ИИ впечатляет всё больше и больше

Последние несколько дней я занимаюсь миграцией своего блога с Jekyll на Astro, и в этом мне очень помогает ИИ.

1. Частично пишу код с помощью ИИ-агентов в GitHub Copilot (тот самый Vibe Coding). Особенно полезно, когда нужно выполнить много рутинных задач: заменить <img/> на <Image>, добавить краткие описания ко всем постам, отредактировать теги и привести их к единому стилю.

2. В Astro у каждого поста должна быть обложка, тогда как в Jekyll она была не обязательной. Здесь на помощь приходит генерация картинок в ChatGPT. Впечатляет, что нейросети уже умеют корректно генерировать текст.

Утиная типизация в C#

English version.

Думаю, опытные C#-разработчики знают ответ на вопрос: «Что нужно сделать, чтобы можно было перечислить объекты при помощи foreach?»

Для этого не обязательно наследовать класс от интерфейса IEnumerable. Достаточно, чтобы класс имел публичный метод GetEnumerator, который возвращает объект, реализующий IEnumerator.

// Этот код компилируется
var obj = new MyType();
foreach (var item in obj);

class MyType {
    public IEnumerator GetEnumerator() {
        throw new Exception();
    }
}

Такое поведение иногда называют утиной типизацией — компилятору неважно, реализует ли класс интерфейс IEnumerable или нет. Главное, чтобы в нём был метод, возвращающий перечислитель.

Аналогичное поведение встречается и при работе с async-await. Чтобы «ожидать» тип, достаточно, чтобы у него был метод GetAwaiter(), возвращающий тип TaskAwaiter или ValueTaskAwaiter. При этом даже не обязательно, чтобы этот метод был внутри самого ожидаемого типа.

 cs
// Этот код тоже компилируется
var obj = new MyType();
await obj;

class MyType {
}

static class MyTypeExtensions {
    public static TaskAwaiter GetAwaiter(
        this MyType @object) {
        throw new Exception();
    }
}

Недавно я наткнулся на ещё один случай, который можно считать примером утиной типизации. Начиная с версии 12, в C# появился упрощённый способ инициализации коллекций:

int[] array = [1, 2, 3, 4, 5];
List<int> list = [1, 2, 3, 4, 5];

Этот лаконичный синтаксис работает не со всеми коллекциями. Например, следующий код не скомпилируется:

Queue<int> queue = [1, 2, 3, 4, 5];
Stack<int> stack = [1, 2, 3, 4, 5];

Компилятор ожидает, что у типа коллекции будет метод Add, но в Queue вместо него используется Enqueue, а в Stack — Push. Изменить эти типы мы не можем, поэтому можно сделать следующий финт и помочь компилятору обнаружить метод Add:

public static class CollectionExtensions {

    public static void Add<T>(
        this Queue<T> collection, 
        T item) => collection.Enqueue(item);

    public static void Add<T>(
        this Stack<T> collection, 
        T item) => collection.Push(item);
}

Упрощённая инициализация работает и с кастомными коллекциями, при условии, что для них есть соответствующий метод Add — неважно, внутри типа или в методе-расширении.

// и этот код компилируется
MyType collection = [1, 2, 3];

class MyType : IEnumerable {
    public IEnumerator GetEnumerator() {
        throw new Exception();
    }
}

static class MyTypeExtensions {
    public static void Add(
        this MyType o, 
        int value) { }
}

UPD: В комментариях выяснили, что оператор using может быть использован с ref struct без IDisposable начиная с C# 8.0.

using var obj = new MyType();

ref struct MyType {
    public void Dispose() { }
}

UPD2: В комментариях выяснили, что foreach может обойтись без IEnumerator.

// Этот код компилируется
var obj = new MyType(); 
foreach (var item in obj); 
 
class MyType { 
    public MyEnumerator GetEnumerator() => new(); 
} 
 
class MyEnumerator { 
    public object Current => new(); 
    public bool MoveNext() => false; 
}

Ещё больше опенсорсных проектов становятся платными

Две свежие новости из мира open-source software (OSS) в .NET:

1. MassTransit станет платным, начиная с версии 9. Новая версия будет распространяться по коммерческой лицензии. При этом версия 8 останется OSS и будет получать только критические патчи и багфиксы.

2. Джимми Богарт, автор AutoMapper и MediatR, также сообщил, что переводит свои проекты на коммерческую модель. Он больше не может поддерживать их в свободное от работы время, как раньше, и хочет создать устойчивую модель развития. Конкретные детали монетизации пока не объявлены. Забавно, что всего 2 месяца назад он писал, что никогда не сделает MediatR платным.

Что происходит?

