И это все еще могло

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

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

Под «успехом» мы подразумеваем количество разработчиков, использующих Scala в отрасли. Если говорить о рейтингах Redmonk и частоте объявлений о вакансиях, то с тех пор Scala стабилизировалась. С учетом сказанного, Scala удалось найти свое место почти во всех системах JVM, даже если только часть этой системы является библиотекой или фреймворком, написанным на Scala.

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

Заявление об ограничении ответственности: это не нападение на какое-либо лицо. Если вы чувствуете, что я негативно отзываюсь о вас как о человеке, свяжитесь со мной, и я постараюсь успокоить вас.

Болевые точки

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

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

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

То, что пугает большинство разработчиков Scala и вызывает самые ожесточенные споры, - это использование библиотеки универсального программирования Shapeless. Я частично несу ответственность за это, потому что однажды я провел семинар по Scala eXchange, отстаивая его использование. Я сожалею об этом. Пожалуйста, простите меня!

Время компиляции

В 2019 году мы увидели хороший прогресс от Lightbend в производительности компиляции: компилятор Scala 2.13 является самым быстрым компилятором Scala, а запатентованная технология GraalVM может сделать его еще быстрее.

Lightbend, к их чести, удвоил микрооптимизацию с помощью своих коммерческих клиентов. Это похвальное достижение, потому что Lightbend в первую очередь занимается своими собственными продуктами, а команда Scala очень мала (всего четыре штатных разработчика), и они также несут ответственность за поддержку sbt.

Для тех, кому нужны еще более быстрые компиляции, гидра Triplequote поможет.

Twitter переписывает компилятор с помощью RSC (компилятор Reasonable Scala), а Kentucky Mule был предложен бывшим членом команды компилятора Scala, так что есть еще варианты, которые можно использовать.

Инструменты

Ученым в EPFL потребовалось много времени, чтобы осознать, что время компиляции и инструменты были проблемой. Scala Center был создан в 2016 году для координации и разработки библиотек и инструментов с открытым исходным кодом на благо всех пользователей Scala.

Я был одним из первых сторонников, но я потерял веру, когда они потратили свои первые три года на работу над проектами для домашних животных и программным обеспечением для электронных сигарет, такими как Scaladex, Spores, Scastie, Scala Native и Dotty, вместо того, чтобы решать неизбежные проблемы.

В 2019 году мы увидели, что Scala Center предоставляет больше актуальных проектов: они пишут более быстрые инструменты сборки, инструменты рефакторинга и альтернативы IntelliJ.

К сожалению, отсутствие у них опыта промышленного инжиниринга свидетельствует о том, что они решили изобретать новые решения, а не вносить свой вклад в существующий инструментарий, который используется в производстве. Например, мы можем раскритиковать ляп, отметив, что если преимущества не видны в sbt, то никто не выиграет. И мы можем раскритиковать создание Metals, отметив, что 10% пользователей Scala (около 2018 г.) используют ENSIME, и они отклонили вклад буквально сотен добровольцев.

Это следует традиции переосмысления, восходящей к Scastie (переосмысление Scalafiddle) и Scala Native (конкурирующее с Graal). Если сообщество Scala желает лучшего инструментария, оно должно держать Scala Center под контролем: они были созданы для «координации и развития», а не для игнорирования того, что существует, и разработки новых вещей.

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

Сложность

В 2018 году Джон Претти выпустил библиотеку макросов Magnolia. Команды заменяют свой самый сложный код «производного класса типов» Shapeless простыми альтернативами Magnolia, которые могут компилироваться в 100 раз быстрее.

Хорошо выглядеть?

Глядя на то, как все решают основные проблемы, Scala находится в хорошей форме!

Scala Center и Lightbend приносят пользу, и сообщество прилагает все усилия, чтобы исправить пробелы в экосистеме. Так почему же Scala выходит на плато? Это слишком мало, слишком поздно?

Я считаю, что проблема многогранна:

  1. действительно трудно нанять опытных разработчиков Scala.
  2. В то время как Scala жгло время, Java догнала его.
  3. Scala 3 и эффект Осборна.

Трудно нанять разработчиков Scala

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

