Ну то, что товращ Апач говорил именно об этом. Ильмир говорил не об этом. И тут я его полностью поддерживаю, хотя считаю, что котлин более функциональный, чем объектный язык.

Да сколько угодно. Волновая функция. Там идеальные синусы.

Начиная с определённого момента, котлин начинает форсить в вашу кодовую базу анемичную модель. Это не плохо и не хорошо, это просто следствие того, что он принял некоторые функциональные подходы и перевел фокус с действий на данные. Котлинисты теперь больше стали думать не над тем, как декораторы раскидать, а как по коллекции красиво пройтись, вот что-то из этого рода. В некотором смысле это можно назвать идиоматическим кодом.
Но тащить разные фичи в язык и называть их идиомами - это путь к тому, что Set.filter возвращает лист, юзеры постоянно спотыкаются на корнер-кейсах, полгода переезжают с Ркса на корутины, а библиотекописари в замешательстве пытаются абстрагироваться над как раз suspend-ом. Фичи в языке должны синергировать.
ХКТ - это не какая-то прихоть, и даже не идиома. Это логичное развитие любого языка с дженериками, потому что раз вы параметрически полиморфны по значениям, будьте добры быть параметрически полиморфными и по оберткам, иначе вы привязываетесь к бесконечному числу частных случаев.
И втаскивание фич в язык "по необходимости", а не "по задумке" - это, кстати, и есть С++ вей. Вот юзер споткнулся на каком-то кейсе, накатал пропозал, ему решили его проблему очередной фичей, отлично. Что это за фича? Будет ли она синергировать с другими? Нужна ли она другим юзерам? Какой мне толк от делегейтед пропертей, если команда крутит пальцем у виска, не понимая, что здесь написано?
Язык должен стремиться к тому, чтобы максимальное количество вещей можно было выразить на нём же, не открывая ютрек, иначе он всегда превратится в С++. Тут кстати и про суспенды - им необязательно быть частью компилятора, в пресловутом хаскеле почти такие же корутины реализованы на уровне библиотеки через ХКТ и монады и не отличаются от всего остального кода в смысле каких-то специальных ключевых слов или чего-то в этом роде.
Короче, если котлин-вей - обсуждать в пропозалах "а кому это надо" и "не сломает ли нам это что-нибудь", то увидимся через пять лет в паблике с мемами, где котлин будут сравнивать с плюсами. Если, конечно, язык выдержит такое многообразие взаимномешающих фич и вообще сможет развиваться

Ну то, что товращ Апач говорил именно об этом. Ильмир говорил не об этом. И тут я его полностью поддерживаю, хотя считаю, что котлин более функциональный, чем объектный язык.

Струны блять

Начиная с определённого момента, котлин начинает форсить в вашу кодовую базу анемичную модель. Это не плохо и не хорошо, это просто следствие того, что он принял некоторые функциональные подходы и перевел фокус с действий на данные. Котлинисты теперь больше стали думать не над тем, как декораторы раскидать, а как по коллекции красиво пройтись, вот что-то из этого рода. В некотором смысле это можно назвать идиоматическим кодом.
Но тащить разные фичи в язык и называть их идиомами - это путь к тому, что Set.filter возвращает лист, юзеры постоянно спотыкаются на корнер-кейсах, полгода переезжают с Ркса на корутины, а библиотекописари в замешательстве пытаются абстрагироваться над как раз suspend-ом. Фичи в языке должны синергировать.
ХКТ - это не какая-то прихоть, и даже не идиома. Это логичное развитие любого языка с дженериками, потому что раз вы параметрически полиморфны по значениям, будьте добры быть параметрически полиморфными и по оберткам, иначе вы привязываетесь к бесконечному числу частных случаев.
И втаскивание фич в язык "по необходимости", а не "по задумке" - это, кстати, и есть С++ вей. Вот юзер споткнулся на каком-то кейсе, накатал пропозал, ему решили его проблему очередной фичей, отлично. Что это за фича? Будет ли она синергировать с другими? Нужна ли она другим юзерам? Какой мне толк от делегейтед пропертей, если команда крутит пальцем у виска, не понимая, что здесь написано?
Язык должен стремиться к тому, чтобы максимальное количество вещей можно было выразить на нём же, не открывая ютрек, иначе он всегда превратится в С++. Тут кстати и про суспенды - им необязательно быть частью компилятора, в пресловутом хаскеле почти такие же корутины реализованы на уровне библиотеки через ХКТ и монады и не отличаются от всего остального кода в смысле каких-то специальных ключевых слов или чего-то в этом роде.
Короче, если котлин-вей - обсуждать в пропозалах "а кому это надо" и "не сломает ли нам это что-нибудь", то увидимся через пять лет в паблике с мемами, где котлин будут сравнивать с плюсами. Если, конечно, язык выдержит такое многообразие взаимномешающих фич и вообще сможет развиваться

Это другое

Ну то, что товращ Апач говорил именно об этом. Ильмир говорил не об этом. И тут я его полностью поддерживаю, хотя считаю, что котлин более функциональный, чем объектный язык.

> полгода переезжают с Ркса на корутины, а библиотекописари в замешательстве пытаются абстрагироваться над как раз suspend-ом. Фичи в языке должны синергировать.
У меня такое ощущение, что ты до сих пор не понял, зачем в язык вводились корутины. suspend-функция, конечно, аналогична Single-у из рыкса, но от того, что ты спрячешь и рыкс, и саспенд за эф-дыркой, ты всю суть корутин теряешь. Никакого смысла нет их в дырку совать.

++

Ты померял экспериментально это до какой степени

Когда то ньютоновская физика была дофига окончательным решением, как и теплород с флогистоном

Животное электричество

Не теряю. Тебе же все равно где-то нужно в дырку что-то засунуть и у тебя все равно где-то будет код на корутинах