В декабре Scala-комьюнити опубликовало пресс-релиз о том, что Scala 2.14 никогда не выйдет. Мартин Одерски и Ко приняли решение, что необходимо сконцентрироваться на работе над Dotty/Scala3.
Сообщество Scala программистов (в моем лице в том числе) безмерно этому радо, т.к., честно говоря, давно пора было. Scala застыло в прорывном развитии на несколько лет, что на фоне стремительного роста популярности better-java-kotlin приводило к оттоку разработчиков и даже целых компаний.
Scala3 должна стать тем самым большим скачком вперед, который вернет интерес нынешним и будущим энтузиастам ФП на JVM.
Мы получим больше всего того, что мы так любим: еще больше типобезопасности и метапрограммирования настероидахбазе полностью нового компилятора с инкрементальным режимом. Еще более краткий синтаксис.
Статус прогресса в списке вкусностей застыл в неизменном состоянии на долгое время, что должно измениться в ближайшее время, если команда Scala3 выполнит свое обещание, данное в пресс-релизе. Пока же они нам советуют рассчитывать на...
К концу 2020 обещают зарелизиться. И еще в процессе отчитываться о майл-стоунах.
С Scala 2.13.1. И общую стандартную библиотеку. Здесь нет значительных компромиссов в угоду обратной совместимости потому что на самом деле 2.13 (и несостоявшаяся 2.14) задумывались как эволюционные промежуточные шаги на пути к Scala3. Scala3, напомню, благодаря TASTy обещает вечную бинарную совместимость в будущем.
Метапрограммирование в Scala3 полностью переосмыслено. Поэтому макросы от 2.х придется полностью переписать. За подробностями отправляю сюда.
Производительность была поставлена во главу угла при разработке Scala3. Причем и при компиляции, и в рантайме. Все изменения в исходный код языка обложены тестами на регресс производительности.
Продолжится. Но все улучшения будут сначала заливаться в 3-ку, а потом при возможности портироваться обратно в 2-ку.
Предоставляется набор утилит для автоматической проверки совместимости кода к переходу на Scala3, а так же конвертации исходный файлов из 2 в 3 и обратно (!). Обещают не повторять ошибок Python'а (при переходе с 2 на 3), поломавшего всю совместимость с существовавшей кодовой базой Python2.
Команда Скалы работает совместно с разработчиками Visual Studio Code и IntelliJ IDEA. Обе уже понимают новую Скалу и обновляются параллельно с самим языком. Что не может не радовать, потому в современном мире нельзя разрабатывать языки без оглядки на IDE — ведь именно проблемы с парсингом и смертельно долгой компиляцией Scala2 привели в свое время IntelliJ к созданию своего лунапарка с блекджеком и шлюпками под названием Kotlin.
Сообщество Scala программистов (в моем лице в том числе) безмерно этому радо, т.к., честно говоря, давно пора было. Scala застыло в прорывном развитии на несколько лет, что на фоне стремительного роста популярности better-java-kotlin приводило к оттоку разработчиков и даже целых компаний.
Scala3 должна стать тем самым большим скачком вперед, который вернет интерес нынешним и будущим энтузиастам ФП на JVM.
Мы получим больше всего того, что мы так любим: еще больше типобезопасности и метапрограммирования на
Статус прогресса в списке вкусностей застыл в неизменном состоянии на долгое время, что должно измениться в ближайшее время, если команда Scala3 выполнит свое обещание, данное в пресс-релизе. Пока же они нам советуют рассчитывать на...
Сроки
К концу 2020 обещают зарелизиться. И еще в процессе отчитываться о майл-стоунах.
Бинарная совместимость
С Scala 2.13.1. И общую стандартную библиотеку. Здесь нет значительных компромиссов в угоду обратной совместимости потому что на самом деле 2.13 (и несостоявшаяся 2.14) задумывались как эволюционные промежуточные шаги на пути к Scala3. Scala3, напомню, благодаря TASTy обещает вечную бинарную совместимость в будущем.
Типобезопасное метапрограммирование
Метапрограммирование в Scala3 полностью переосмыслено. Поэтому макросы от 2.х придется полностью переписать. За подробностями отправляю сюда.
Производительность
Производительность была поставлена во главу угла при разработке Scala3. Причем и при компиляции, и в рантайме. Все изменения в исходный код языка обложены тестами на регресс производительности.
Поддержка Scala 2
Продолжится. Но все улучшения будут сначала заливаться в 3-ку, а потом при возможности портироваться обратно в 2-ку.
Миграция
Предоставляется набор утилит для автоматической проверки совместимости кода к переходу на Scala3, а так же конвертации исходный файлов из 2 в 3 и обратно (!). Обещают не повторять ошибок Python'а (при переходе с 2 на 3), поломавшего всю совместимость с существовавшей кодовой базой Python2.
Поддержка IDE
Команда Скалы работает совместно с разработчиками Visual Studio Code и IntelliJ IDEA. Обе уже понимают новую Скалу и обновляются параллельно с самим языком. Что не может не радовать, потому в современном мире нельзя разрабатывать языки без оглядки на IDE — ведь именно проблемы с парсингом и смертельно долгой компиляцией Scala2 привели в свое время IntelliJ к созданию своего лунапарка с блекджеком и шлюпками под названием Kotlin.
rfq
«Еще более краткий синтаксис.»
То есть, смысл будет еще сильнее зашифрован, чтобы профаны ничего не понимали. Я Скалу 2 не понимаю, хотя за 40 лет в программировании навидался всяких языков. Ну что ж, быть со всеми или сформировать группу избранных — каждый решает сам.
solver
Если вы не понимаете скалу, то это может означать тольку одну вещь. Вы не приложили усилия для её изучения.
Это вовсе не проблема скалы или любого другого языка, а проблема людей. Почитайте что такое парадокс Блаба, может вам станет понятнее.
slonopotamus
Это означает что у Скалы выше входной порог чем у других языков, которые понимает предыдущий комментатор. Вероятно, существенно выше. Но тут возникает вопрос — а окупится ли вкладывание необходимого для её понимания количества усилий или лучше это время потратить на изучение других штук.
Siemargl
бизнес уже ответил на этот вопрос. а сегментация на scala2 vs scala3 добьет
barbalion Автор
Синтаксис Скалы не сложный. Он похож одновременно и на тот же Kotlin, и на Python (начиная с Scala3 там будет даже контроль отступов, как в Питоне). Не говоря о том, что Java и JavaScript многие конструкции заимствуют. Если вы не понимаете исходники на Scala, то вы не понимаете ФП. А это целое семейство языков и целая парадигма, изучить которую безусловно стоит любому программисту, даже с 40летним стажем.
rfq
"Если вы не понимаете исходники на Scala, то вы не понимаете ФП."
Не понимаю из-за переусложненного синтаксиса. Разве ФП язык обязан иметь криптованный синтаксис, по иному нельзя?
И заодно вопрос лично вам как знатоку ФП: какие функциональные конструкции Скалы нельзя выразить на простой Яве?
fougasse
Грубовато у вас как-то вышло, есть же какой-то предел в укорачивании синтаксиса, тем более сейчас в эпоху автокомплита.
Хотелось бы более аргументированную позицию.
barbalion Автор
Здесь укорачивание — это чисто оптимизация. Но не в ущерб читаемости, а наоборот. Например отход от фигурных скобок (они останутся опциональными) в пользу структуры по отступам. Это уменьшает количество мест, где можно ошибиться, не ухудшая семантику. Иными словами уменьшают количество знаков пунктуации, там где без них можно обойтись.
intfox
Как по мне семантика скалы более очевидна нежели у других языков. А в дотти для многих механизмов выделили свои ключевые слова и код стал еще более очевидным.
rfq
прежде чем говорить о семантике, надо продраться сквозь синтаксис. А такие синтаксические конструкции как xs filter (pivot ==), elems = args map Integer.parseInt или loop {react {}} попросту ставят в тупик.