Пришёл вчера вечером домой и решил-таки почитать тред Why Go?.

Оказывается, комментарий на Хабре, о котором я писал, это перевод вот этого комментария. У него, к слову, больше дизлайков, чем лайков, т.к. написан AI. Но, судя по всему, портировать (именно портировать, не переписывать) TypeScript на Go всё же легче.

В самом низу есть и ответ Андерса Хейлсберга. Приведу цитату:

The TypeScript compiler's move to Go was influenced by specific technical requirements, such as the need for structural compatibility with the existing JavaScript-based codebase, ease of memory management, and the ability to handle complex graph processing efficiently. After evaluating numerous languages and making multiple prototypes — including in C# — Go emerged as the optimal choice, providing excellent ergonomics for tree traversal, ease of memory allocation, and a code structure that closely mirrors the existing compiler, enabling easier maintenance and compatibility.

In a green field, this would have been a totally different conversation. But this was not a green field - it's a port of an existing codebase with 100 man-years of investment. Yes, we could have redesigned the compiler in C# from scratch, and it would have worked. In fact, C#'s own compiler, Roslyn, is written in C# and bootstraps itself. But this wasn't a compiler redesign, and the TypeScript to Go move was far more automatable and more one-to-one in its mapping. Our existing codebase is all functions and data structures - no classes. Idiomatic Go looked just like our existing codebase so the port was greatly simplified.

Короче говоря, это техническое решение обусловленное финансовыми ограничениями. Переписать на Rust/C# можно было бы, но кто за это будет платить?

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

Последние несколько дней я занимаюсь миграцией своего блога с 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-пакет. Большое спасибо.