C# *

Как мы столкнулись с неожиданным багом в .NET 5, расследовали возникшую проблему, и что же из этого вышло.

Раньше я очень любил C#

Это был мой основной язык программирования, и каждый раз, когда я сравнивал его с другими, я радовался тому, что в свое время случайно выбрал именно его. Python и Javascript сразу проигрывают динамической типизацией (если к джаваскрипту понятие типизации вообще имеет смысл применять), Java уступает дженериками, отстутствием ивентов, value-типов, вытекающей из этого карусели с разделением примитивов и объектов на два лагеря и зеркальными классами-обертками вроде Integer, отсутствием пропертей и так далее. Одним словом — C# клевый.

Отдельно отмечу, что я сейчас говорю о самом языке и удобстве написания кода на нем.
Тулинг, обилие библиотек и размер сообщества я сейчас в расчет не беру, потому что у каждого
из этих языков они развиты достаточно, чтобы промышленная разработка была комфортной в большинстве случаев.

А потом я из любопытства попробовал F#.

Здравствуйте, давно читаю Хабр и все хотел написать кому-нибудь статью, но не знал с чего начать и о чем писать. Но решил что тянуть кота за причинное место. Надо просто взять и написать обзор о чем то что я знаю и что будет просто для начало. Поэтому решил описать алгоритмы сортировки в размере 37 штук. Я понимаю, что на Хабре есть подобные статьи, одна постараюсь их добавить количеством алгоритмов и приведением небольшого числа графиков.

Статья о моих приключениях при разработке первой игры в 3D. Да, вы правильно поняли, я замахнулась на святое, и попробовала сделать Skyrim на Unity. Но делала это с любовью и от чистого сердца.

На просторах интернета, и в частности хабра, очень трудно встретить статьи с критикой игрового движка Unity. Я решил это исправить, и приготовил вам текст о переходе на DOTS, насилию над C#, знаменитых UI пакетах, MonoBehaviour, универсальности и о многом другом.

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

Современные процессоры очень круты. Они таят в себе великое множество секретов и невероятных возможностей. И просто восхитительно, что некоторые из способностей процессоров легко продемонстрировать даже из такого высокоуровневого языка, как C#, буквально за десять строчек кода!

Разрабатывая один проект на свежем .NET 7 столкнулся с необходимостью подписывать данные с использованием отечественных криптоалгоритмов. Ранее, в .NET Framework хорошая поддержка работы с со сторонними криптопровайдерами, реализующими семейство алгоритмов ГОСТ (CryptoPro CSP, ViPNet CSP и пр.), шла "из коробки". К сожалению, в новые версии фреймворка часть ранее работающего функционала по работе с CMS-сообщениями не попала, и пришлось восполнять пробел надёжными дедовскими методами, т. е. с помощью старого доброго WinAPI.

Avalonia — кроссплатформенный .NET UI-тулкит с открытым исходным кодом, вдохновлённый технологиями WPF и UWP. Он полностью поддерживает Windows, macOS и Linux, .NET Core 2.0-3.1, XAML, дата-биндинги, lookless-контролы и многое другое.

^{(на ВДПВ показана работа без XOrg)}

Версия 0.9 стала большим обновлением с набором давно ожидаемых фич: компилируемый XAML, поддержка глобальных меню, возможность плавной прокрутки виртуализированных списков с элементами произвольного размера, поддержкой сенсорного ввода и ещё кое-чем.

За подробностями прошу под кат.

Итак, начнем с представления строк в памяти

В одной конторе соискателю на позицию Senior C# developer выдали тестовое задание: отсортировать файл со строками определенного формата.

Требования такие:

* Формат строки: число, точка, пробел, далее любые символы до конца строки.

* Порядок сортировки — сначала сортируем текстовой части строки, потом по числу если текстовые части совпадают.

* Кодировка — UTF-8.

* Размер файла — 100гб - гарантированно больше объема ОП.

Должно отработать за 1 час на машине проверяющего, вряд ли там будет супер-быстрый SSD и огромное количество оперативной памяти.

Как и многие другие программисты, узнав о таком тестовом задании, я возмутился. Внешнюю сортировку слиянием практически всех проходили в ВУЗе, но практически никто никогда не писал её. Задача очень непрактическая и непонятно какие навыки проверяет. Так мне казалось.

