Языком 2023 года по индексу TIOBE назван C#, который сохранил 5 место, но стал лидером по росту популярности (+1.43%) 🥳

Жаба уже одной в могиле, ведь она показала один из самых высоких спадов популярности (-4.34%) ☠️

https://www.tiobe.com/tiobe-index/

Узнали? Согласны?

Рекомендую к прочтению

В прошлом году у меня возникла необходимость систематизировать в моменте свои знания об асинхронном программировании в C# и при этом иметь постоянную шпаргалку под рукой.

Собственно, эта книга идеально решила эту потребность - в ней описаны все необходимые аспекты, при чём очень доступно и концептуально, на уровне идеи, а не конкретного кода.

Вы даже узнаете, в чём преимущество async / await для ASP NET приложений!

Бумажный вариант стоит недорого, сама книга имеет небольшой объём - всего 119 страниц.

Так что, однозначный лайк👍🏻

Какой сахар мне хотелось бы видеть в новых версиях C#

Вас не подвело зрение, мне действительно не хватает кое-какого синтаксического сахара)

Большинство разработчиков знакомы с оператором ??

Он делает эквивалентными две следующие строчки:

return expr is null ? fallbackValue : expr

// ...

return expr ?? fallbackValue

Однако, в моей практике часто встречалась ситуация, когда необходимо было сделать обратный процесс:

return expr is null ? null : GetResult(expr)

Хотелось бы сократить эту запись до одного оператора.

Не важно, как он будет называться, варианты: ?!, ?:, ???

Тогда, сокращение будет выглядеть так:

return expr ??? GetResult(expr)

Priority Queue

В .NET 6 завезли такую настоящую объекто-ориентированную очередь с приоритетами.

Объектно-ориентированная в смысле поддержки своих формальных типовых параметров:

▪️TElement - тип содержимого очереди

▪️TPriority - тип приоритета содержимого очереди

По сути своей, это сортирующая коллекция, в которой приоритет выступает ключом сортировки.

Причём в конструктор очереди, можно передать экземпляр IComparer<T>, чтобы, например, определить направление сортировки:

// сортируем по убыванию некоторой даты
var queue = new PriorityQueue<string, DateTimeOffset>(
    Comparer<DateTimeOffset>.Create((x, y) => y.CompareTo(x)));

queue.Enqueue("abv", DateTimeOffset.UtcNow.Subtract(TimeSpan.FromDays(2)));
queue.Enqueue("ghj", DateTimeOffset.UtcNow.Subtract(TimeSpan.FromDays(3)));
queue.Enqueue("123", DateTimeOffset.UtcNow.Subtract(TimeSpan.FromDays(1)));

while (queue.TryDequeue(out var card, out var addedOn))
{
    Console.WriteLine($"{card}, {addedOn}");
}
// чтение выведет: 123 | abv | ghj

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

Из недостатков можно отметить, что класс PriorityQueue<TElement, TPriority> не реализует никаких LINQ интерфейсов, или интерфейсов коллекций, поэтому совместимость с другими API придётся реализовывать самому.

Больше прочитать про внутреннее устройство класса можно в статье Вадима Мартынова на Хабре

Всех с началом рабочей недели!

«Самая зрелая реакция — это радоваться его успеху. Вам следует вознаградить его за производительность и признать его успешность, особенно если это очень качественный сотрудник.

…

Кроме того, мы можете учиться у этих упорно трудящихся людей. Если их показатели крайне высоки, узнайте, как им это удаётся.»

https://habr.com/ru/articles/791264/

А вы используете IAsyncEnumerable?

У меня сложилось впечатление, будто после релиза C# 8 про эту штуку все забыли, поэтому решил сегодня про неё вспомнить)

Этот тип данных решал задачу потребления и создания асинхронных потоков данных.

То есть, таких потоков, в которых данные получают или генерируют асинхронно.

Напомню, что если у нас есть некоторый метод:

static async IAsyncEnumerable<Data> GetData()
{
    // ...
}

То в таком случае, можно перебрать возвращаемое значение следующим образом:

await foreach (var item in GetData())
{
    // ...
}

Но что в таком случае будет наполнять тело метода GetData?

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

То есть, всё сразу предъявить мы не можем, но способны заявить об этой возможности.

Например, есть многостраничный список с фиксированным количеством элементов на одной странице.

Тогда, внутри метода GetData будет скачиваться одна страница и разворачиваться в плоский поток до тех пор, пока есть следующая страница:

static async IAsyncEnumerable<Data> GetData()
{
    var page = 1;
    while (page <= 10)
    {
        var items = await Fetch(page);
        foreach (var item in items)
            yield return item;
        page++;
    }
}

В вашей практике встречается потребность в IAsyncEnumerable?

Статические анонимные функции

Оказывается, в C# 9 лямбды получили серьёзное обновление!

Штука настолько малоизвестная, что меня даже ни разу не спрашивали про неё на собесах!

Допустим, у вас есть следующий код с замыканием:

int y = 1;
Func<int, int> lambda = x => x + y;

Захват переменной y и всего внешнего окружения вызовет ненужные аллокации.

С помощью ключевого слова static можно запретить подобные ситуации.

Тогда, обновлённый код не скомпилируется:

int y = 1;
Func<int, int> lambda = static x => x + y;

Однако, если очень нужно иметь возможность использовать y, но при этом сохранять эффективность кода, то переменную просто надо сделать константой:

const int y = 1;
Func<int, int> lambda = static x => x + y;

Кирилл сделал хорошее дополнение к последнему посту на своём канале @csharp_gepard

Бенчмарк показал, что производительность не меняется при добавлении static к делегату.

В целом ожидаемо и вполне логично, так как это compile guard