[Перевод - recovery mode ] Конец хайпа: Что ждёт язык Scala дальше20.04.2020 20:34

Вокруг языка Scala всегда было много хайпа и неоднозначных суждений.
Сейчас споры поутихли, но в твитере появились сообщения об уходе некоторых значимых участников из компаний активно развивающих экосистему языка Scala. В связи с чем в очередной раз пошли разговоры о том, что Scala всё.
В ответ на это один из очень активных членов сообщества (Li Haoyi) описал своё видение дальнейшего пути языка Scala.
Статья у него получилась интересной, посему решил перевести её.

Помните, это перевод.
Я старался сохранить оригинальный стиль. В любом случае, все замечания и исправления просьба отправлять в личку.

В недавнем твите мой друг писал, что общественный интерес к языку программирования Scala, похоже, остановился или уменьшается, что вполне соответствует моему представлению о том, что происходит сейчас. В этом посте я расскажу о том, почему, по моему мнению, это произошло, где сейчас находится Scala и что ждет в будущем сообщество Scala.

Этот пост был вдохновлен следующим твитом:

Обидно смотреть, как увольняют друзей из Typesafe/Lightbend, но, как я всегда говорил, бесплатные вещи продавать тяжело.
Я действительно задаюсь вопросом об использовании Scala сейчас. Это конечно не «конец Clojure», но, похоже, Scala достигла пика примерно в 2016 году. Хотя у меня нет данных, подтверждающих это.

Jamie Allen

Джейми отмечает, что общественный интерес к языку программирования Scala, похоже, уменьшился: меньше интереса к встречам, меньше интереса к конференциям и т.д. Я вижу примерно то же самое. Несмотря на то, что конференции, посвященные Scala, ориентированные на энтузиастов, по-прежнему актуальны (или были, пока COVID19 не закрыл мировую экономику), я думаю, что нет сомнений, в инженерном сообществе сейчас гораздо меньше разговоров о Scala.

Думаю, что это снижение интереса не только реально, но также ожидаемо, учитывая типичный «Hype Cycle», который следует за любой новой технологией:

Вначале Scala накрыла волна хайпа, которая откровенно удивила даже меня: хайп вокруг расширения синтаксиса, вокруг реактивной архитектуры, вокруг функционального программирования, вокруг проекта Apache Spark. Потом большая часть этой шумихи сошла, и в сообществе и за его пределами был период негатива. С тех пор все утихло и остался разумный, скучный язык, который постоянно развивается и предоставляет отличную платформу для общей разработки программного обеспечения.

Хотя язык Scala был создан в 2004 году, он начал активно развиваться только в начале 2010-х годов:

~2009: Twitter начал использовть язык в продакшене

~2010: Первый релиз библиотеки функционального программирования Scalaz

~2011: Была основана компания Lightbend, продвигающая Scala и связанные с ней технологии

~2014: Apache Spark был написан на языке Scala

~2015: Первый релиз библиотеки функционального программирования Cats

Хотя до этого в сообществе Scala не было никаких сомнений, это были основные вехи, которые пробудили интерес к языку. Неудивительно, что благодаря широкому коммерческому внедрению, коммерческой поддержке и таким убийственным продуктам по работе с большими данными, как Apache Spark, общественный интерес возрос. Многие из этих усилий были направлены на следующие области:

Раздвигая границы синтаксиса

В начале Scala привлекала гибкостью языка: у него были методы расширения, перегрузка операторов, неявные конструкторы/преобразования и очень гибкий механизм имплиситов (неявных параметров), который можно было использовать везде. Эта гибкость давала свободу, поскольку становились доступны все виды предметно-ориентированных языков и стилей программирования, которые были бы невозможны в других языках.

В качестве примера можно привести ряд проектов, таких как HTTP-клиент Databinder Dispatch, библиотека структуры данных Scala-Graph или средство сборки SBT:

// Making a HTTP request and processing the output in Databinder Dispatch
executer(:/(host, port) / target << reqBody >- { fromRespStr })