Эта задача вызвала бурные обсуждения о способах её решения. Многие программисты, причисляющие себя к рангу senior, предложили использовать базы данных, ибо не барское это дело - вручную писать алгоритмы сортировки. Некоторые даже попытались сделать решение на Apache Spark. Однако никто до конца задачу не решил, ибо мало кому удалось отсортировать в нужном порядке даже 10ГБ файл менее чем за 15 минут без SSD.

Я подумал, что стоит решить задачу до конца с помощью программирования, и тоже причислить себя к рангу senior developer.

В последние годы команда .NET усиленно рекламирует ASP.NET Core как один из самых быстрых веб-фреймворков на рынке. Источником этих утверждений всегда были бенчмарки TechEmpower Framework Benchmarks.

Скотт Хантер - директор по управлению программами .NET, утверждает, что .NET более чем в 10 раз быстрее, чем Node.js.

Скотт также утверждает, что .NET быстрее, чем Java, Go и даже C++.

Меня очень возмутил вчерашний пост Что будет с C# и причём здесь Страуструп? Конечно, каждый имеет право на мнение, но автор использует множество манипулятивных техник, таким образом негативно влияя на мнение молодых читателей. Да и сам текст является маркетинговым переводом, что меня сильно удивляет. Потому и захотелось развенчать мифы из данной статьи.

Не поймите меня неправильно, я не фанбой C#. Буквально недавно в подкасте DotNet & More №53 C# 10 и не только я жаловался на то, что C#10 не впечатляет. Но в своих высказываниях необходимо стараться быть хоть немного объективным. Или, хотя бы, иронизировать над необъективностью.

Введение

На дворе 2025 год, а я всё ещё продолжаю делать видеоигры. Если верить archive.org, я начал заниматься этим двадцать лет назад! Достаточно долгий срок для одного увлечения...

Когда я рассказываю о том, над чем работаю, люди часто спрашивают меня, как я делаю игры, и их часто удивляет (а иногда и тревожит?), когда я говорю, что не пользуюсь коммерческими игровыми движками. Существует какой-то стереотип, что если ты делаешь игры не в популярном инструменте наподобие Unity или Unreal, это значит, что ты чуть ли не вручную пишешь ассемблерный код.

Я искренне считаю, что создание игр без огромного «многофункционального» движка может быть проще и интереснее, а часто и позволяет оптимальнее тратить вычислительные ресурсы. Я не делаю игру, в которой «есть всё», поэтому мне не нужны 90% фич, предоставляемых движками. Все мои игры обладают конкретным стилем и у меня есть конкретные способы работы с моими инструментами. Часто оказывается так, что используемым по умолчанию реализациям фич в крупных движках наподобие Unity не хватает столь многого, что мне всё равно приходится писать их самостоятельно. В конечном итоге, мои проекты по большей мере оказываются моими собственными инструментами и системами, а движок становится необходим лишь для создания удобного UI и части рендеринга...

Тут можно задаться вопросом, а зачем вообще использовать движок? Что он даёт? Зачем я позволяю инструменту потенциально препятствовать моей работе, когда его владельцы внезапно принимают неэтичные и ужасные бизнес-решения? Или выпускают обновление, которое требуется для запуска моей игры на консолях, но ломает всю систему в игре, заставляя переписывать её? Зачем я ежедневно борюсь с этим для работы с движком, пока я постепенно заменяю все его стандартные системы и он постепенно становится только загрузчиком ресурсов и фреймворком UI редактора?

Это расшифровка-перевод доклада Саши Гольдштейна, признанного лучшим на конференции DotNext 2016 Piter. С годами этот доклад стал лишь актуальнее прежнего: появление Mac на ARM-процессорах — еще один пример, почему разработчикам сегодня нужно думать не только о x86-архитектуре.

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

То, что подходит процессорам Intel на архитектурах x86 и x86-64, может не подойти другой архитектуре. Как только вы перенесете свой код на другой процессор, например, на ARM для iPhone и Android, есть вероятность, что он перестанет работать как надо. Проблемы могут быть как очевидными (воспроизводиться с первого-второго раза), так и не очень (возникать только раз в миллион итераций). Вполне вероятно, что такие баги могут добраться до продакшна. Сегодня .NET и, конечно, C++ можно использовать не только на Windows и Intel, но и на других платформах, так что доклад будет полезен многим разработчикам.

Дисклеймер: статья предназначена для продвинутых читателей. Смотрите на свой страх и риск. За частое упоминание барьеров памяти и изменения порядка исполнения инструкций она получила возрастное ограничение 18+.