Комментарии 110
Dotty / Scala 3 конечно интересны. Но до их адаптации в производство не один год пройдёт.
Когда там еще релиз будет, когда еще библиотеки подтянутся, когда еще вся экосистема подтянется. И надо еще чтобы отгремели холивары по поводу их внедрения )
Питон гораздо популярнее и сколько лет прошло преждем чем значимое количество проектов на 3ю версию перешли?
Другими словами, это отдалёное будущее скалы, которое еще не факт, что настанет. Комьюнити у скалы не такое большое как у питона, неизвестно как оно переживёт этот раскол.
Так обратная совместимость есть. Почти всё, кроме макросов, будет работать.
В любом случае, даже если в своём коде всю эту экзотику не использовать — она с высокой степенью вероятности есть в используемых сторонних библиотеках. И пока их судьба в рамках новой версии языка окончательно не ясна — сохраняются и сомнения, есть ли смысл сейчас связываться с тем, что придётся через пару лет переписывать.
Да откуда у вас это мнение? Компилятор дотти уже сейчас кросс компилирует библиотеки из скалы 2. Авторы либ уже сейчас начинают переписывать части либ, где используются макросы. К релизу это всё уже будет. Имплиситов никуда не деваются. Всё старое на месте, и будет удаляться потом, через deprecation цикл.
Я со своей дилетантской точки зрения (ибо пока не разобрался в нюансах использования всех продвинутых фич, которые меняются) тоже склоняюсь к тому, что всё в итоге пройдёт гладко и языку с библиотеками суждена долгая и счастливая жизнь, — но отсутствие какой-то оценки этого вопроса в статье удивило. Не более.
Смотрим, какая у нас версия Spark: 2.2.0_cloudera4, смотрим, какая версия Scala: 2.11. Dotty (так же, как впрочем и Hadoop 3, и Spark 3.0, и Java 14) нам в ближайшее время либо вообще не светит, либо грозит огромными трудозатратами, чтобы на них мигрировать. Вот такое, оно, будущее Scala в одном отдельно взятом банке. Скушно, но жизненно.
Спарк уже сейчас работает под дотти.
Все версии, в которых поддерживается скала 2.12.
Спарк 2.2.0 вышел в июле 17 года. 3 года назад! То, что вы используете такие старых версии инструментов — не проблема инструментов или языка. Обновитесь уже на актуальную версию
А вы давно пробовали обновить кластер, работающий 24х7? В котором порядка 300 узлов, и петабайты данных? Поверьте, это далеко не так просто. Мы уже трижды пробовали обновиться на 2.3, и трижды откатывались обратно. Потому что несовместимости. Сейчас вот новый кластер собирают, на новой cloudera, и там все будет в виде спарка 2.4. Но когда мы на него переедем — вопрос очень интересный.
Но это ведь всё равно никак не связано с языком, правда? А по оригинальному сообщению прослеживается именно такая мысль.
Я скорее имел в виду, что значительному числу пользователей скалы типа меня (на самом деле пользователям спарка) — им на дотти пока приходится облизываться в лучшем случае. Мы бы и рады, и пробуем — но тяжело это идет.
И вот тут и могут сыграть опасения, что у Скалы что-то глобальное скоро будет меняться. Поэтому непонятно, насколько это (а) скажется на популярности языка и доступности разработчиков на оном на рынке и (б) на судьбе фреймворков/библиотек, которые будешь использовать. И поэтому не взять ли вместо Скалы какой-нибудь Котлин — возможностей, конечно, меньше, но поддержка Гугла, стабильность и все дела.
Вот. Например, где-нибудь можно посмотреть пример доказательства, что алгоритм умножения блочных float-матриц корректен?
Выдержка из одного поста:
Hi everyone. We have great news on the ultimate λ-calculus which will possibly lead to a next-gen compiler for Formality.
Long history: initially, we compiled Formality to interaction combinators, the Levy-optimal system everyone here knows. Sadly, inets, while asymptotically fast, are slightly inefficient in practice due to pointer gloat. A few months ago, I noticed a way to represent a subset interaction combinators in a more compact format that resembled terms, except «ill-scoped» (i.e., a lambda-bound variable can appear outside of its body). I called it the ultimate λ-calculus. It had 4 main constructors:
LAM(name, body)
APP(func, argm)
PAR(val0, val1)
LET(name0, name1, expr, body)
Afterwards, I found a very efficient way to evaluate a subset of the ultimate λ-calculus, by representing variables as pointers on LAM nodes (i.e., lambdas point to variables, not the other way around). This, together with a leftmost-innermost reduction, allowed beta-reduction to become a single array write! It is, ridiculously, 40x faster than interaction nets. It is the «fast-mode» on Formality v0.1.253. Sadly, this mode didn't allow duplications at all, only affine terms. The problem was that the order let redexes were found didn't match the leftmost-innermost reduction. This resulted in errors, since pointers would become invalid when the terms they pointed to moved. Today, I noticed that a small change on the ultimate λ-calculus could solve that issue. Instead of a let with two variables, we use a cpy with only one. That is, instead of:
let [a, b] = 42 in [a, b]
We have:
[cpy a = 42, a]
The cpy constructor injects a copy of something into another location, and then returns that thing. The result of this is that 1. the let constructor becomes smaller (from 3 to 2 fields), 2. the order it is found matches the innermost-leftmost reduction strategy, solving the problem mentioned.
I'll start immediately working in a C runtime for that new calculus and benchmark. If it works well, I'll proceed with the addition of native numbers and mutable arrays (which can be detected from types as I mentioned previously). If all turns ok, we'll have a functional runtime that is very CPU efficient, levy-optimal, non-garbage collected and with actual mutable arrays that don't need to live inside ST or other monad.
А вообще знакомые делали какой-то блокчейн на идрисе с доказуемо корректными бинарными числами, и там всё достаточно шустро работало.
Любопытно. Верно ли я предполагаю, что, как и всегда в таких случаях, код посмотреть невозможно?
О natlike компиляции мне известно, но этого «маловато будет» для производительных приложений. Ну, вот, например, речь же идёт всегда об ответственных приложениях, типа управления оборудованием, а там по техническим причинам применяются микроконтроллеры. Нужно, чтобы модель устройства влезала в маленькую память. GMP-арифметика не особо подходит для этого.
Что ждёт язык Scala дальше
Тема не раскрыта. А если её всё же раскрывать, то стоит указать на заинтересованные стороны. Если таковых нет (ну или одни лишь разработчики), то язык умрёт. А вот если за языком стоит гугл или мелкософт — язык будет жить и прирастать сторонниками.
Сегодня из всех языков будущее есть лишь у пошлого Го и у шарпованного Си, потому что за них готовы платить. А вот у остальных — будущего нет. Даже у Java, как не печально, но Оракл похоже остался один из тех, кто её хоть как-то поддерживает. И ему она не нужна. Поэтому лет через 10 ландшафт используемых языков сместится в сторону гугло-недо-языков с примесью мелкософтовых изысков.
Миром правит финансирование рекламы, а не какие-то там пристрастия разработчиков и удобства языка. Будут платить з/п выше рынка за пошлый Го — будет рост. Не будут платить — всё умрёт.
Хотя «умрёт» здесь не совсем точно отражающее реальность слово. Жизнь будет, но в летаргическом сне, как у кучи давно забытых языков, которыми на всей земле пользуется тысяча-другая человек.
Отсюда и популярность, ну, и, соответственно, сообщения об этих языках из всех сокетов всея интернета.
Если в большинстве случаев простой язык позволяет решать задачу, люди будут использовать более простой язык и рационализировать свой отказ от изучения более сложного. Мозг — ленивая штука. А в большинстве случаев простых и «пошлых» языков хватает.
Собственно, как-то так, мне кажется. Большие компании просто понимают, как это всё устроено и работает, и умеют пользоваться, иначе, они бы не смогли бы стать такими большими. У «не пошлых» языков (я так понимаю, Scala и Haskell?) стратегии захода на массовый рынок просто нету. О чём, собственно, автор статьи и пишет. Организовали бы какой-нибудь Scala Game Jam, народ бы и потянулся.
Но тут, конечно, возникает ещё один интересный вопрос: насколько велика когнитивная нагрузка Scala на программирующего? Может ли он одновременно продумывать хорошую игру и хорошую архитектуру кода на Scala? Интересный, мне кажется, вопрос. Вдвойне поэтому интересно было бы посмотреть на Scala/Haskell Game Jam.
И это при том что это вообще рандомная выборка куда попали любые вакансии где есть слово Go а таки слово Java намного больше фильтрует. Если поставить фильтры IT телеком и в названии вакансии то вообще получается 77 против 884 в пользу Java.
Мне кажется, что статья оторвана от реальности.
Начало вроде многообещающее — хорошая затравка про ниши, где scala хороша. И почти нет реакции на то, что стало с ней сейчас, причем в комментах к оригиналу это подметили.
Spark застрял со старой версией (всем миром ему помогали на 2.12 выкатываться), некоторые библиотеки еще не смогли (например, elasticsearch-hadoop). Ну и как выше писали в комментах, мигрировать не очень просто. И все больше скалу в спарке вытесняет питон.
Из ниши «better java» скалу со свистом вышвырнул котлин — а в статье про него ноль упоминаний. И у того же котлина уже есть плюс-минус рабочее решение с js и native. У скалы вроде как тоже, но котлин в этих направлениях развивается гораздо активнее. Scala-js по маргинальности примерно одинакова с хаскеллем на фронте. Native там же примерно. Да и graalvm тоже маячит.
Akka уже теснят всякие корутины и project loom. Реактивным программированием сейчас тоже никого не удивишь.
Dotty вроде как дает надежду и уже почти готов, но опять же в статье про него тоже ни слова.
Ожидал от статьи какого-то обоснованного позитива и подсветку направлений, где скала сильна и имеет хорошие перспективы. Но в статье этого нет. Такое ощущение, что скоро скала останется в банках, легаси и у маргиналов.
Поверх континуаций акторы строятся легко. Представьте, что вы разработчик, который одинаково знаком с akka и корутинами — новый проект на чем будете начинать?
Ок, перефразирую вопрос — при каких условиях для нового проекта будет использоваться Akka? Эти условия те же, что были до появления котлина с корутинами?
Disclaimer: я не фанат котлина, но мне кажется, что он неплохо отжирает долю ниш скалы.
В тестах? Весьма странно — имхо, у scala test больше возможностей и гибкости, чем у любой котлиновской библиотеки тестов или junit того же самого.
Это были Java разработчики, не скалисты. Решили попробовать с тестов. Ничего особо не дало. Впрочем, я как раз это вполне готов объяснить тем, что у нас на первом месте спарк, а тесты для спарка — это по большей части интеграционные, не юнит, тесты.
Собственно язык написания тестов и фреймворк — это такая мелкая фигня во всем этом целом получается. Не в плане объема мелкая — по объему это как раз много выходит, а в плане сложности достижения эффекта, чтобы реально что-то протестировать.
Котлин гугл признал официальным языком на Андроид, так что вряд ли он повторит судьбу Скалы
UPD
JediPhilosopher Вот почему Гугл на Котлин подсел — вообще не пойму. Ведь они могли любой свой ЯП туда присобачить (да хоть новый с нуля разработать). Теория заговоров какая-то…
Насколько я знаю, там была история в духе "мы для вас бесплатно делаем клевую IDE под андроид, а вы пиарите наш язык". win-win такой.
go и dart сто лет в обед, но чет вроде на андроиде никто их не пиарит особо. А на котлин, например, уже и большую часть документации гугловой переписали.
Простите, но на мой практический взгляд это скорее сказки. Разница в производительности такая, что этого не происходит, как только эта производительность хоть что-то да значит. Разница в удобстве в случае спарка тоже не за питоном, а за скалой.
У нас модели тоже любят делать в Jupiter и на питоне. А потом когда в пром нужно, берут, и переписывают. На Java, как правило.
Завтра из интереса спрошу, есть ли у нас хоть какой-то питон в проме. И если есть, сколько его в процентах. Моя оценка — порядка 1%.
Вот вы сами сказали что модели пишут на питоне, а потом в проде на java переписывают. Если на скале удобнее — чего ж на ней-то не пишут?
В спарке в том то и прикол, что очень многим от него начинает быть нужен только spark sql. А там без разницы практически на чем писать. Вот и пишут дата сайентисты на питоне спарковские джобы. Т.е. основной язык, где разрабатывается что-то новое, уже не факт, что scala.
Простой ответ — это разные люди. Мне было бы на питоне неудобно, но я это не они.
Чуть более сложный ответ — далеко не все модели вообще идут в пром, а зачастую просто выбрасываются.
Ну а совсем точного ответа у меня нет.
Так про то и речь. Раньше дата-анализ на спарке был либо на голых rdd, либо на java-либах. Сейчас эту нишу отъел питон.
Для действительно тяжелых задач — да, на скале будет быстрее. Для того, чтобы проверять гипотезы — вряд ли. Тут уже разница есть, когда нужно реальная оптимизация, недостижимая сменой алгоритма. Но api pyspark предоставляет почти полностью идентичный скале, выполняется все на экзекуторах. Если большая часть обработки — на spark sql или через стандартные методы, то питон там будет проседать в основном только из-за боксинга/анбоксинга. По сетке гонять все равно дороже.
В любом случае порог входа ниже для питониста. Если даже взять среднюю температуру по больнице в виде запросов “spark scala” и “spark python” на hh, то получим 134 против 211.
У нас есть живой пример, когда нужно было сделать проект, переваривающий терабайты в сутки. Причем было много неясностей, и мы решили делать прототип на spark-shell, который в итоге и остался (на скале).
В результате его сделали двое — один аналитик, и один Java-разработчик примерно middle-уровня (примерно — потому что на самом деле он довольно опытный, но немного в другой области — в области баз данных и SQL). Два месяца примерно. Нулевой уровень скалы в начале, у обоих.
Порог входа в скалу на спарке — околонулевой, и кривая очень плавная. У меня четыре подопытных кролика, я это на практике проверяю ежедневно :)
На всякий случай, чтоб было понятнее — это не ML, это скорее ETL. То есть, я не к тому, что порог у питона высокий, или что-то в этом духе, а что порог входа у скалы тоже низкий.
Я не говорю, что для скалы порог входа высокий. Я тоже могу рассказать несколько историй про то, как быстро люди начинают на ней писать.
Я про то, что у питона он ниже. Еще раз — я ни в коем случае не против скалы. Просто говорю, что питон начал отъедать ее аудиторию для спарка. Я уже не знаю, как вам еще доказать, что это не «сказки» — зайдите что ли в чат русского сообщества apache spark в телеге или посмотрите программу Spark AI Summit — там есть чисто питонячий трек.
Что автор и делает в своих библиотеках. Они действительно простые и понятные.
Я вот их использую)
те ниши, где ФП подход однозначно выгоднее простого ООП и процедурного
А такие есть? А есть ли в них достаточно пользователей, чтобы поддерживать развитие языка? А сможет ли оно конкурировать с ООП языками, в которых давно уже есть все основные прикладные ФП концепции? Я чет сомневаюсь.
Сколько лет пытаются людей убедить что ФП это круто, но нет, не ложится оно на мозги. Людям удобно мыслить императивно или объектно, так как это соответствует тому, как мы ощущаем окружающий мир.
А вот как «better java» (ответ на ваш нижний комментарий) — это вопрос интересный.
Если делать better_java для простых задач, то это не ниша Скалы (и там уже укрепился Котлин). А вот для сложных задач (чтобы их можно было делать легко и быстро) может и взлететь. Хотя здесь ее уже тоже подпирают не-jvm-ские Haskell и Rust. Но это по-любому означает необходимость кардинальной переработки Скалы, чтобы она перестала быть всем для всех.
Да и где стейты критичны, тоже. Там как раз хорошо, стейт сразу видно, он везде явный, а не «вот если у этого объекта дёрнуть это, а потом у того то, то первый будет в нужном стейте, но при этом вот этот метод дёргать нельзя, а то всё сломается».Согласен, нынешние дизайны ООЯП подталкивают к «макаронной» архитектуре.
Людям удобно мыслить императивно или объектно
Это очень спорное утверждение, на котором много копий сломано.
Каким именно людям? Тем, кто в институте, на курсах и на первых работах писал императивно?
Да, привычки играют очень большую роль. Но есть люди, кто с самого начала изучал только функциональщину, они вот непонимают, как можно писать ПО с этой кашей ООП объектов.
Я хочу сказать, что нет хорошей, объективной статистики для таких утверждений.
А что касается "это соответствует тому, как мы ощущаем окружающий мир", то его удобство очень хорошо отображает вот эта классическая картинка.
Процедурно-объектное мышление формируется, имхо, гораздо раньше первого курса и, даже, первого класса.
Даже в OOP Claims brains:true смущает, и неабстрактный legs который возвращает 0 для всех животных которые не догадались его переопределить.
Сколько лет пытаются людей убедить что ФП это круто, но нет, не ложится оно на мозги.
На деле, ФП вполне проникает в мейнстрим, просто кусками и медленно. Но и ООП зашло в мейнстрим не через Smalltalk, а через более близкие к процедурным языкам C++ и Java.
На моей практике, университетов в России которые нормально преподают ФП, (5 лет назад), было очень мало, по сравнению с университетами где хоть как-то преподавали программирование. Но ООП есть везде. Вкупе с тем, что концепции довольно сильно отличаются, мы получаем эффект, что на выходе разработчики не могут «с ходу» понять абстракции ФП и не спешат развиваться в эту сторону.
И почему же оно не подходит? Есть объекты бизнес-логики, есть эндпоинты апи, которые что-то с ними делают.
А вот функциональщину тут куда приткнуть? Т.е. какая-то там часть функциональщины может там работать под капотом в виде всяких акторов, но как на функциональщину положить типичную бизнес-логику типа "ну есть юзеры, группы, роли, проекты, и все это связано кучей зависимостей"?
И почему же оно не подходит?
Потому что типичный АПИ — «вот тебе запрос, обработай его, дай ответ». Это как раз очень хорошо ложится на определение функции:
res = handle(req)
Я пытаюсь, сказать, что все, что происходит — это трансформация данных перед\после тем\того как положить\достать их в\из хранилища.
объекты бизнес-логики
Объекты никуда не деваются и в ФП. Только вместо классов появляются типы, вместо интерфейсов — тайпклассы и т.д…
«ну есть юзеры, группы, роли, проекты, и все это связано кучей зависимостей»
Это все прекрасно описывается теорией категорий. (И да — ее не обязательно знать, достаточно понимать довольно небольшое кол-во базовых понятий). Оперируя продуктами\ко-продуктами можно добиться выдающихся результатов, при этом получая мощные гарантии. А ООП код не дает никаких гарантий. Наследуясь от базового класса — можно переопределить его поведение до неузнаваемости. И программисту, который, скажем, рефакторит такой код чтобы быть уверенным, что он ничего не поломал необходимо изучить всю иерархию классов… если обобщить, то ты не знаешь что делает программа, пока не прочитаешь ее полностью (в худшем случае). Если брать ФП, то там программа сводится к значению. Т.е. это просто функция, а что бы понять что делает функция — достаточно взглянуть на ее сигнатуру. И если вам когда либо приходилось рефакторить код на Java (ООП) и Scala (ФП), то очевидно, что последнее требовало на порядки меньше трудозатрат.
Как-то так.
т.е. какая-то там часть функциональщины может там работать под капотом в виде всяких акторов
Часто как раз таки поступают наоборот. Возвращаясь к скале — рантайм JVM очевидно более заточен под Java, поэтому в скале даже в чисто функциональных частях кода используют ООП под капотом, чтобы добиться оптимальной производительности.
Пример: Map — если конструировать ее из списка, то под капотом создается MutableBuilder, который собирает структуру данных, а на выход она уже возвращается как immutable.Map. Это не ломает никаких абстракций, но прокачивает производительность в реалиях JVM.
Я тут относительно недавно поймал себя на мысли, что давно не встречал задачи, куда хорошо ложится ООП
Полностью поддерживаю! Сам прошел путь от процедурного программирования к ФП и теперь ясно осознаю, что, действительно, там, где раньше вместо ООП и ничего нельзя было представить — теперь очевидно (мне), что его использование выливается в кучу костылей.
не пишу гуи (и никогда не писал фронтенд)
С некоторыми оговорками — ФП тоже хорошо заходит (что на нижнем слое все же прослойка из ООП для производительности).
Ну, вот gamedev на мой взгляд довольно хорош в рамках ООП.
А давно вы занимались автоматизацией документооборота, электронной коммерцией, учётом различным, задачами где суть в управлении состоянием огромных систем?
Пытался одно время перелезть на скалу, как на better java — не взлетело. Да, были какие-то приятные фишки, ради которых очень хотелось перейти, но:
1) Запутанность и неочевидность многих вещей. В последний раз такую фрустрацию от непонимания переусложненных языковых конструкций я в С++ ощущал. И НЕТ, вы не сможете пользоваться только каким-то понятным и приятным вам лично подмножеством языка. Потому что авторы популярных библиотек обожают нахреначить туда всех этих имплиситов и прочей мутной хренотени, и волей-неволей приходится пытаться это все понять.
2) Фиг найдешь разработчиков. Тут замкнутый круг — нет популярности языка — нет разработчиков — нет проектов. Я сделал один небольшой сервер в продакшене на скале и уже успел проклясть все на свете — другие члены команды в скале не разбираются, учить смысла не видят, кроме меня ковырять его некому. На хабре была когда-то хорошая статья на эту тему — почему для бизнеса скала плохой вариант.
При этом начиная с 8 джавы для меня лично почти все критичные фишки появились и в самой джаве — лямбды и стримы. Если добавить ломбок — то и дата-классы и еще что-то там. По сути единственное по чему я скучал в джаве по сравнению со скалой — это подход "все является выражением" и паттерн-патчинг. Но это вроде тоже в джаву потихоньку перетаскивают.
А потом появился Котлин. Который во-первых еще более better java, во-вторых не содержит такой кучи мозговзрывающих концепций, превращающих код в write-only, а в-третьих благодаря поддержке гугла на андроиде он сумел разорвать замкнутый круг и резко начал набирать популярность.
Итог: как better java Скала, на мой взгляд, смысла больше не имеет. И ждет ее дальше только тихое загнивание и стагнация, подпитываемое по чуть-чуть любителями ФП, так как на хаскелле вакансий вообще нет, а на скале хоть чуть-чуть да есть.
На чистую Java после Скалы откатываться не хочется. А вот Котлин?.. Да, поддержка Google. Но, с другой стороны, на Котлине пишут 90% под Андроид. И толку мне от обилия мобильных разработчиков, если мне надо пилить не мобильное приложение, а бекенд, шустренько и зело распаралеленно ворочающий гигабайты данных.
Ну я вот на котлине сейчас для эксперимента пару бэкенд сервисов писать стал. Поддержка котлина в Spring уже есть, все работает. А что еще для энтерпрайза надо.
А про гигабайты — там та же JVM под капотом, если раньше джава вас устраивала, то котлин будет работать не хуже.
Я про то, что преимущество Котлина над Скалой в части наличия на рынке бóльшего количества разработчиков в случае с бэкендом не столь очевидно. Пишущих на Котлине вообще — да, больше, чем на Скале, и перспективы роста этого количества лучше. А пишущих на Котлине бэк — вот не факт…
Котлин, как мне кажется, проще изучить. При этом более понятны перспективы изучения — раз уж гугл за него впрягся. Плюс та же интеграция в спринг и интероп с джавой — в итоге проще будет найти того, кто согласится котлин изучить при необходимости. И сделать это будет проще.
В той же скале, например, кроме языка придется еще и стек иной изучать. И все это со смутными перспективами эти знания применить где-либо еще, в другом месте.
Запутанность и неочевидность многих вещей
Справедливости ради, популярные Java-стеки тоже сложно назвать простыми и очевидными. Программирование на аннотациях и на classpath в спринг-буте имхо гораздо большая магия, чем имплиситы, или макросы, или что угодно еще в скале. Взять какой-нибудь хибернейт или тот же ломбок — в них реально проще разобраться, изменить поведение или найти баг, чем в скала-либах?
Если у меня не работает какая-нибудь связка макросов и имплиситов для десеарилизации какого-то хитрого типа из json, я всегда могу посмотреть дешугареный код, разобраться, что откуда берется, написать нужные куски сам. Я по-прежнему остаюсь в пространстве языка, могу пользоваться всеми его богатыми средствами, и компилятор скажет, если что-то не так.
Но вот когда в спринг-буте что-то ломается на ровном месте из-за неправильного порядка загрузки конфигов, а птичьего языка аннотаций не хватает, чтобы запрограммировать нужное поведение — вот тут я ощущаю нешуточную фрустрацию. Правильность аннотаций не проверяется компилятором. Все это добро работает в рантайме через рефлексию. Весь современный java стек программируется не на уровне языка джава, а мета-уровнях, будь то имена методов (как в JPA), аннотации, classpath, генерация кода, генерация байткода.
Может код джава-проектов и выглядит таким простым, потому что вся основная работа неявно делается где-то еще, и девелоперы могут просто верить в магию, данную свыше, вместо того, чтобы разбираться в ней и кастомизировать под себя средствами языка.
Rails был первым блином (комом), и таким достаточно долго и оставался (да что там, и остается до сих пор)). Но затем появились более правильные подходы к проектированию таких больших систем. Как хороший образец кода можно посмотреть Sequel и Shrine. Затем появился Dry и Hanami. Отсуствие метапрограммирования в современном мире — это дичайше неудобно.
Ну, этому нужно правильно учить. Я пытался учить этому аналитиков. В принципе, в рамках приложенных усилий (примерно в пределах 10 часов занятий) результат более чем неплохой.
Возможно, это объясняется тем, что библиотек у нас как раз одна — спарк. Но я бы сказал — частично объясняет.
В смысле время? Последних 6 лет недостаточно что ли? Примерно все добавленные синтаксические фичи джавы, имеющие аналог в скале, во-первых сделаны более убого по сравнению со скалой, во-вторых, неслабо корежат исходный синтаксис джавы, делая его все менее консистентным и более мозаичным.
Хорошая иллюстрация, как дизайнерам джавы приходится идти на компромиссы и выбирать из нескольких зол — спич Тагира Валеева про паттерн-матчинг https://www.youtube.com/watch?v=qurG_J81_Cs
Можете, пожалуйста, исправить перевод (перевод «Польские» здесь неправильно использован для слова «polish»):
«Польские» функции, такие как сопоставление с образцом в строках или подавление предупреждений, продолжают улучшать жизнь каждого.
Конец хайпа: Что ждёт язык Scala дальше