Тело больших размеров издаёт более низкие звуки (например слон или водопад). А тело меньших размеров издаёт более высокие звуки (мышь или журчание ручейка).
Даже лягушка понимает что всё большое это плохо, оно потенциально опасно. Всё маленькое хорошее, его можно съесть. Мозг соотносит большую и малую терции в мелодии с положительными и отрицательными эмоциями по такому же принципу, это заложено на уровне рефлексов.
а ноты совпадающие с более тихими гармониками звучат "неприятно", "диссонансно".
Да-да, в интервале самом по себе это так. Вопрос только в том, почему внезапно в sus-аккордах эти большие секунды начинают звучать нейтрально?
Соль-бемоль мажор и фа-диез мажор энгармоничны и формально оба имеют право на существование. Бемольные тональности предпочитают на практике ровно потому, что это удобнее - позволяет избежать дубль-диезов. Ещё я не эксперт, но что-то мне подсказывает, что в натуральных строях они могут слегка отличаться (поправьте, пожалуйста, знающие люди).
Странная аргументация. Тогда секса и септима должны звучать прямо архивесело? А на деле они звучат как соответсвующие им терции и секудны, для которых они являются обращениями. А почему малая/большая децимы выполняют ту же гармоническую функцию, что и малая/большая терции? А секунды звучат не грустно, а просто неприятно, но при этом аккорд sus2 звучит нейтрально, не грустно и не весело, как мажорное или минорное трезвучие. А что там с септ-аккордами, которые не звучат диссонантно, но внутри у них затоился тритон? И вообще, обычно всё же говорят "малая и большая секунда/терция/секста/септима", а не "мажорная/минорная".
Ну и ещё надо напомнить, что помимо натурального мажора и минора есть ещё очень много разных звукорядов, каждый имеет свой окрас, и не всегда его можно характеризовать как "грустный" и "весёлый".
Отличная статья! Но мне кажется, в рассуждения закралась одна неточность: предполагается, что в программах часто вызываются функции, и поэтому количество регистров нельзя увеличивать. А на деле не так, потому что функции вызываются редко, т.к. в большинстве случаев инлайнятся. В современных реалиях даже рамки obj-файла не являются помехой из-за link-time кодогенерации (ну а в случае сред вроде JVM проблемы вообще нет by design). Большие объёмы памяти, большие кэши, большие ресурсы для компилятора позволяют инлайнить очень агрессивно, и это как правило идёт на пользу, причём не столько из-за того, что реже делаются вызовы, а из-за того, что инлайнинг как правило даёт возможности для межпроцедурных оптимизаций, которые таким образом делаются гораздо проще и эффективнее.
Свобода - понятие слишком философское и слишком размытое, так что обсуждать, где сколько свободы - это заведомо холиваное и неблагодарное событие. Хотя я и соглашусь, что в большинстве европейских стран свободы "больше" (если вообще можно применять понятия больше/меньше к свободе), чем в России. Однако, разговор шёл не про это, а про прогнозы по поводу свободного хождения валюты и возможности граждан выезжать за пределы РФ. Так вот это понятия вполне конкретные. А вот делать прогнозы даже по столь конкретным вещам - это занятие неблагодарное. Я всего лишь указал на то, что нельзя такие прогнозы делать с достаточной степенью достоверности, и уж тем более нельзя обвинять в недальновидности тех, кто не разделяет пессимизма автора комментария. Минус вам за категоричность и провокацинность комментария.
Давно - это года два. Я и говорю: пандемия всё очень изменила. До коронавируса, да даже в первые месяцы, за 150К евро (это что-то в районе 10М рублей) вполне можно было купить просторную двушку в сталинке. Ну или что-то на Фрунзенской, Новочеркасской или на Ваське сравнительно недалеко от цивилизации (а не на намывах), даже на Петроградке. Или у Охты. Но мои выкладки про "купить квартиру тут выгоднее" относятся к тем, кто уже успел купить 2-5 лет назад. Может, планируй я покупку жилья вот прямо сейчас, может и подумал бы о переезде в Германию.
Говоря, что то на то и выходит, я больше имел ввиду покупательную способность ИТ петербуржца для покупки квартиры в СПб за 200к€, и тоже самое для Берлинца и перегретой квартиры в 700к.
Это если говорить про среднего петербуржца и среднего берлинца. А в IT дела обстоят так, что в СПб люди зарабатывают почти так в Берлине. По крайней мере, мне так казалось. senior java developer сейчас зарабатывает в районе 250К рублей. При текущем курсе - это 3К евро. senior java developer в Берлине, насколько мне известно (но я могу и заблуждаться) зарабатывает в районе 70-80К евро. Минус налоги, получится 40-50К евро в год. Делим на 12, получится те же 3.5-4К в месяц на руки.
Думал также, что программисты в общем не глупые люди и должны понимать чем все это закончится.
А чем это закончится, мы не знаем, пока не изобрели машину времени или другие способы достоверного предсказания будущего. Может, будут дальше ужесточаться меры, может нет. Может, будут ужесточаться, но до какого-то предела. Тут можно только гадать, и часто это вопрос конкретного мнения. Не все разделяют такой вот пессимизм, поэтому нельзя так категорично говорить, что "только слепой не видит куда катится РФ".
Приведённая цена в 150К в Питере - это уже не уровень панельки на отшибе, это уже что-то посерьёзнее (в частности, если не нравятся кирпично-монолитные новостройки, можно за такие деньги рассмотреть сталинку). Хотя ковид очень сильно всё поменял, и сейчас цены раза в полтора скакнули.
Зачем senior developer-у с его почти европейской зарплатой брать квартиру стоимостью в 150К евро в ипотеку на 30 лет, если она при таком раскладе выплачивается лет за 10 максимум (мы же не дураки, чтобы не накопить хоть какого-нибудь первоначального взноса)?
Дело даже не в налогах. Дело в том, что цены на квартиры в каком-нибудь Мюнхене начинаются от условных 500К евро, а в Питере за какие-нибудь жалкие 150К евро (в доковидные времена, сейчас всё сильно поменялось) можно купить что-то приличное в не очень многоэтажном недалеко от центра. При этом и сама ипотека быстрее платится, т.к. в целом дешевле жизнь. При этом работая из России можно получать почти европейские зарплаты. Я понимаю, что при этом в Германии несравнимо лучше городская среда, но в ней я просто не имею выбора: либо покупай квартиру по конским ценам, либо не покупай вовсе. Мне известны контраргументы: да кто же в Германии живёт в своём жилье? Ну не знаю, меня, например, очень заботит вопрос, где я буду жить после пенсии. Хотелось бы в этом вопросе чуть больше понадеяться на свои силы, а не делегировать это государству.
Всё-таки разработчики — профессия, в которой национальность, родной язык и прочие подобные вещи значения почти не имеют. Опыт, скиллы и амбиции — вот что главное.
Вот не знаю, совсем не могу согласиться! Я не работал в других отраслях и не могу про них судить - может там всё в разы хуже. И не работал прямо в других странах. А так, в уютной айтишечке если работаешь с иностранными коллегами и всего лишь переписываешься/перезваниваешься с ними, тоже чувствуются национальные особенности, менталитет. Не то, чтобы это было какой-то непреодалимой проблемой, но тем не менее дискомфорт ощущается и при прочих равных работать с русскими коллегами в разы проще.
Всё так. У меня по этому поводу как раз синдром самозванца. Мне постоянно присылают непрошенные вакансии на Java/Kotlin (и почему-то даже .NET) senior developer. Я читаю список требований и понимаю, что вообще мои текущий знания нерелевантны. И что мне делать, если меня внезапно попрут с текущего места? Остаётся только надеяться, что рано или поздно я выйду на людей, которых впечатлит мой опыт и мои скилы и которые поверят, что вспомнить Spring, которого я лет 8 уже не трогал, я быстро смогу. Но учитывая конвейер найма, не думаю, что это случится прямо совсем быстро. Останется мне с апломбом приходить и заявлять, что я синиор и продаю не знания какого-то там фреймворка, а общеинженерные навыки. Интересно, вот действительно, что важнее: понимать, как в очередном фреймворке используются корутины Kotlin или глубокое понимание устройства этих самых корутин и причин именно такого их дизайна в языке и рантайме языка?
Ещё такой момент, что в любом случае в каждой компании есть своя культура, своя специфика. В неё всё равно придётся вникать, и порой там пласты будут побольше, чем просто разобраться в каком-нибудь стеке. Так что совокупный вклад стека в онбординг будет не таким уж большим.
Конечно, это работает, если человек переходит с бэкэнда на бэкэнд - стеки хоть и разные, но общие подходы в принципе уже давно отработаны и ничего принципиально нового так же не то, чтобы очень много появляется. А вот с бэкэнда на фронтэнд перейти или вообще попасть в бэкэнд из чего-то где нет такого разделения (например, из разработки компиляторов) будет сложнее, т.к. нет понимания, какие задачи возникают и какие бывают подходы к их решению.
И главное: вот нанимаешь такой человека с хорошим резюме. И вещи он правильные на собеседовании говорит. А как нанимаешь - он сидит и пишет комментарии на Хабре ничего не делает. Так что в этом смысле конкретный стек вообще вещь не принципиальная.
Это ещё поправят, думаю, компилятор ещё неплохо так оптимизируют
Увы, но нет. Пока с самой спекой wasm не сделают чего-то, никакой оптимизатор погоды не сделает. Есть множество причин, почему код wasm работает медленно, например:
При любом доступе к куче делается bound check. Это в какой-то степени компенсируется оптимизатором, но очень часто у оптимизатора просто не хватает информации, чтобы понять, что проверку можно убрать
В Wasm нельзя получить указатели на локальные переменные. Это значит, что если вы пишете код: "int a = 0; foo(&a);", то, кроме небольшого числа тривиальных кейсов, которые может распознать оптимизатор, копилятору придётся запрятать a в shadow stack, что и само по себе не быстро, а учитывая, что shadow stack находится в куче, доступ к которой проверяется, выходит совсем уж печально
В Wasm нельзя походить по стеку. Это серьёзно ограничивает возможности по эффективной реализации GC и исключений. Что GC, что исключения, уже давно обещают, но воз и ныне там. И судя по черновикам, тот же GC (точнее, модель "кортежей") получится куцым и малопригодным для реальных нужд. С исключениями ситуация вроде получше (мне и черновик больше нравится, и шансов у него добраться до финальной спеки выше), так что возможно в каком-то обозримом будущем для кода на C++, активно использующем исключения, мы действительно увидим существенный прирост производительности.
В Wasm нельзя делать трюки с memory protection, которые так же можно использовать, чтобы генерировать segfault при разыменовании нулевого указателя или переполнении стека.
Ваша методика бенчмаркинга не выдерживает никакой критики. Движкам с JIT необходимо прогреться, собрав статистику по выполнению кода и затем оптимизировав его. Соответственно, перед замерами тестируемый код надо погонять в цикле. Далее, сам замеряемый код так же необходимо прогнать несколько раз. То же самое желательно делать и с Wasm, т.к. никто не гарантирует, что конкретная среда не делает JIT. Далее, сам код - нарочито неоптимальный. По сути вы тут тестируете как быстро среда делает вызовы функций. Было бы интереснее что-то повнушительнее: рейтрейсинг, deflate, компиляция C, физический движок. Я понимаю, что для вводной статьи это слишком страшные вещи, так что хотя бы можно было потестировать на трёх версиях fib: вашей (рекурсивная, экспоненциальная сложность), рекурсивная с мемоизацией, итеративная.
Реально же проекты, где необходима мультиплатформенность с единой кодовой базой, в природе не встречаются.
Ну почему же. Вот, например. Правда, кросплатформенность и без Kotlin бывает, на обычной Java. Для iOS был MOE, а сейчас GraalVM. На Android и на сервере нативно работает. На web — TeaVM. Правда, на сервере не надо запускать весь код клиента, достаточно только части, отвечающей за OT.
Очень интрузивное и тяжелое изменение, которое заставляет код выполняться совсем не так, как написано, разрезая сверху до самого основания ваш код на suspendable и не-suspendable. Loom гораздо более элегантен и прозрачен.
Думаю, некорректно сравнивать корутины и Loom. Корутины — это языковой механизм, который позволяет в том числе на уровне языка легко запилить аналог Loom. Но не обязательно их для этого использовать. Например, с их помощью можно делать генераторы последовательностей.
Мутабельные данные — отличный способ отстрелить себе задницу, ящитаю.
Ахаха, вы это скажите сотрудникам Kotlin team, которые ловеринги пишут не путём "я пересоздам все IR элементы от рута до текущего элемента", а путём старого доброго изменения мутабельного свойства. Думаете, они там дураки сидят, которые не знают всех преимуществ иммутабельных данных и не могут в ФП? Боюсь, если бы они делали IR иммутабельным, kotlinc работал ещё раз в 100 дольше, чем он работает сейчас.
Ну а раз в любом случае это будет POJO с final-полями, то отчего бы не обмазать его префиксом data и не получить сахарок в виде copy-метода?
Так если это иммутабельный класс, то бога ради. Я просто вижу, как на вполне мутабельных расставляют. Впрочем, в Kotlin не всё так хорошо с иммутабельностью. Вот вам маленькая задачка от меня. Что выведет следующий код?
fun main() {
val trollList = mutableListOf(1)
val a = A(foo = trollList)
val s = mutableSetOf(a)
trollList += 2
s -= a
println(s)
}
data class A(val foo: List<Int>)
Как так, мы столько сил вложили в изучение джавы, стали синьорами, а нам тут говорят, что какой-то котлин лучше, чем наша дорогая джава?
Синьоры стали синьорами не потому, что все свои 10-15 лет в индустрии потратили на изучение синтаксиса и идиом конкретно взятого языка. Они изучали такие вещи как:
Несколько других языков, хотя бы на базовом уровне. JS, чтобы что-то на фронте быстро подправить, не дожидаясь фронтэдеров (а то и вообще стали сами full stack). C++, чтобы написать performance critical код. C#, потому что в своё время успели на несколько лет переметнуться в .NET.
Обширный набор фреймворков и библиотек для языка (стандартная библиотека Java, Spring, Hibernate, Jackson, log4j и т.д.)
Базовые алгоритмы, структуры данных, паттерны, архитектура корпоративных приложений, объектно-ориентированный дизайн, принципы (SOLID, YAGNI, KISS, причём умение их использовать/не использовать на практике)
Хотя бы общее знание предметной области (не одной).
Инструменты для разработке на языке: отладка, профилирование, сборка, развёртывание.
Что приходится из этого проапдейтить при переходе с Java на Kotlin? Синтаксис. Ну может пару библиотек специально для Kotlin написанных посмотреть (ktor, exposed). Ну может научиться подключать модули к Spring, которые нужны для облегчения жизни Kotlin-истам. Ну просмотреть быстренько стандартную библиотеку Kotlin, увидеть, что она почти один-в-один является подмножеством стандартной библиотеки Java, плюс несколько расхождений (Sequence вместо Stream), плюс горстка удобств. Ну какие-то идиомы, которых нет в Java. Профайлеры те же. Отладчик тот же. Maven и Gradle те же. Поверьте, человеку с опытом в 10-15 лет в отрасли, всё указанное не так долго изучить. Вот перейти с Java на C++ или с Java на Python сложно. С Java на Haskell ещё сложнее.
благодаря этому они больше отвечают семантике "я строка в базе данных/элемент в очереди".
ИМХО, data классы и record-ы совсем не для этого были созданы. Как раз для строк в БД очень редко нужна специфическая семантика equals. Лично я считаю, что data class нужны ровно в двух ситуациях:
Объявить иммутабельные штуки вроде Color, Vector2/Vector3, Rect, Point, Complex и т.д.
Объявить кастомный составной ключ для Map/Set в случае, если Pair/Triple по какой-то причине не устраивают.
Собственно, поэтому мне на практике приходилось использовать data class-ы ОЧЕНЬ редко. Не понимаю, почему все бездумно лепят модификатор data на всякие DTO и entity (особенно на DTO)? Потому что есть ассоциация "данные == data"?
Цитирую вам вас же:
Да-да, в интервале самом по себе это так. Вопрос только в том, почему внезапно в sus-аккордах эти большие секунды начинают звучать нейтрально?
Соль-бемоль мажор и фа-диез мажор энгармоничны и формально оба имеют право на существование. Бемольные тональности предпочитают на практике ровно потому, что это удобнее - позволяет избежать дубль-диезов. Ещё я не эксперт, но что-то мне подсказывает, что в натуральных строях они могут слегка отличаться (поправьте, пожалуйста, знающие люди).
Странная аргументация. Тогда секса и септима должны звучать прямо архивесело? А на деле они звучат как соответсвующие им терции и секудны, для которых они являются обращениями. А почему малая/большая децимы выполняют ту же гармоническую функцию, что и малая/большая терции? А секунды звучат не грустно, а просто неприятно, но при этом аккорд sus2 звучит нейтрально, не грустно и не весело, как мажорное или минорное трезвучие. А что там с септ-аккордами, которые не звучат диссонантно, но внутри у них затоился тритон? И вообще, обычно всё же говорят "малая и большая секунда/терция/секста/септима", а не "мажорная/минорная".
Ну и ещё надо напомнить, что помимо натурального мажора и минора есть ещё очень много разных звукорядов, каждый имеет свой окрас, и не всегда его можно характеризовать как "грустный" и "весёлый".
А что за компилятор?
Отличная статья! Но мне кажется, в рассуждения закралась одна неточность: предполагается, что в программах часто вызываются функции, и поэтому количество регистров нельзя увеличивать. А на деле не так, потому что функции вызываются редко, т.к. в большинстве случаев инлайнятся. В современных реалиях даже рамки obj-файла не являются помехой из-за link-time кодогенерации (ну а в случае сред вроде JVM проблемы вообще нет by design). Большие объёмы памяти, большие кэши, большие ресурсы для компилятора позволяют инлайнить очень агрессивно, и это как правило идёт на пользу, причём не столько из-за того, что реже делаются вызовы, а из-за того, что инлайнинг как правило даёт возможности для межпроцедурных оптимизаций, которые таким образом делаются гораздо проще и эффективнее.
Свобода - понятие слишком философское и слишком размытое, так что обсуждать, где сколько свободы - это заведомо холиваное и неблагодарное событие. Хотя я и соглашусь, что в большинстве европейских стран свободы "больше" (если вообще можно применять понятия больше/меньше к свободе), чем в России. Однако, разговор шёл не про это, а про прогнозы по поводу свободного хождения валюты и возможности граждан выезжать за пределы РФ. Так вот это понятия вполне конкретные. А вот делать прогнозы даже по столь конкретным вещам - это занятие неблагодарное. Я всего лишь указал на то, что нельзя такие прогнозы делать с достаточной степенью достоверности, и уж тем более нельзя обвинять в недальновидности тех, кто не разделяет пессимизма автора комментария. Минус вам за категоричность и провокацинность комментария.
Давно - это года два. Я и говорю: пандемия всё очень изменила. До коронавируса, да даже в первые месяцы, за 150К евро (это что-то в районе 10М рублей) вполне можно было купить просторную двушку в сталинке. Ну или что-то на Фрунзенской, Новочеркасской или на Ваське сравнительно недалеко от цивилизации (а не на намывах), даже на Петроградке. Или у Охты. Но мои выкладки про "купить квартиру тут выгоднее" относятся к тем, кто уже успел купить 2-5 лет назад. Может, планируй я покупку жилья вот прямо сейчас, может и подумал бы о переезде в Германию.
Это если говорить про среднего петербуржца и среднего берлинца. А в IT дела обстоят так, что в СПб люди зарабатывают почти так в Берлине. По крайней мере, мне так казалось. senior java developer сейчас зарабатывает в районе 250К рублей. При текущем курсе - это 3К евро. senior java developer в Берлине, насколько мне известно (но я могу и заблуждаться) зарабатывает в районе 70-80К евро. Минус налоги, получится 40-50К евро в год. Делим на 12, получится те же 3.5-4К в месяц на руки.
А чем это закончится, мы не знаем, пока не изобрели машину времени или другие способы достоверного предсказания будущего. Может, будут дальше ужесточаться меры, может нет. Может, будут ужесточаться, но до какого-то предела. Тут можно только гадать, и часто это вопрос конкретного мнения. Не все разделяют такой вот пессимизм, поэтому нельзя так категорично говорить, что "только слепой не видит куда катится РФ".
Приведённая цена в 150К в Питере - это уже не уровень панельки на отшибе, это уже что-то посерьёзнее (в частности, если не нравятся кирпично-монолитные новостройки, можно за такие деньги рассмотреть сталинку). Хотя ковид очень сильно всё поменял, и сейчас цены раза в полтора скакнули.
В любом случае, всё значачительно выгоднее покупать жильё в ипотеку России по ставке в 9%, чем в Германии со ставкой 2%
Зачем senior developer-у с его почти европейской зарплатой брать квартиру стоимостью в 150К евро в ипотеку на 30 лет, если она при таком раскладе выплачивается лет за 10 максимум (мы же не дураки, чтобы не накопить хоть какого-нибудь первоначального взноса)?
Дело даже не в налогах. Дело в том, что цены на квартиры в каком-нибудь Мюнхене начинаются от условных 500К евро, а в Питере за какие-нибудь жалкие 150К евро (в доковидные времена, сейчас всё сильно поменялось) можно купить что-то приличное в не очень многоэтажном недалеко от центра. При этом и сама ипотека быстрее платится, т.к. в целом дешевле жизнь. При этом работая из России можно получать почти европейские зарплаты. Я понимаю, что при этом в Германии несравнимо лучше городская среда, но в ней я просто не имею выбора: либо покупай квартиру по конским ценам, либо не покупай вовсе. Мне известны контраргументы: да кто же в Германии живёт в своём жилье? Ну не знаю, меня, например, очень заботит вопрос, где я буду жить после пенсии. Хотелось бы в этом вопросе чуть больше понадеяться на свои силы, а не делегировать это государству.
Вот не знаю, совсем не могу согласиться! Я не работал в других отраслях и не могу про них судить - может там всё в разы хуже. И не работал прямо в других странах. А так, в уютной айтишечке если работаешь с иностранными коллегами и всего лишь переписываешься/перезваниваешься с ними, тоже чувствуются национальные особенности, менталитет. Не то, чтобы это было какой-то непреодалимой проблемой, но тем не менее дискомфорт ощущается и при прочих равных работать с русскими коллегами в разы проще.
Всё так. У меня по этому поводу как раз синдром самозванца. Мне постоянно присылают непрошенные вакансии на Java/Kotlin (и почему-то даже .NET) senior developer. Я читаю список требований и понимаю, что вообще мои текущий знания нерелевантны. И что мне делать, если меня внезапно попрут с текущего места? Остаётся только надеяться, что рано или поздно я выйду на людей, которых впечатлит мой опыт и мои скилы и которые поверят, что вспомнить Spring, которого я лет 8 уже не трогал, я быстро смогу. Но учитывая конвейер найма, не думаю, что это случится прямо совсем быстро. Останется мне с апломбом приходить и заявлять, что я синиор и продаю не знания какого-то там фреймворка, а общеинженерные навыки. Интересно, вот действительно, что важнее: понимать, как в очередном фреймворке используются корутины Kotlin или глубокое понимание устройства этих самых корутин и причин именно такого их дизайна в языке и рантайме языка?
Ещё такой момент, что в любом случае в каждой компании есть своя культура, своя специфика. В неё всё равно придётся вникать, и порой там пласты будут побольше, чем просто разобраться в каком-нибудь стеке. Так что совокупный вклад стека в онбординг будет не таким уж большим.
Конечно, это работает, если человек переходит с бэкэнда на бэкэнд - стеки хоть и разные, но общие подходы в принципе уже давно отработаны и ничего принципиально нового так же не то, чтобы очень много появляется. А вот с бэкэнда на фронтэнд перейти или вообще попасть в бэкэнд из чего-то где нет такого разделения (например, из разработки компиляторов) будет сложнее, т.к. нет понимания, какие задачи возникают и какие бывают подходы к их решению.
И главное: вот нанимаешь такой человека с хорошим резюме. И вещи он правильные на собеседовании говорит. А как нанимаешь - он сидит и
пишет комментарии на Хабреничего не делает. Так что в этом смысле конкретный стек вообще вещь не принципиальная.Увы, но нет. Пока с самой спекой wasm не сделают чего-то, никакой оптимизатор погоды не сделает. Есть множество причин, почему код wasm работает медленно, например:
При любом доступе к куче делается bound check. Это в какой-то степени компенсируется оптимизатором, но очень часто у оптимизатора просто не хватает информации, чтобы понять, что проверку можно убрать
В Wasm нельзя получить указатели на локальные переменные. Это значит, что если вы пишете код: "int a = 0; foo(&a);", то, кроме небольшого числа тривиальных кейсов, которые может распознать оптимизатор, копилятору придётся запрятать a в shadow stack, что и само по себе не быстро, а учитывая, что shadow stack находится в куче, доступ к которой проверяется, выходит совсем уж печально
В Wasm нельзя походить по стеку. Это серьёзно ограничивает возможности по эффективной реализации GC и исключений. Что GC, что исключения, уже давно обещают, но воз и ныне там. И судя по черновикам, тот же GC (точнее, модель "кортежей") получится куцым и малопригодным для реальных нужд. С исключениями ситуация вроде получше (мне и черновик больше нравится, и шансов у него добраться до финальной спеки выше), так что возможно в каком-то обозримом будущем для кода на C++, активно использующем исключения, мы действительно увидим существенный прирост производительности.
В Wasm нельзя делать трюки с memory protection, которые так же можно использовать, чтобы генерировать segfault при разыменовании нулевого указателя или переполнении стека.
Ну и т.д.
Ваша методика бенчмаркинга не выдерживает никакой критики. Движкам с JIT необходимо прогреться, собрав статистику по выполнению кода и затем оптимизировав его. Соответственно, перед замерами тестируемый код надо погонять в цикле. Далее, сам замеряемый код так же необходимо прогнать несколько раз. То же самое желательно делать и с Wasm, т.к. никто не гарантирует, что конкретная среда не делает JIT. Далее, сам код - нарочито неоптимальный. По сути вы тут тестируете как быстро среда делает вызовы функций. Было бы интереснее что-то повнушительнее: рейтрейсинг, deflate, компиляция C, физический движок. Я понимаю, что для вводной статьи это слишком страшные вещи, так что хотя бы можно было потестировать на трёх версиях fib: вашей (рекурсивная, экспоненциальная сложность), рекурсивная с мемоизацией, итеративная.
Ну почему же. Вот, например. Правда, кросплатформенность и без Kotlin бывает, на обычной Java. Для iOS был MOE, а сейчас GraalVM. На Android и на сервере нативно работает. На web — TeaVM. Правда, на сервере не надо запускать весь код клиента, достаточно только части, отвечающей за OT.
Думаю, некорректно сравнивать корутины и Loom. Корутины — это языковой механизм, который позволяет в том числе на уровне языка легко запилить аналог Loom. Но не обязательно их для этого использовать. Например, с их помощью можно делать генераторы последовательностей.
Ахаха, вы это скажите сотрудникам Kotlin team, которые ловеринги пишут не путём "я пересоздам все IR элементы от рута до текущего элемента", а путём старого доброго изменения мутабельного свойства. Думаете, они там дураки сидят, которые не знают всех преимуществ иммутабельных данных и не могут в ФП? Боюсь, если бы они делали IR иммутабельным, kotlinc работал ещё раз в 100 дольше, чем он работает сейчас.
Так если это иммутабельный класс, то бога ради. Я просто вижу, как на вполне мутабельных расставляют. Впрочем, в Kotlin не всё так хорошо с иммутабельностью. Вот вам маленькая задачка от меня. Что выведет следующий код?
Синьоры стали синьорами не потому, что все свои 10-15 лет в индустрии потратили на изучение синтаксиса и идиом конкретно взятого языка. Они изучали такие вещи как:
Что приходится из этого проапдейтить при переходе с Java на Kotlin? Синтаксис. Ну может пару библиотек специально для Kotlin написанных посмотреть (ktor, exposed). Ну может научиться подключать модули к Spring, которые нужны для облегчения жизни Kotlin-истам. Ну просмотреть быстренько стандартную библиотеку Kotlin, увидеть, что она почти один-в-один является подмножеством стандартной библиотеки Java, плюс несколько расхождений (Sequence вместо Stream), плюс горстка удобств. Ну какие-то идиомы, которых нет в Java. Профайлеры те же. Отладчик тот же. Maven и Gradle те же. Поверьте, человеку с опытом в 10-15 лет в отрасли, всё указанное не так долго изучить. Вот перейти с Java на C++ или с Java на Python сложно. С Java на Haskell ещё сложнее.
ИМХО, data классы и record-ы совсем не для этого были созданы. Как раз для строк в БД очень редко нужна специфическая семантика equals. Лично я считаю, что data class нужны ровно в двух ситуациях:
Собственно, поэтому мне на практике приходилось использовать data class-ы ОЧЕНЬ редко. Не понимаю, почему все бездумно лепят модификатор data на всякие DTO и entity (особенно на DTO)? Потому что есть ассоциация "данные == data"?