Насчёт IDE споры вечные, но по-моему так Rider значительно превосходит VS, про VS Code и говорить нечего. VS Code — отличный редактор, удобно работать с произвольными файлами, типа документации в Markdown или скриптов каких-нибудь. Но там нет нормального анализа и автодополнения кода, мало рефаторингов, нет профайлера, нет coverage analysis, примитивная работа с git. В райдере всё это есть из коробки. Экономит уйму времени, если умеешь пользоваться.
Спасибо за статью! Посыл очень верный, и попробовать переехать с винды стоит каждому.
Но, говоря справедливо, не всё так гладко:
Профайлеры. Ситуация печальная. Только сейчас в .NET Core 3.x появились инструменты от Microsoft (dotnet-trace, dotnet-dump), да и то, результаты лучше смотреть на винде в PerfView/VS. dotTrace от JetBrains пока что только в EAP и работает не для всех версий .NET
Conference tools (Zoom, Skype, ...) — что-то работает, что-то не очень
Нет многих других вещей типа LINQPad
Железо — тут лотерея и танцы с бубном, особенно с ноутами и с видяхами nvidia
IAsyncEnumerable, как и IEnumerable — это pull-модель
Я бы сказал, что IAsyncEnumerable выглядит как pull-модель (делаем foreach), но ведёт себя как push-модель: внутренность foreach является коллбеком, который может быть вызван в том числе в другом потоке.
Очень хорошее замечание. На мой взгляд, лучше лишний раз не думать (и не заставлять коллег думать) и всегда писать async/await. Далеко не все даже опытные разработчики держат в голове все эти тонкости.
это не то же самое, что 40-часовая рабочая неделя в офисе
С учетом того, что ехать никуда не надо, примерно то на то и выходит (если дорога от получаса и больше в один конец).
Ну и, конечно, если вы привыкли потусить у кофемашины, поиграть в пингпонг и иксбокс в рабочее время, сходить на обед на часок, оставляя кодингу часа 3, то да, будет непросто.
Думаю, что stackalloc используется так редко, потому что либо размер буфера предопределён и данные структурированы, тогда просто заполняется struct и берётся указатель, либо размер буфера непредсказуем.
В Ignite.NET использование stackalloc для передачи JNI аргументов (varargs / va_list) вместо params JavaValue[] подняло перформанс реальных кэшовых операций на 15% и избавило от лишних аллокаций / GC.
Спасибо за статью. Пара комментариев:
.Net->.NETНасчёт IDE споры вечные, но по-моему так Rider значительно превосходит VS, про VS Code и говорить нечего. VS Code — отличный редактор, удобно работать с произвольными файлами, типа документации в Markdown или скриптов каких-нибудь. Но там нет нормального анализа и автодополнения кода, мало рефаторингов, нет профайлера, нет coverage analysis, примитивная работа с git. В райдере всё это есть из коробки. Экономит уйму времени, если умеешь пользоваться.
Очень круто, особенно впечатлила компиляция XAML и ходьба по нему в дебаггере!
А где взять и запустить "каталог контролов"? Что-то с ходу не нашел.
https://devblogs.microsoft.com/dotnet/net-core-and-systemd/
Доступно всё рассказано, и ни одного упоминания монад — спасибо!
Но, определения в начале статьи всё-таки отличаются от общепринятых (см википедию):
Есть ссылки на первоисточники этих определений?
С такой логикой можно на JavaScript или Python перейти c дотнета, они ведь популярней :)
Спасибо за статью! Посыл очень верный, и попробовать переехать с винды стоит каждому.
Но, говоря справедливо, не всё так гладко:
dotnet-trace,dotnet-dump), да и то, результаты лучше смотреть на винде в PerfView/VS. dotTrace от JetBrains пока что только в EAP и работает не для всех версий .NETRider себя окупит очень быстро даже для джунов (потому что научит много чему). VSCode и рядом не валялась. Не стоит экономить на рабочих инструментах.
Плюс, полученный опыт транслируется на все остальные продукты, если придётся работать с Python, Java, Go, PHP.
Я сравнивал — разницы по скорости в CPU-bound задачах нет. В работе с диском выигрываeт Linux. Кучу лишних денег надо иметь на лицухи для винды.
Отвечу за себя — как и автор, перешёл на Ubuntu для разработки на .NET Core. Причины:
Я бы сказал, что
IAsyncEnumerableвыглядит как pull-модель (делаемforeach), но ведёт себя как push-модель: внутренностьforeachявляется коллбеком, который может быть вызван в том числе в другом потоке.Вот тут я превращаю push-модель (события) в
IAsyncEnumerable: https://ptupitsyn.github.io/Ignite-Async-Streams/Очень хорошее замечание. На мой взгляд, лучше лишний раз не думать (и не заставлять коллег думать) и всегда писать async/await. Далеко не все даже опытные разработчики держат в голове все эти тонкости.
Занятно! К картинкам можно добавить подпись, что все эти размеры полей и смещения — для 32 битного режима.
С учетом того, что ехать никуда не надо, примерно то на то и выходит (если дорога от получаса и больше в один конец).
Ну и, конечно, если вы привыкли потусить у кофемашины, поиграть в пингпонг и иксбокс в рабочее время, сходить на обед на часок, оставляя кодингу часа 3, то да, будет непросто.
Именно поэтому сделан тонкий клиент, который использует только чистый .NET и дополнительных требований не имеет.
Ради прикола попробовать можно было бы, но для продакшна это точно не решение.
Да и проект IKVM загнулся, к сожалению.
http://weblog.ikvm.net/2017/04/21/TheEndOfIKVMNET.aspx
Представим узлы кластера А и Б, толстый клиент К, тонкий клиент Т подключен к узлу А.
При попытке извлечь данные, находящиеся на узле Б, толстый клиент отправит запрос напрямую. Тонкий же работает только через узел А.
Через JNI и указатели на unmanaged (offheap) память. Да, это намного быстрее сокета.
Только что прочитал, что
libcurlвыпиливают в .NET Core 2.1:https://blogs.msdn.microsoft.com/dotnet/2018/02/27/announcing-net-core-2-1-preview-1/
Интересно, что как это обернётся для вас :)
Сколько в стеке свободного места есть. Размер стека по умолчанию на винде 1 или 4 метра (32/64 бит), на Линухе по-разному, частый вариант — 8 метров.
Ну и часть этого места наверняка занята самим стеком вызовов.
Думаю, что
stackallocиспользуется так редко, потому что либо размер буфера предопределён и данные структурированы, тогда просто заполняетсяstructи берётся указатель, либо размер буфера непредсказуем.В Ignite.NET использование
stackallocдля передачи JNI аргументов (varargs/va_list) вместоparams JavaValue[]подняло перформанс реальных кэшовых операций на 15% и избавило от лишних аллокаций / GC.Код на гитхабе: UnmanagedUtils.cs
Ещё пример, перетасовка байт: WriteGuidSlow