Как поменяется .NET и C# в ближайшие годы?

[Gromilo]

Runtime async

Чёт страшно мне. На бэкендах привык разделять асинхронный и синхронный код, как код с IO и код без IO. Код без IO является ещё и чистыми функциями по возможности. Позволяет делить методы на части вида: грузим, что-то делаем, сохраняем.

Просто помню время, когда данные грузились в недрах каких-то функцих и этого нельзя понять, пока не просмотришь ВСЁ.

[Lewigh]

Runtime async

Наверное, вы уже слышали о runtime async, даже есть отличная статья на Хабре. Если коротко, это позволит создавать легковесные асинхронные задачи, как горутины в Go, управление которыми ляжет на рантайм, без нагрузки на потоки ОС.

Боюсь Вы не до конца поняли как статью так и механику.

В указанной Вами статье:

Для реализации Async2 были рассмотрены два подхода: размотка стека (tasklets, stack unwindind) и JIT-сгенерированные машины состояний (continuations, JIT State Machine). Подход на основе JIT оказался предпочтительным благодаря лучшей совместимости с текущей инфраструктурой .NET, меньшим накладным расходам и более высокой производительности в большинстве сценариев. Размотка стека, хотя и поддерживает сложные конструкции, такие как byref и span, оказалась менее практичной из-за увеличения времени пауз сборки мусора и сложности реализации.

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

Без преувеличения, самая ожидаемая фича, которая позволит C# выбить главный козырь из рукава Go.

Ничего никто выбивать не пытаеться, у .Net итак все очень хорошо и никаких козырей у Go нет. В .Net, JVM и Go у каждого свой подход к решению проблемы, со своими плюсами и минусами.

К примеру для виртуальных потоков Java главная задача была - это безболезненно мигрировать огромное количество проектов. Для Go - создать шайтан машину которое позволит разработчикам вообще не грузить голову по поводу управления задачами в среднем по больнице. Для C# - это - наглядность и управляемость.

[Ydav359]

Спасибо за замечание, учту!

[iamkisly]

С нетерпением жду статью "Как поменяется .NET и C# в ближайшие годы В РОССИИ ?" потому что пока что весь локальный рынок захватили java и go стеки, и шарп остался какой-то нишевой штукой на грани легаси, где только Dodo и Ozon мейнстримно поддерживают его

[Zufir]

Я работаю в банке. Крупном. У нас тут много C#. Сейчас вот с 8 на 10 переходим потихоньку. Так что не все так печально.

[Spearton]

В рф в принципе не так уж и много вакансий с НЕ легаси, в сравнении с другими рынками, а всякие сберы и яндексы несут мусорные технологии (например у яндекса это приложения на электроне или другом подобном фреймворке, вместо нормальных кроссплатформенных приложений)

[Mikle2024]

Я полный профан в разработке, хоть мне и легко давались практика и теория C# несколько лет назад. Все Испортил ИИ, какой самый сладкий чит для новичков. Но в одном я уверен точно, никогда в точных дисциплинах не побеждала гуманитарная лабузня, как долго не хвалили питон за его простоту и кучу фичей, это та же лобузня, которая со временем погаснет, а группа С будет развиваться дальше. Разве что позаимствует какие то мелкие элементы из ушедшего в древность питона, или GO. На мой взгляд такие языки, как заплатки на штаны, которые нужно срочно подлатать, пройдет время и все придут к мнению что они устарели. Таких заплаток будет еще оченьмного. А группа С языков, это как манекен, который постепенно из квадратного безформенного скелета превращается в полноценный живой образ на протяжении десятков лет. Именно точность процессов под капотом дают тот самый непревзрйденный звук двигателя у известного бренда. А эти заплатки звучат как копии китайских авто, все красиво и дорого но чувствуется где-то подвох.

[miklin-ag]

Разные языки используются для разных же целей. А ваша "группа C языков", это кажется вообще что-то из эзотерики - не понятно, почему вы в одну кучу сложили C и C#

[Nagg]

В C# любая рекурсия (т.е. вызов функцией самой себя) требует O(n) памяти только для стека

Это не так, JIT компилятор где сможет, прекрасно расставляет тейл коллы сам (а в очень редких ситуациях может даже развернуть в цикл). tail. prefix который использует F# это больше как обязательное требование к рантайму, в духе "мне все равно как, сделай тут tail call, в случае если быстрый (имплицитный) тейл-колл нельзя вставить, джиту придется вставлять специальный хелпер колл от чего будет удар по перфу.

Я не думаю что есть хоть какие шансы на появление этого в синтаксисе C#, хз зачем вы его тут перечислили.

[navferty]

Вот тоже, помню ещё лет 5 назад экспериментировал с рекурсией. Если компилировать метод с рекурсивным вызовом в последней инструкции в Release конфигурации, то реально он компилируется как цикл.

В этом можно убедиться, если намеренно сделать рекурсию бесконечной. Переполнения стека не происходит, и программа крутится бесконечно (в отличие от Debug mode, где stack overflow exception происходит практически сразу после запуска).