// Constructing a simple directed graph with labelled edges in Scala Graph
val flights = Graph(
    (jfc ~+#> fra)(Flight("LH 400" ,10 o 25, 8 h 20)),
    (fra ~+#> dme)(Flight("LH 1444", 7 o 50, 3 h 10))

// Append the contents of a URL to a File after filtering through grep using SBT
url("http://databinder.net/dispatch/About") #> "grep JSON" #>> file("About_JSON") !

// Search for uses of null in the source directory using SBT
"find src -name *.scala -exec grep null {} ;"  #|  "xargs test -z"  #&&  "echo null-free"  #||  "echo null detected"  !

Многие из этих библиотек развивались с первых релизов Scala и с тех пор перешли к более простым API на основе методов. Оказалось, что именование операторов >- ~+#> или #&& хотя и было возможно, не всегда было мудрым решением. Тем не менее, нет никаких сомнений в том, что расширение границ синтаксиса Scala с использованием операторов и предметно-ориентированных языков было одной из главных достопримечательностей раннего Scala.

Реактивная Архитектура

Реактивная архитектура, проталкиваемая Lightbend через их среду Akka Actor, была еще одним большим усилием. Это способ написания кода, сильно отличающийся от «нормального» кода, который обычно изучают в школе, но позволяющий получить более высокий уровень параллелизма и производительности чем при написании кода в традиционном стиле.

В начале Akka Actors пожертвовали многим из того, чем является Scala: полным отсутствием типобезопасности между акторами, запретом блокировок API и многими другими особенностями. Работа с акторами Akka была в основном их собственным языком, встроенным в Scala, но со своими собственными соглашениями, синтаксисом и семантикой.

Совсем недавно, с релизом Typed Actors и Reactive Streams, разработчики получили больше типобезопасности, которой обычно ожидают в программах на Scala. Я думаю, что также произошел сдвиг в настроении сообщества: вместо того, чтобы относиться к реактивным архитектурам как к универсальному решению всех проблем, теперь они рассматриваются как один из возможных подходов для одного конкретного класса проблем. Это в основном соответствует моему опыту использования этих методов в моих собственных приложениях.

Функциональное программирование

Функциональное программирование в Scala лучше всего иллюстрируется проектами Scalaz и Cats. Эти две библиотеки пытаются перенести большую часть методов функционального программирования с языка Haskell на язык Scala: большое внимание уделяется таким понятиям, как монады или аппликативы, избегая объектно-ориентированной стороны языка для более чистого функционального стиля.

Две библиотеки имеют разные стили, и обе они активно используются сегодня в сообществе. Религии стало меньше, и все признают функциональное программирование как один из возможных стилей написания приложений для Scala.

Apache Spark

Последним крупным проектом, вызвавшим ранний ажиотаж в Scala, был Apache Spark. Распределенная среда обработки больших данных, Apache Spark использовала функциональный стиль Scala и сериализуемые лямбды для сбора общих коллекций, таких как map, filter и reduce, распределенных по вычислительному кластеру, обрабатывающему огромные объемы данных. Apache Spark позволяющий писать на порядки меньшие объёмы кода для конвейерной обработки больших данных и работающий на порядки быстрее раннего API Hadoop — мгновенно стал хитом.

Apache Spark был киллер фичей Scala. Огромная часть сообщества Scala использует Scala только потому, что им нужно каким-то образом взаимодействовать со Spark.

Apache Spark теперь поддерживает API-интерфейсы для разработчиков на многих языках: SQL, R, Python. Причем Python является самым популярным вариантом. Исходный API, построенный на API из коллекций, был в основном заменён на API более похожий на SQL, который лучше оптимизируется, что является важным фактором при работе с огромными наборами данных, для которых часто используется Apache Spark. Тем не менее, кодовая база Apache Spark по сей день остается в основном на Scala.

Дно разочарования

С начала развития спарка часть сообщества продолжала бухтеть против Скалы, поскольку начальный хайп уже прошёл. Некоторые ранние участники ушли из сообщества, были некоторые личные конфликты. Это происходило не только в целом, но и на индивидуальном уровне: я лично знаю многих людей, которые устали от того, что они обманываются и были недовольны ситуацией.

Трудно понять точно когда прошел хайп, возможно, в 2016–2018 годах.

Даже на техническом уровне не все было хорошо. В то время как одни организации успешно использовали эти методы в своих нишах, другие сожалели, что поставили всё на акторы и на функциональное программирование. Они обнаружили, что эти методы не решают их проблемы так, как им хотелось бы, и им пришлось потратить некоторое время, чтобы отказаться от своих наработок. Я лично знаю много организаций, которым пришлось это сделать.

Еще в начале 2010-х, я удивлялся количеству ажиотажа вокруг этих технологий. Использование операторов в некоторых библиотеках было явно за гранью, а иногда превращало даже простые задачи в сложные головоломки. Количество хайпа вокруг реактивных архитектур и функционального программирования, не соответствовало тем вариантам, для которых они подходят лучше всего: у каждой конференции Scala были основные докладчики, проповедующие оба эти подхода как основополагающее будущее всей архитектуры программного обеспечения.

Меня совсем не удивляет, что в результате люди оказались со мной на «Дне разочарования».

Настоящее: на склоне просветления

Scala получила свой хайп в начале 2010-х, после чего последовал спад в середине-конце 2010-х. Куда же теперь двигается Скала?

Стабильно растущее сообщество

Несмотря на очевидный спад интереса, использование Scala продолжает расти. Я поддерживаю большое количество библиотек с открытым исходным кодом, и количество уникальных IP-адресов, загружающих эти библиотеки из репозитория пакетов Maven Central, выросло чуть более чем в 2 раза за последний год. Несмотря на некоторые различия в количестве загрузок или показателях для каждого отдельного пакета, в целом они достаточно близко соответствуют этой тенденции.

Хотя этот рост не является экспоненциальным, на который рассчитывают некоторые проекты, это постоянный рост, соответствующий моему собственному субъективному опыту: использование Scala продолжает увеличиваться даже после хайпа. Если мы сможем поддерживать этот двукратный рост каждый год, я думаю, что у сообщества Scala будет и впредь всё хорошо.

Если вы посмотрите на самые последние рейтинги Redmonk или Tiobe, они оба показывают, что Scala стабильно колеблется в непосредственной близости от основных языков, заняв 13 и 28 места соответственно. Не очень популярный, но не малоизвестный язык.

Вспоминая хайп и критику в прошлом, Scala теперь выглдяит гибким языком, поддерживающим несколько стилей программирования, каждый со своими компромиссами и вариантами использования. Многие ранние религиозные войны и конфликты превратились в людей, использующих Scala на постоянной основе, наслаждающихся языком по своему выбору.

Надежная платформа для использования в производстве

Несмотря на снижение хайпа, язык Scala чувствует себя лучшем, чем раньше:

За последние несколько лет инструмент для сборки SBT сильно развивился, стал значительно быстрее и проще в использовании.
Если вам не нравится SBT, у вас есть выбор: многие организации используют Bazel или Pants со Scala, в то время как мой собственный инструмент для сборки Mill стабилен и широко используется.
Новые инструменты, такие как Coursier, формируют новую основу для экосистемы: используются инструментами от Ammonite до SBT и Mill
Проект Metals даёт поддержку Scala для VSCode, Sublime Text и любого другого редактора с поддержкой языкового сервера.
Собственный плагин Intellij для Scala продолжает совершенствоваться: быстрее, точнее и с поддержкой новых инструментов, таких как скрипты Ammonite или инструмент сборки Mill.
Новая библиотека коллекций в Scala 2.13 хорошо почистила API и значительно повысила производительность во многих случаях (например, ускорение на 25–40% в Sjsonnet)
«Польские» функции, такие как сопоставление с образцом в строках или подавление предупреждений, продолжают улучшать жизнь каждого.
Компилятор значительно ускорился, код компилируется буквально в два раза быстрее, чем всего три года назад.

Хотя спецификация языка, за последние несколько лет, почти не изменилась, количество качественных улучшений в целом трудно переоценить. В 2017 году, любая инженерная организация, использующая Scala, за сокращение времени компиляции вдвое осыпала бы вас деньгами!

Каждое изменение в отдельности значительно улучшило мой личный опыт работы со Scala, и есть много других улучшений, которые я не могу перечислить здесь.

Широкая и разнообразная экосистема

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

В любом случае, хайп делает своё дело: знакомство большого количества людей с определенной парадигмой помогает достичь критической массы, чтобы поддерживать это сообщество в будущем.

Множество стилей в Scala можно рассматривать как благо: вместо того, чтобы рассматривать его как способ разделения сообщества, это способ объединения сообществ, которые иначе никогда бы не взаимодействовали друг с другом. Без Scala эти сообщества могут работать независимо друг от друга в системах на Haskell, Python, Java и Go. Сконцентрировавшись на общих чертах, а не отличиях, Scala позволяет сообществам совместно работать над тем, что им выгодно, при этом сохраняя всё то, что делает каждое суб-сообщество уникальным.

Я не делаю сразу архитектуру своего кода реактивной с использованием Actors, но я создавал продакшен код активно использующий акторы, когда это было надо. Я не всегда использую чисто функциональные методы программирования, но я использовал довольно эзотерические конструкции, такие как Free Applicatives, когда они полезны. Я думаю, что сообщество в целом развивалось аналогичным образом: ценило различные стили и использовало их, где это уместно, без догматизма, который отравлял первые дни Scala.

Будущее

Итак, что интересного, как я думаю, нас ждёт в будущем Scala?

Для меня сам язык Scala находится в относительно хорошем состоянии. Дня написания современного Java-кода достаточно, чтобы избавить меня от иллюзий, которые «догнали» другие языки, равно как и потратить дни, пытаясь (безуспешно) упаковать проект Python в отдельный исполняемый файл (Здравствуйте, Azure-CLI!).

Где самый большой потенциал, для представления Scala новым людям или новым вариантам использования, которые до этого момента были полностью вне границ. Я думаю, что есть две основные вещи:

Удобство использования

В самом начале Scala не хватало одного: возможности новому программисту быстро начать работу с кодовой базой и быстро стать продуктивным. Неважно, использовали ли вы императивный стиль, реактивный стиль с акторами или чистый функциональный стиль с FP-Cats / Scalaz: кому-то придется нелегко.

Почему так должно происходить?

В качестве контр-примера разработчики обычно приводят Python как простой язык для начала: «исполняемый псевдокод», который они называют. Новые программисты изучают Python. Непрограммисты изучают Python. Когда люди пишут код на доске с маркером, они часто пишут на Python. Хотя производительность, параллелизм или масштабируемость в Python сомнительны, его простота, в начале, не имеет себе равных.

Почему Scala не может быть так же легка на старте, как Python?

Ответ на этот вопрос — цель всего набора библиотек, который я поддерживаю. Многие из моих библиотек являются копиями, бесстыдными клонами их эквивалентов на Python. Например:

Ammonite, клон IPython REPL
[uPickle](), клон Python json module
PPrint, клон Python pprint module
Requests-Scala, клон Kenneth Rietz' Requests module
OS-Lib, клон Python os, sys, и shutil modules
Cask, клон Armin Ronacher’s Flask library

Оказывается, вы можете сделать Scala таким же простым на старте, как и Python. Со всеми слабостями Python — производительностью, параллелизмом, удобством обслуживания — Scala уже отлично справляется. Scala обладает потенциалом языка с удобством и гибкостью Python, производительностью и масштабируемостью Java или Go, а также типо-безопасностью, выходящей далеко за пределы любого из этих вариантов. В буквальном смысле лучшее из обоих миров!

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

Scala Native

Scala.js продемонстрировал целесообразность использования Scala на альтернативной платформе: он скомпилирован для Javascript, а не для JVM, имеет популярную экосистему, сообщество и переносит язык Scala в браузер, где его нельзя было использовать ранее.

Scala-Native обещает еще большую революцию: компилируя Scala в автономные бинарные исполняемые файлы. Это позволит использовать язык Scala в сценариях, где время запуска и оверхед JVM или Javascript недопустимы.
Как Scala.js принес Scala в браузер, так Scala-Native обещает привести Scala к множеству новых окружений:

Инструменты командной строки, такие как git, ls, rsync и т.д., которым критично время запуска JVM.
Фоновые процессы или демоны, где из-за значительных накладных расходов памяти JVM использование Scala проблематично.
Разработка мобильных приложений для iOS на iPhone и iPad, одном из самых распространенных в мире потребительских вычислительных устройств.
Десктопные приложения, в которых запуск JVM слишком медленный или сборка JVM слишком громоздкая.
Глубокая интеграция с нативными библиотеками, такими как библиотека машинного обучения Tensorflow.

Программы такого рода традиционно написаны на небезопасных языках, таких как C или C ++. Более поздние реализации часто пишутся на Rust или Go, и существует целая индустрия не-C языков программирования, таких как Nim, Zig или Crystal, которые также пытаются занять эту нишу. Scala-Native обещает занять нишу не новым языком, а уже популярным языком с богатой экосистемой библиотек и инструментов.

Scala-Native будет намного сложнее добиться успеха, чем Scala.js. В частности, Scala.js может сосредоточиться на компиляторе, а затем делегировать его существующей среде исполнения Javascript, в то время как Scala-Native должен построить свою собственную среду исполнения с самых основ: многопоточность, сборка мусора, циклы событий и так далее. Это добавляет огромное количество необходимой работы компилятору. Тем не менее, в случае успеха это будет огромным благом для расширения вариантов использования языка Scala.

Заключение

В то время как хайп вокруг языка Scala утих за эти годы, его использование, похоже, постоянно растет, и качество использования языка быстро улучшается. Это именно то, что вы ожидаете по мере того, как язык продвигается через цикл рекламы и переходит от сообщества, ориентированного на причуду, к сообществу, ориентированному на ценность. Разработчики Scala используют язык не как самоцель, а как надежный инструмент, который они могут использовать для решения своих технических или бизнес-задач, не связанных со Scala.

По сути, это означает зрелость сообщества.

В будущем, я надеюсь, мы сможем увидеть больше этого. Больше внимания на результатах и ценности, а не на рекламе. Больше взвешенных компромиссов, нежели догматизма. Больше искать общее, чем спорить о различиях. И еще 2х кратного ускорения компилятора!

Я думаю, что сообщество Scala не должно тратить много усилий на изучение существующего синтаксиса языка, много усилий на обсуждение функционального и объектно-ориентированного программирования или много усилий на то, чтобы сделать наш и без того очень типобезопасный код еще более типобезопасным. Вместо этого усилия должны идти на расширение языка, чтобы охватить тех разработчиков, которых мы не могли вовлечь: новичков, непрограммистов, людей с инструментами командной строки, разработчиков iOS и так далее. Если мы посмотрим на Опрос разработчиков Jetbrains 2019 для Python, мы увидим множество различных областей, в которых используется язык Python:

В настоящее время Scala в подавляющем большинстве случаев используется для серверных служб и/или конвейеров данных Spark, но нет никаких причин, по которым Scala также не могла удовлетворить вышеупомянутые варианты использования. Сообщество должно сделать применение Scala простым и широким настолько, чтобы любой, а не только многоопытный бэкенд/инженер данных, мог выбрать Scala и использовать его, наслаждаясь лаконичностью, производительностью и безопасностью типов, которые в сообществе Scala уже знают и любят.

Об авторе: Хаойи (Haoyi) — инженер-программист, один из первых разработчиков Scala.js и автор многих инструментов Scala с открытым исходным кодом, таких как Ammonite REPL и FastParse.

Если вам понравился этот блог, или вам нравилось использовать другие библиотеки с открытым исходным кодом Haoyi, пожалуйста, подключитесь (или сделайте так, чтобы ваша компания включилась!) Через Patreon, чтобы он мог продолжить свою работу с открытым исходным кодом.