Одним из преимуществ Scala было то, что он совместим с библиотеками Java. Это палка о двух концах, потому что, хотя он помогает разработчикам Java перейти на Scala, он затрудняет изучение Scala для людей, не знающих Java. Чтобы использовать большую часть инструментов времени выполнения (профилировщики, отладчики, оптимизация и т. Д.), Необходимо изучить JVM.

Множество разных стилей Scala означают, что недостаточно нанять или обучить кого-то в Scala. Play, Typelevel, Scalaz - все это очень разные технологические стеки, создающие ниши в своей нише. Укоренившаяся политика привела к тому, что эти стопки еще больше разошлись. Они должны объединиться, а не сражаться. К сожалению, в 2019 году мы увидели обратное: Lightbend и Scala Center активно исключили проекты и отдельных лиц из сообщества, потому что они внесли свой вклад в «неправильный» стек.

Политика настолько грязная, что несколько членов команды компиляторов Scala недавно занялись «отказом от платформы» известного участника, удалившего основные доклады из Scala Days (UPDATE: и Scala eXchange), что оказало давление на всех организаторов конференции. ОБНОВЛЕНИЕ: бывший руководитель Lightbend призвал к бойкоту рекрутеров, которые работают с этим участником.

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

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

Java догнала

Java теперь имеет гораздо лучшую поддержку параллелизма и функционального программирования. Есть предложения добавить в язык сопоставление с образцом.

Android, на который приходится 80% всех смартфонов на планете, использует урезанную версию Java. Scala намеренно отказалась от поддержки Android, а это означает, что всем разработчикам, ориентированным на крупнейший в мире App Store, пришлось искать альтернативные языки. Многие вернулись на Java, а другие перешли на Kotlin как «лучшую Java».

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

Эффект Осборна

Эффект Осборна - это миф о том, что Osborne Computer Corporation вышла из бизнеса в 1980-х годах, потому что они анонсировали версию 3 своего персонального компьютера, в то время как версия 2 все еще продавалась. Хотя это миф, эффект вполне реален. Scala 3 является академическим исследовательским проектом под кодовым названием «Dotty» в течение почти пяти лет и должен появиться в течение следующих нескольких лет. На этом этапе Scala в том виде, в каком вы его знаете, будет списана. Так зачем инвестировать в Scala 2, если вы можете дождаться Scala 3 и до тех пор обойтись Python?

Изменения в Scala 3 настолько разительны, что всех разработчиков Scala необходимо будет переобучить, а все базы кода нужно будет перенести. Личные контакты говорят мне, что их оценки миграции варьируются от «выходных» для небольших проектов до одного месяца для проектов среднего размера (100 тыс. Строк кода) до нескольких лет усилий для более крупных проектов (миллионы строк кода). И это предполагает, что экосистема бесплатного программного обеспечения уже перенесена, что зависит от множества добровольцев, мобилизующихся для общего дела.

Все улучшения компилятора и инструментов, сделанные за последние несколько лет, будут выброшены. Они нацелены на компилятор Scala 2. Даже неясно, будут ли готовы IDE и текстовые редакторы (усилия по поддержке значительных пробелов и новых грамматических конструкций невозможно переоценить, и они слишком низкоуровневые, чтобы их мог решить LSP).

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

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

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

Самые страстные сторонники сообщества Scala пытались опозорить и отвергнуть любого, кто выражает озабоченность по поводу Scala 3 как «токсичных троллей» или «FUD». Но есть искренняя озабоченность, и ее нельзя игнорировать. Нельзя замалчивать дебаты, нельзя увольнять или запрещать людям ставить под сомнение оценки.

Что может быть сделано? Я считаю, что сообществу Scala необходимо громко высказаться и посоветовать ученым и хранителям Scala изменить название Scala 3. Запустить его как «Dotty», новый язык с собственным процессом улучшения. Передайте управление процессом улучшения Scala (SIP) отрасли, и давайте делать все на основе консенсуса.

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

«Я вижу, как агрессивные, массовые изменения предлагаются и навязываются вопреки отрицательному консенсусу». - Автор fastparse и аммонита