Здравствуйте, Codealot, Вы писали:
C>Только если у тебя бесконечные ресурсы. Которых на самом деле нет.
Вы предлагаете перекинуть ресурсы команды платформы на язык?
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, _NN_, Вы писали:
_NN>>Похоже в .NET 10 нас ждут серьёзные улучшения производительности.
C>Все сильнее становится ощущение, что чуваки пытаются переизобрести C++.
Конкретно решают проблему медленного старта приложений из-за JIT.
Посему работают надо Native AOT, чтобы программы запускались быстрее.
Это актуально для всяких утилит и для короткоживущих контейнеров.
Кстати, проблема настолько серьёзная, что некоторые команды в MS решили переписать с C# на Rust
А по поводу С++, это ведь гораздо приятнее писать на C# со всеми преимуществами платформы получая при этом быстродействие примерно нативного кода.
Здравствуйте, _NN_, Вы писали:
_NN>Это актуально для всяких утилит и для короткоживущих контейнеров. _NN>Кстати, проблема настолько серьёзная, что некоторые команды в MS решили переписать с C# на Rust
О! А можно поподробнее, что они там решили переписать и откуда это известно?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, _NN_, Вы писали:
_NN>>Это актуально для всяких утилит и для короткоживущих контейнеров. _NN>>Кстати, проблема настолько серьёзная, что некоторые команды в MS решили переписать с C# на Rust
Ф>О! А можно поподробнее, что они там решили переписать и откуда это известно?
Ну во первых об этом уже писали и не раз.
Во вторых об этом рассказывали непосредственно сами разработчики из Офиса.
Были у них утилиты на .NET Framework, которые перевели на .NET, но тут выяснилось, что он не является частью ситсемы и поэтому стартует гораздо медленней.
В последних .NET улучшили это дело с Ready2Run и следующим шагом работают над Native AOT, но когд это будет реально готово в производстве никто не знает.
Посему решили, что раз это утилиты и не что-то мегасложное можно и переписать на Rust, тем более когда такое движение вокруг языка.
Что там дальше с этим я не в курсах, не интересовался.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, _NN_, Вы писали:
_NN>>Конкретно решают проблему медленного старта приложений из-за JIT.
C>А что конкретно тормозит и насколько?
Здравствуйте, Codealot, Вы писали:
C>А сейчас они делают оптимизации в ущерб нужным вещам, которые никак не могут сделать уже почти десяток лет.
A что в C# кроме DU так уж нужно?
.NET хорошая штука, но кажется они уже опоздали, для меня .NET это аналог джавы, вероятно чуть быстрее на каких-то коротких дистанциях, на длинных джава скорее всего будет выгоднее.
Go и Rust оттягивают на себя долю рынка.
При этом серверный рынок наверное проигран, т.е. выйти там в топ не удастся, GUI — что-то специфическое, наверное да, мобильный тоже нет. При том, что студию для линукса так никто и не сделал, а без решарпера студия — очень продвинутый блокнот.
Раньше винда vs линукс на десктопе имело большое значение, а сейчас куча все в вебе, гуи линухов подтянулся, а по браузеру шариться без разницы откуда, а остальных тулов не так уж и много. И такое ощущение, что в массе .NET сейчас особо никто и не выберет с нуля, при этом смузихлебы скажут что сложнаа, многа букаф, и это ваще не тренд.
Скорее возьмут и питон/го/раст, более того куча всевозможных либ, кешей, очередей и чего только нет — все написано. Т.е. сложный монолитный кеш (как Ignite) вряд ли кто-то будет писать на C#/
Тут сравнивают старт, рантайм, потребление памяти. Сейчас чистого кода в экосистеме компании работающего условно на шарпах ничтожна: базы Си/С++, очереди сообщений тоже + java, кубер на го, всякие кеши на java/Си/С++, какой смысо мне брать .NET если rest gateway на го, будет работать быстро и с мелким memory footprint, который будет сваливать сообщения в кафку, а дальше все относительно быстрое это го/раст, медленное питон.
Да Java/C# очень хороши для больших и сложных моделей, которые линкуются статически. Т.е. написать биллинг на питоне например или на го — идите в ж... потом сами собирайте все это г-но. Там где на джаве и шарпах можно решить вопрос атрибутами/аннотациями либами конфигами, на других языках придется писать и писать много.
Т.е. Java/C# для выстраивания "своей" сложной модели, но много ли тех, кто упирается в такие ограничения?
Текущие улучшения выглядят как "придержим старичков, чтобы не ушли", хотя язык прекрасен, может где-то уступает котлину в синтаксисе, но силен в управлении памятью, да и спецов еще найди по шарпам.
Здравствуйте, Codealot, Вы писали:
_NN>>выяснилось, что он не является частью ситсемы и поэтому стартует гораздо медленней. C>Что значит "не часть системы" и какое это имеет отношение к скорости?
Я пока не смотрел на ссылки, которые он дал — не знаю что там говорилось.
.NET Framework в Windows имеет Global Assembly Cache и Native Image Cache, у .NET такого нет (не было).
В первый кэш падают "глобальные" сборки, а во вторые — нативные образы, которые избавляют от необходимости в JIT-компиляции — они компилируются во время ngen install имя_сборки.
Вот всей этой подсистемы не было у .NET
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
_NN>>>выяснилось, что он не является частью ситсемы и поэтому стартует гораздо медленней. C>>Что значит "не часть системы" и какое это имеет отношение к скорости?
Ф>Я пока не смотрел на ссылки, которые он дал — не знаю что там говорилось. Ф>.NET Framework в Windows имеет Global Assembly Cache и Native Image Cache, у .NET такого нет (не было). Ф>В первый кэш падают "глобальные" сборки, а во вторые — нативные образы, которые избавляют от необходимости в JIT-компиляции — они компилируются во время ngen install имя_сборки.
Ф>Вот всей этой подсистемы не было у .NET
Так как .Net Core кроссплатформенный и нужно быть независимым от сборок на машине. Пошли другим путем.
Вы можете уменьшить время запуска и задержку приложения .NET, скомпилировав все сборки приложения в формат ReadyToRun (R2R). R2R является разновидностью компиляции AOT.
Бинарные файлы R2R повышают производительность при запуске, снижая объем работы, выполняемой на этом этапе компилятором JIT. Бинарные файлы содержат такой же машинный код, который создается компилятором JIT. Но бинарные файлы R2R имеют больший размер, так как содержат не только код на промежуточном языке (IL), который по-прежнему необходим для некоторых сценариев, но и версию того же кода на машинном языке. Функция R2R доступна только при публикации приложения, предназначенного для конкретной среды выполнения (RID), например для Windows x64 или Linux x64.
Здравствуйте, novitk, Вы писали:
N>Здравствуйте, Codealot, Вы писали:
C>>А сейчас они делают оптимизации в ущерб нужным вещам, которые никак не могут сделать уже почти десяток лет. N>A что в C# кроме DU так уж нужно?
Вынужден согласиться.
Для Линукс сегодня я есть Rider, но это не от MS.
От MS есть только VSCode и закрытый DevKit.
Начинать сегодня писать код сервисов на .NET это действительно будет странным выбором.
Экосистема Go ушла далеко вперёд.
Ну и конечно плюшки в виде простого развёртывания и быстрого старта никто не отменяет.
Здравствуйте, _NN_, Вы писали:
_NN>Начинать сегодня писать код сервисов на .NET это действительно будет странным выбором. _NN>Экосистема Go ушла далеко вперёд.
Смотря что писать: го — очень слабенький, невыразительный язык, почти ассемблер.
Всё сказанное выше — личное мнение, если не указано обратное.
