Если сравнивать с Kotlin, то здесь работает тот же принцип, что помог C# стать лучше Java: когда язык проектировали не было легаси и можно было спокойно скопировать удачные решения Java, а неудачные - исправить. Сейчас те же nullable reference types пришлось костылить потому что нельзя просто так исправить всю систему типов. + фичей в языке уже так много, что приходится очень аккуратно выбирать, что добавить, а что нет. Вообще будет забавно, если в какой-то момент C# устареет как Java и появится Kotlin от CLR, но пока вот не видно, чтобы Kotlin совсем уж Java похоронил. Многие считают, что Java 17 даже предпочтительнее Kotlin. Так что поживем - увидим.
Я знаю как устроен async/await внутри. Я о том, что без переписывания байткода в CPS будет две модели программирования: синхронна и асинхронная и придется держать в голове 100500 операторов Rx. В случае с await все это уезжает за кулисы, а код выглядит синхронным.
Если @Asynchronous - это оно, то Future же придется писать через .then.then.then в promise-стиле. async/await завезли ровно, чтобы этого избежать.
А можете дать ссылку на @asynchronous?Я не представляю как аннотацией синхронный IO на асинхронный изменить. Project Loom вроде собирается такое делать, но это ж сколько байткода переписывать… Касательно «привыкли»: привыкли же не значит, что это хорошее решение, просто за неимением альтернатив. Не подумайте, некоторые вещи в Java мне нравятся больше, чем в .NET, но работа с бд в этот список не входит.
Ну есть такой момент… многие уже начали говорить, что C# идёт по кривой дорожке C++. Однако команда C# тратит просто очень много времени на дизайн и анализ. Будьте уверены, что все новые фичи продумываются от и до.
Кажется, вы меня тролите:) Ну не просто так же запретили после плюсов множественно наследование везде. Получается, всем понятно зачем запретили, вам непонятно.
А как джависты про Котлин вообще: с удовольствием переходят или есть те, кто "фу-фу-фу эти ваши лямбды, сложна-сложна непонятна, лучше уж на восьмерочке оставаться"? Понятно, что люди разные, но если взять среднюю температуру по больнице?
Может завезут короткие конструкторы из рекордов в обычные классы и тогда get; set; тоже можно будет опускать. В Kotlin же справились с этой задачей. Вообще будет прикольно, если C# начнет тырить фичи из Kotlin - языка, который изначально тырил фичи в т.ч. из C#.
Если сравнивать с Kotlin, то здесь работает тот же принцип, что помог C# стать лучше Java: когда язык проектировали не было легаси и можно было спокойно скопировать удачные решения Java, а неудачные - исправить. Сейчас те же nullable reference types пришлось костылить потому что нельзя просто так исправить всю систему типов. + фичей в языке уже так много, что приходится очень аккуратно выбирать, что добавить, а что нет. Вообще будет забавно, если в какой-то момент C# устареет как Java и появится Kotlin от CLR, но пока вот не видно, чтобы Kotlin совсем уж Java похоронил. Многие считают, что Java 17 даже предпочтительнее Kotlin. Так что поживем - увидим.
Я про C#
А вот и ссылка. Обещанного, как говорится, три года ждут.
Я знаю как устроен async/await внутри. Я о том, что без переписывания байткода в CPS будет две модели программирования: синхронна и асинхронная и придется держать в голове 100500 операторов Rx. В случае с await все это уезжает за кулисы, а код выглядит синхронным.
Если @Asynchronous - это оно, то Future же придется писать через .then.then.then в promise-стиле. async/await завезли ровно, чтобы этого избежать.
А можете дать ссылку на @asynchronous?Я не представляю как аннотацией синхронный IO на асинхронный изменить. Project Loom вроде собирается такое делать, но это ж сколько байткода переписывать… Касательно «привыкли»: привыкли же не значит, что это хорошее решение, просто за неимением альтернатив. Не подумайте, некоторые вещи в Java мне нравятся больше, чем в .NET, но работа с бд в этот список не входит.
Все так: static abstract и static sealed. Подмешивать поведение можно, мутировать стейт и создавать неочевидные цепочки наследования нельзя.
Ну есть такой момент… многие уже начали говорить, что C# идёт по кривой дорожке C++. Однако команда C# тратит просто очень много времени на дизайн и анализ. Будьте уверены, что все новые фичи продумываются от и до.
Посмотрите proposal champion на гите. Там достаточно подробно описано.
Прикольно. Не видел раньше. Но без лямбдочек:))
Кажется, вы меня тролите:) Ну не просто так же запретили после плюсов множественно наследование везде. Получается, всем понятно зачем запретили, вам непонятно.
Смотрим "На плечах гигантов" Бреслава. Там почему в Kotlin не стало трейтов. На гитхабе в issue C# тоже аргументы против трейтов приведены.
Чтобы не разбираться в цепочке наследования в случае полиморфизма, очевидно
А как джависты про Котлин вообще: с удовольствием переходят или есть те, кто "фу-фу-фу эти ваши лямбды, сложна-сложна непонятна, лучше уж на восьмерочке оставаться"? Понятно, что люди разные, но если взять среднюю температуру по больнице?
В бесплатном Identity Server плохая обработка ошибок внутри к сожалению...
Раньше игрушки радовали. А сейчас как-то не очень
Да нормас. Там же стейт не наследуется. Так что все ок
множественным наследованием
Я буду еще как. Это ж тайпклассы почти. Супер-нужная мега-недооцененная фича. Дайте еще улучшеный вывод типов для generic'ов и abstract sealed.
А static в интерфейсах тоже не впечатляет? Или логика такая, что они не успеют похоже его запилить и он в превью останется?
Может завезут короткие конструкторы из рекордов в обычные классы и тогда get; set; тоже можно будет опускать. В Kotlin же справились с этой задачей. Вообще будет прикольно, если C# начнет тырить фичи из Kotlin - языка, который изначально тырил фичи в т.ч. из C#.