Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 19
Runtime async
Чёт страшно мне. На бэкендах привык разделять асинхронный и синхронный код, как код с IO и код без IO. Код без IO является ещё и чистыми функциями по возможности. Позволяет делить методы на части вида: грузим, что-то делаем, сохраняем.
Просто помню время, когда данные грузились в недрах каких-то функцих и этого нельзя понять, пока не просмотришь ВСЁ.
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# - это - наглядность и управляемость.
С нетерпением жду статью "Как поменяется .NET и C# в ближайшие годы В РОССИИ ?" потому что пока что весь локальный рынок захватили java и go стеки, и шарп остался какой-то нишевой штукой на грани легаси, где только Dodo и Ozon мейнстримно поддерживают его
Я работаю в банке. Крупном. У нас тут много C#. Сейчас вот с 8 на 10 переходим потихоньку. Так что не все так печально.
В рф в принципе не так уж и много вакансий с НЕ легаси, в сравнении с другими рынками, а всякие сберы и яндексы несут мусорные технологии (например у яндекса это приложения на электроне или другом подобном фреймворке, вместо нормальных кроссплатформенных приложений)
Я полный профан в разработке, хоть мне и легко давались практика и теория C# несколько лет назад. Все Испортил ИИ, какой самый сладкий чит для новичков. Но в одном я уверен точно, никогда в точных дисциплинах не побеждала гуманитарная лабузня, как долго не хвалили питон за его простоту и кучу фичей, это та же лобузня, которая со временем погаснет, а группа С будет развиваться дальше. Разве что позаимствует какие то мелкие элементы из ушедшего в древность питона, или GO. На мой взгляд такие языки, как заплатки на штаны, которые нужно срочно подлатать, пройдет время и все придут к мнению что они устарели. Таких заплаток будет еще оченьмного. А группа С языков, это как манекен, который постепенно из квадратного безформенного скелета превращается в полноценный живой образ на протяжении десятков лет. Именно точность процессов под капотом дают тот самый непревзрйденный звук двигателя у известного бренда. А эти заплатки звучат как копии китайских авто, все красиво и дорого но чувствуется где-то подвох.
В C# любая рекурсия (т.е. вызов функцией самой себя) требует O(n) памяти только для стека
Это не так, JIT компилятор где сможет, прекрасно расставляет тейл коллы сам (а в очень редких ситуациях может даже развернуть в цикл). tail. prefix который использует F# это больше как обязательное требование к рантайму, в духе "мне все равно как, сделай тут tail call, в случае если быстрый (имплицитный) тейл-колл нельзя вставить, джиту придется вставлять специальный хелпер колл от чего будет удар по перфу.
Я не думаю что есть хоть какие шансы на появление этого в синтаксисе C#, хз зачем вы его тут перечислили.
Вот тоже, помню ещё лет 5 назад экспериментировал с рекурсией. Если компилировать метод с рекурсивным вызовом в последней инструкции в Release конфигурации, то реально он компилируется как цикл.
В этом можно убедиться, если намеренно сделать рекурсию бесконечной. Переполнения стека не происходит, и программа крутится бесконечно (в отличие от Debug mode, где stack overflow exception происходит практически сразу после запуска).
JiT действительно может, но Roslyn просто не эмитит ему эти инструкции, потому что это меняет семантику, а оптимизации по определению не должны менять результат исполнения программы.
Мне было бы очень интересно посмотреть на примеры, которые стабильно эмитят tail call потестить
Какую именно это меняет семантику и результат программы? наличие или нет StackOverflowException? это не семантика
Мне было бы очень интересно посмотреть на примеры, которые стабильно эмитят tail call потестить
вот вам 2 примера https://godbolt.org/z/9ne5K5G16
Должен отметить, предложение о хвостовой рекурсии есть в IL (поскольку есть в F#), но было отклонено на уровне LDM. Причина: ломает стек трейс, сильно травмирует отладку, есть комментарий Мэдса на тему.
Из планов на .NET11 известны ещё closed модификатор, nullable async/foreach, развивается unsafe блок в статический анализатор как было с nullable reference types, top-level methods и ещё всякого разного по мелочи.
Так-то да, из крупных анонсов ждем Union types и Runtime async (+extension everything), но об этом уже давно известно, ещё со времён .Net9. Самое интересное как по мне происходит в нишевых гитхаб коммитах
Скоро нужно будет уточнять каким подмножеством C# ты владеешь. Стили и наборы используемых фич будут ощущаться как отдельные языки программирования.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как поменяется .NET и C# в ближайшие годы?