Не сказать, что я большой фанат AutoMapper и MediatR. По-моему, от них даже больше проблем, чем пользы. Но поддержка OSS – действительно сложная штука. Людей, которые тратят личное время на такие проекты можно понять. Я это вижу даже по EventFlow. У библиотеки 2.4 тыс. звёзд на GitHub и миллионы загрузок на NuGet. Но при этом автор пишет, что почти нет пул-реквестов от компаний, не говоря уже о финансовой поддержке.

Можно вспомнить свежий случай с FluentAssertions. Ещё 2 года назад автор с иронией «хвастался», что кто-то задонатил $31. Неудивительно, что он решил продать своё детище компании. Правда это не отменяет текущий неадекватный ценник на библиотеку – сейчас она стоит почти как Rider.

Также можно привести в пример Avalonia UI. У проекта 27.3 тыс. звёзд на GitHub, десятки миллионов загрузок на NuGet и всего 43 спонсора. Даже если предположить, что каждый из них донатит по $100 в месяц (что маловероятно), это всего $4300 — немного для команды из 11 человек. Да, они наверняка дополнительно зарабатывают на консалтинге, но если говорить исключительно о добровольной поддержке через донаты — ситуация грустная.

Короче говоря, заниматься OSS — это интересно, полезно и вдохновляюще. Но когда проект становится популярным, трудно продолжать работать над ним бесплатно с учётом возрастающей нагрузки. В какой-то момент разработчик выгорает и начинает хотеть справедливой компенсации за свой труд. И вместо поддержки часто получает волну критики, причём от своих же коллег по цеху.

В итоге от всей этой ситуации выигрывают только корпорации. Одни просто используют OSS в своих коммерческих продуктах. Другие скупают права на библиотеки, фактически присваивая результат многолетнего труда десятков разработчиков, которые вкладывали в проект своё время, знания и энтузиазм.

Коллеги, посоветуйте, пожалуйста, бесплатные Postgres-as-a-Service решения.

Цены у облачных провайдеров совсем не подходят для pet-проектов. Например, тот же Яндекс стоит больше 5000 рублей / месяц.

Основные требования:
- Бесплатно навсегда, без триал периода.
- Наличие резервных копий с возможностью восстановления хотя бы за последние 1–3 дня.
- Без обязательной привязки банковской карты.
- Локация — Европа.
- Объём — достаточно пары сотен мегабайт.

Google Sheets не предлагать. Я уже использую её в качестве базы данных.

SharpLab мёртв?

Сегодня буднично писал код. В какой-то момент мне понадобилось быстро вспомнить работу одной коллекции. Для таких случаях я обычно использую sharplab.io.

Открыв сайт и начав писать код я понял, что пользоваться им очень трудно из-за раздражающего бага: при вводе всплывает окно автокомплита, и если нажать Tab или Enter, редактор просто удаляет весь текст.

Я пошёл проверить, открыт ли issue. Оказалось, что да — и уже почти три месяца. Но никто его не правит, а пул реквесты в репозиторий вообще не принимаются.

Последняя активность в проекте — 18 ноября 2024 года. С тех пор — тишина.

На всякий случай я открыл issue с вопросом. Посмотрим, что ответит Андрей (автор SharpLab) и будет ли вообще ответ.

Влияние логирования в C# на производительность

English version.

Давно ничего не было про производительность. Сегодня про логирование и как оно влияет на производительность.

Если вы писали такой код:

// CA2254: The logging message template 
// should not vary between calls
logger.LogDebug($"Request Id: {id} finished with Error: {error}");

...то, скорее всего замечали, что IDE настойчиво рекомендовала так больше не делать.

Почему? Потому что интерполированные строки — это синтаксический сахар.
После компиляции код будет выглядеть так:

var handler = new DefaultInterpolatedStringHandler(34, 2);
handler.AppendLiteral("Request Id: ");
handler.AppendFormatted(value);
handler.AppendLiteral(" finished with Error: ");
handler.AppendFormatted(value2);
string text = handler.ToStringAndClear();
logger.LogDebug(text);

Проблема здесь в том, что строка text создаётся всегда, даже если уровень логирования выше Debug и сообщение в лог не попадёт.

Более правильный вариант логирования выглядит так:

logger.LogDebug("Request Id: {Id} finished with Error: {Error}", Id, Error);

В этом случае строковый шаблон "Request Id: {Id} finished with Error: {Error}" не будет использоваться, если, например, минимальный уровень логирования Information.

Лишних аллокаций удастся избежать… так я думал, пока не написал бенчмарки и не проверил результаты.

Читать полностью на сайте 👇🏻

P.S. Зацените обновлённый блог. Наконец-то закончил миграцию с Jekyll на Astro.

В продолжение вчерашнего поста про xxHash

Коллеги в комментариях подсказали ещё один интересный алгоритм — GxHash. Я посмотрел репозиторий вчера вечером и быстро прогнал бенчмарк (результаты на обложке).

Что понравилось:
– Действительно быстрый. Даже быстрее xxHash.
– Как и xxHash, возвращает хэш в виде uint, ulong или UInt128.

Недостатки:
– Нет NuGet-пакета. Пришлось копировать исходники вручную.

Спасибо за наводку @NSent

UPD: @viruseg нашёл NuGet-пакет. Большое спасибо.

Используйте индексаторы вместо методов LINQ

Это часть серии, в которой я разбираю правила качества кода .NET с точки зрения производительности. Сегодня поговорим про CA1826: Use property instead of Linq Enumerable method.

Описание правила

Правило рекомендует не использовать методы First(), Last(), Count() из LINQ с IReadOnlyList<T>:

IReadOnlyList<string> list = ["str1", "str2", "str3"];
var first = list.First();   // CA1826
var last = list.Last();     // CA1826
var count = list.Count();   // CA1826

Вместо этого стоит использовать индексатор или свойство Count:

IReadOnlyList<string> list = ["str1", "str2", "str3"];
var first = list[0];
var last = list[^1];
var count = list.Count;

Анализ производительности

Я написал простой бенчмарк, чтобы проверить, насколько LINQ действительно влияет на производительность. Результаты в репозитории и на диаграмме.

Как видно, разница есть. Но она совсем небольшая — всего несколько микросекунд на моём ноутбуке.

Стоит ли заморачиваться?

В большинстве случаев нет. Прирост производительности минимальный. Но если вы пишете высокопроизводительный код или используете LINQ методы в цикле — возможно код стоит отрефакторить.

Скриптинг на C# всё ближе

Microsoft продолжает двигаться в сторону упрощения C#. В свежем видео они показали функционал, позволяющий запускать cs-файлы без sln и csproj. Фича доступна в Preview версии .NET 10.

Пример:

dotnet run hello.cs

Работает даже с NuGet-пакетами прямо в файле:

#:package Spectre.Console@0.50
#:package Spectre.Console.Cli@0.50

using Spectre.Console;

AnsiConsole.Markup("[underline red]Hello[/] [underline green]World![/]");

Как выглядит результат - на скриншоте.

Пока не совсем ясно, будет ли возможность запускать такие файлы в Docker, то есть через Runtime, а не через SDK.

StringBuilder: избегайте ToString при использовании Append

Read on website.
Читать на сайте.

Это новая часть серии, в которой я разбираю правила качества кода .NET с точки зрения производительности. Сегодня поговорим про CA1830: Prefer strongly-typed Append and Insert method overloads on StringBuilder.

Описание правила

Правило рекомендует не преобразовывать значения в строку при вызове методов Append или Insert.

var i = 123;
var sb = new StringBuilder();
sb.Append(i.ToString()); // CA1830

Вместо этого лучше передать значение напрямую:

var i = 123;
var sb = new StringBuilder();
sb.Append(i);

Это правило касается примитивных типов вроде byte, short, int, double, long и других.

Анализ производительности

Я написал простой бенчмарк, чтобы оценить, насколько эти подходы отличаются по производительности. Результаты в репозитории и на диаграмме.

Разница по времени — небольшая: около 5 микросекунд на моём ноутбуке. Разница по памяти более заметная: около 20 кБ.

Как работает эта оптимизация?

Когда вы используете метод Append(int), под капотом StringBuilder вызываются методы AppendSpanFormattable<T> и InsertSpanFormattable<T>.

Например, упрощённая версия AppendSpanFormattable<T> выглядит так:

private StringBuilder AppendSpanFormattable<T>(T value) where T : ISpanFormattable
{
    if (value.TryFormat(
        RemainingCurrentChunk, 
        out int charsWritten, 
        format: default, 
        provider: null))
    {
        m_ChunkLength += charsWritten;
        return this;
    }

    return Append(value.ToString());
}

Этот метод использует интерфейс ISpanFormattable.TryFormat, чтобы записать значение напрямую во внутренний буфер StringBuilder как Span<char>. Это позволяет: избежать аллокации строки; упаковки (boxing) и вызова виртуального метода ToString().

Стоит ли заморачиваться?

Скорее да. Даже если не брать в расчёт прирост производительности, такой код:

sb.Append(i);

и выглядит проще и чище, чем:

sb.Append(i.ToString());

И в качестве бонуса, он работает быстрее и потребляет меньше памяти. Win-win.