Не так давно мы допечатали книгу Одерски, Спуна и Веннерса о Scala 2.12. Ведь до Scala 3 еще далеко.
Автор сегодняшней статьи — Адам Уорски, сооснователь компании «SoftwareMill» и опытный Scala-разработчик. У него получилось интересное резюме сильных сторон современного языка Scala, которое мы и предлагаем вашему вниманию.
После пленарной лекции Мартина Одерски на ScalaDays, где он изложил планы на Scala 3 и пленарной лекции Джона де Гоуса на конференции Scalapeno о будущем Scala в сообществе Scala продолжаются оживленные дискуссии. Не считая обсуждения этих пленарных выступлений, многочисленные дискуссии идут в twitter, в сообществах Slack, а также на reddit (см. напр. 1, 2).
Вот в чем вопрос!
Все это очень интересно и познавательно для специалистов, уже работающих в экосистеме Scala. Однако, значительная часть споров связана с различными интуитивно ощутимыми или фактическими недостатками Scala как языка. Эти моменты могут отпугивать людей «со стороны», вызывая у них вопросы: «А зачем мне вообще пользоваться Scala?», «А вдруг это тупиковый путь?», «Повторит ли Scala 3 успех Python 3?» и т.д. Как и в большинстве дискуссий, внимание приковывают самые слабые и эмоциональные тезисы, и эти дебаты — не исключение.
Поэтому сделаем шаг назад: зачем вам вообще мог бы потребоваться язык Scala? Каковы технические и деловые доводы в пользу работы с эти языком?
Предметная область проекта
Начнем с того, что язык Scala особенно хорош для определенных предметных областей (но не для всех!). Важнейшее достоинство Scala – это гибкость при определении абстракций. В вашем распоряжении – ряд простейших «кирпичиков» для этого; иногда определить абстракцию не сложнее, чем использовать класс, методы и лямбда-выражения. Иногда приходится использовать неявный параметр или метод расширения; в редких случаях остается только прибегать к макрокомандам. Однако, есть варианты.
Таким образом, Scala отлично вам подойдет, если требуется сориентироваться в сложной предметной области. Например, речь может идти о распределенном или конкурентном программировании. Наладить параллелизм очень сложно, а в Scala есть ряд библиотек, упрощающих эту задачу путем построения абстракций. Для этого существует два основных подхода: акторный, реализуемый при помощи Akka, и в духе FP, представленный Monix/cats-effect и Scalaz/ZIO (если бы вы хотели подробнее почитать о сравнении этих инструментов – я написал серию статей как раз на эту тему).
Однако, разумеется, речь может идти и о других предметных областях. Возможности Scala также позволяют вывести на новый уровень моделирование типичных бизнес-приложений. Но в данном случае речь уже о сложности другого порядка. В случае с распределенными системами мы сталкиваемся с технической сложностью. При программировании бизнес-логики в приложениях речь идет уже о сложности предметной области как таковой. Например, в книге Дебасиша Гхоша (Debasish Ghosh) “Functional and reactive domain modeling” объясняется, как совместить DDD с функциональным и реактивным программированием.
Сложность языка
Отметим: рассказывая о Scala, все любят подчеркивать широту возможностей этого языка, подчеркивая, что именно по причине такой разносторонности этот язык столь сложен. Это не совсем верно.
Как упоминалось выше, в Scala есть ряд базовых конструкций, из которых можно собирать абстракции. Однако, все их можно комбинировать друг с другом, благодаря чему язык и приобретает такую гибкость. Большинство новаторских проектов, которые могут вам попадаться, сводятся к тем или иным сочетаниям типов высшего порядка, неявных параметров и выделения подтипов.
Таким образом, при относительно небольшом количестве базовых возможностей (по размеру грамматики Scala проще Kotlin, Java или Swift!)?—?что, в свою очередь, облегчает обучение – варианты комбинаций гораздо многочисленнее.
Не слишком ли широкий выбор? Не думаю. Программист, как компетентный и ответственный профессионал, более чем в состоянии выбрать наилучший вариант, чтобы решить конкретную задачу. Подробнее об этом см. в статье “Простой стек Scala”.
Java, только лучше
Сейчас много говорят, что Kotlin вытеснил Scala в качестве “как Java, только лучше”. Но я считаю, что именно Scala, а не Kotlin, по-прежнему заслуживает такого звания. На то есть две основные причины:
Во-первых, неизменяемость в языке Scala первостепенна. Это связано с природой Scala как таковой: писать на нем код удобно прежде всего при помощи неизменяемых данных. К таким данным относятся, в частности:
val (как единицы первого класса), case-классы, функции высшего порядка, т.д. Но дело и в том, как спроектирована и написана стандартная библиотека языка Scala; неизменяемы все структуры данных, используемые «по умолчанию». Благодаря неизменяемости упрощается целый ряд вещей, особенно в нашем мире высокой конкуренции, где выигрывают именно те языки, где предпочитается неизменяемость.Во-вторых, в Scala поддерживаются конструкторы типов, типы высшего порядка и типы классов (объявляемые неявно), что серьезно упрощает работу с оборачивающими/контейнерными типами, например, с
Promise, Future или Task. Такие обертки преобладают при программировании в асинхронном или реактивном стиле, и наличие языковых конструкций, упрощающих работу, скажем, с такой базой кода, где активно используются Future – еще один аргумент в пользу Scala.Что такое типы классов? Роль их примерно такова, как у паттернов проектирования в Java, однако, они более гибкие и простые в использовании, как только вы крепко усвоите их смысл. По этому поводу есть несколько отличных руководств, например, 1, 2.
Что насчет конструкторов типов? Это такие типы как
Future или Option, служащие “контейнерами” или “обертками” для других типов. Так, у вас может быть Option[String] или Future[Int]. Типы высшего порядка позволяют писать код, обеспечивающий абстрагирование любой обертки. См. например. 1, 2.Вдруг вам интересно, зачем вообще прибегать к
Future/Task? Дело не только в том, что большинство высокопроизводительных «реактивных» вычислений с минимальными задержками выполняются с применением асинхронного ввода/вывода, для которого просто просятся именно такие конструкции. Другие причины приводятся в этой дискуссии на reddit и в моей статье “Зачем возиться с обертками?”.Работа в преимущественно неизменяемой среде, а также возможность с удобством обращаться с такими конструкциями как
Future, Promise или Task (и абстрагировать их!) радикально преображает ваш код. На первый взгляд это может быть неочевидно: если у вас за плечами опыт Java или Ruby, то осознать эти аспекты Scala вы сможете не сразу. Но, даже с образовательной точки зрения полезно разобраться, как устроен «функциональный» подход и, что гораздо важнее, почему он может оказаться весьма достойной альтернативой.Естественно, и у Scala, и у Kotlin есть ряд общих преимуществ по сравнению с Java, например:
- Более компактный синтаксис
- Меньше стереотипного кода
- Более насыщенная система типов
- Отсутствие языкового балласта
В то же время, оба языка открывают доступ к экосистеме библиотек и фреймворков JVM.
Чем насыщеннее система типов (в Scala она богаче, чем в Kotlin, а в Kotlin – богаче чем в Java), тем больше работы по верификации выполняется компилятором, а не человеком. Именно для этого и созданы компьютеры: выполнять скучные, рутинные повторяющиеся задачи. Проверка применимости типов – определенно, как раз одна из таких задач.
При этом насыщенная система типов полезна не только при написании кода, но и, в гораздо большей степени при чтении кода. Когда тебе легко сориентироваться в базе кода, понять, что он делает, а, к тому же, не страшно (или не так страшно) браться за его рефакторинг, это очень положительно характеризует язык как с технической, так и с прикладной точки зрения.
ФП vs OOП
Еще один вопрос, часто поднимаемый в таких дискуссиях – должен ли язык Scala и далее придерживаться синтеза ООП и ФП, либо развиваться по чисто функциональному пути. Я – сторонник синтеза, особенно потому, что ФП и ООП на мой взгляд – не альтернативные подходы, а дополняющие друг друга.
ФП – это программирование при помощи функций, правда, не любых, а референциально прозрачных (см. этот ответ на reddit в более раннем треде, где превосходно объясняется референциальная прозрачность). В ООП коммуникация с объектами организована при помощи “сообщений” или, в нашей терминологии, вызовов виртуальных методов. Нет ни одной причины, по которой два этих подхода не могли бы сосуществовать, и Scala это уже продемонстрировал!
В твите о достоинствах Scala Джон де Гоус упоминает некоторые черты ООП, полезные и при чисто функциональном подходе, в частности, модули первого класса (получаемые путем композиции объектов), точечный синтаксис (вызов методов в объектах) и классы/экземпляры типов как конструкции первого класса. Все это – элементы успешной комбинации двух парадигм. Может быть, еще какие-то не за горами?
Проект «синтеза» еще не закончен, здесь определенно остается поле для обсуждения. Один из незавершенных аспектов – это предлагаемый синтаксис методов расширения, который должен прийти на смену гораздо более путаным неявным преобразованиям. Другой – оптимизация синтаксиса классов типов; предложение по этому поводу, высказанное некоторое время назад, явно сырое и не охватывает некоторые из наиболее распространенных случаев использования монад в Scala. Некоторые предложения лучше, другие требуют доработки, но хорошо, что они поступают, и о них идут дискуссии; благодаря ним язык живет и, в конечном счете, в нем закрепляется наилучшее решение.
Scala 3
Scala 3 выйдет через два года. В нем появится ряд интересных возможностей, в частности, непрозрачные типы, параметры типажей, новый подход, связанный с метапрограммированием, типы объединения и & пересечения, неявные типы функций – вот всего несколько примеров. Конечно, здесь возникает (обоснованная) обеспокоенность по поводу миграции.
Уже известно, что будет представлен специальный инструмент для автоматической миграции кода со Scala 2 на Scala 3 при помощи scalafix. Поскольку Scala – статически типизированный язык, такая задача решаема в больших масштабах и гораздо проще, чем, например, на Python. Но, разумеется, никакой магии тут нет: даже если этот инструмент на 99% обеспечит правильное покрытие кода, все равно останется 1% наиболее проблемных случаев. Поскольку на магию рассчитывать не приходится, миграцию этих фрагментов нужно будет выполнить вручную.
Таковы издержки работы с активно развивающимся языком: вы получаете новейшие возможности, но некоторые из них на поверку оказываются не столь хороши и нуждаются в доработке. Даже с учетом этого, предлагаемые изменения не являются революционными. Язык Scala 3 очень похож на Scala 2, никаких серьезных изменений парадигмы не предвидится.
Обнадеживает тот факт, что команда Scala всерьез подходит к миграции. Тогда как ранее миграция между старшими версиями Scala (напр. с 2.8 на 2.9) была довольно обременительна, последние миграции прошли гораздо лучше. В них участвуют три основных стороны: EPFL, ScalaCenter и Lightbend все они (зачастую вместе) работают на облегчение миграции. Например, существует двоично-совместимый инструмент MIMA, а также в сообществе постоянно создаются многочисленные новые библиотеки, призванные обеспечить удобную работу с новыми версиями Scala.
Наконец, пока не законченный инструмент TASTY (который, соответственно, пока нельзя оценить) должен обеспечить использование двоичных файлов из Scala 2 в Scala 3.
Итак, зачем же использовать Scala?
Итак, каковы же причины остановиться на Scala, если рассматривать этот язык с точки зрения бизнеса? Все вышеперечисленные технические преимущества напрямую полезны и для бизнеса. Когда у вас есть язык, на котором можно писать сложный код с меньшим количеством багов – то вам обеспечены и минимальные задержки сроков, и довольные пользователи. Если вы станете писать на Scala мощные, практически не пробуксовывающие конкурентные приложения, для которых в Scala предусмотрены специальные инструментарии, то это обернется серьезной выгодой для вашей компании.
Кроме того, не забываем и о Spark, ведущей платформе для распределенного анализа данных. Scala используется не только для реализации Spark как такового, но и для определения самих вычислений. Вот вам еще одна data science-ориентированная абстракция, скрывающая сложную вычислительную модель.
Резюме
Разумеется, в Scala есть и проблемы, но где их нет? Повод для оптимизма заключается в том, что множество людей, использующих Scala ежедневно, активно работают над улучшением инструментария, библиотек и самого языка. Могу предположить, что они продолжают работать со Scala именно потому, что, при всех имеющихся недоработках, ни один язык так хорошо не подходит для их предметной области.
Scala позволяет вам развивать свой стиль программирования, каким бы языком вы раньше ни занимались: Java, Ruby или только пробуете себя в программировании. Не существует однозначно выигрышного подхода к Scala; можно придерживаться или более императивного подхода Akka, или более функционального подхода Cats и Scalaz.
Вот где можно усмотреть проблему: в сообществе Scala есть фракции, придерживающиеся “реактивного”, “синтетического” OOП/ФП подхода и чистого ФП. Однако, на самом деле в этом заключается огромное преимущество. Благодаря такому разнообразию ведутся дискуссии, высказывается множество различных мнений с разных точек зрения. На этом, в свою очередь, отлично можно выучиться нестандартному решению задач и обогатить собственный инструментарий.
Какой бы путь в Scala вы ни выбрали, вас поддержит внушительное сообщество коллег, занимающихся разработкой библиотек и фреймворков; эти люди всегда готовы помочь и обсудить возникающие идеи.
Комментарии (37)
wert_lex
14.09.2018 18:12Очень странная метаморфоза произошла с Typesafe.
Вообще, по моим ощущениям, примерно с того же времени в Scala начался какой-то застой. Если тогда появление Kotlin выглядело забавным, то сейчас выглядит так, будто новый JVM проект и в самом деле стоит начинать на Kotlin. Потому что действительно better java, а не wannabe haskell, со всеми вытекающими.
sndl
14.09.2018 18:40то сейчас выглядит так, будто новый JVM проект и в самом деле стоит начинать на Kotlin
Если у команды нет опыта на Scala, то может и стоит. В противном случае если есть экспертиза я не вижу смысла мигрировать на Kotlin.
Я вижу большую проблему адаптации Scala с нуля, с очень большой фрагментацией подходов и стилей библиотек. Но если у команды есть обозначеный путь и политика в отношении выбора, то разработка становится очень продуктивной и сильно превосходит Kotlin с его пока еще неразвитой экосистемойwert_lex
14.09.2018 18:52Согласен.
Я вижу большую проблему адаптации Scala с нуля, с очень большой фрагментацией подходов и стилей библиотек.
К этому могу добавить только то, что сообщество у Scala и значительно более скромное в размерах, и по ощущениям действительно чаще чем хотелось бы снобистское. Особенно это заметно когда перепрыгиваешь совсем на другой, более распространённый стек технологий.
time2rfc
14.09.2018 19:19Если не секрет, где Вы общались со снобами из scala-сообщества? Мне тяжело припомнить чтобы за последний год новичку не помогли советом в чате.
wert_lex
14.09.2018 19:55Едва ли смогу сейчас указать на что-то конкретное сейчас, потому что уже больше трёх лет не пишу на Scala, но это определённо были какие-то списки рассылок, связанные с функциональщиной вроде scalaz.
panchmp
14.09.2018 19:52ph_piter ну и где скидка для хабра? :)
уже нашел на habr.com/company/piter/blog/341808
nexus478
14.09.2018 22:51Но я считаю, что именно Scala, а не Kotlin, по-прежнему заслуживает такого звания. На то есть две основные причины:
Во-первых, неизменяемость в языке Scala первостепенна. Это связано с природой Scala как таковой: писать на нем код удобно прежде всего при помощи неизменяемых данных.
А чем иммутабельность в Scala отличается иммутабельности в Kotlin?
Neftedollar
15.09.2018 00:43При этом насыщенная система типов полезна не только при написании кода, но и, в гораздо большей степени при чтении кода. Когда тебе легко сориентироваться в базе кода, понять, что он делает, а, к тому же, не страшно (или не так страшно) браться за его рефакторинг, это очень положительно характеризует язык как с технической, так и с прикладной точки зрения.
Вот! Идеально объясняет почему C# у меня вызывает такое чувство обескураженности при подходе к любому проекту где уже потрачены сотни человекочасов, а с F# все проходит легко.
guai
15.09.2018 02:00как-то низко не упоминать цейлон, из которого через джва года скала допиз… дозаимствует систему типов
time2rfc
15.09.2018 02:25Не могли бы вы раскрыть мысль? Я правильно понял что Scala которую разрабатывают с 2004 года украла систему типов у Цейлона который разрабатывают с 2011? Или украдет в Scala 3.0?
У меня плохая память и даты я взял из википедии.guai
15.09.2018 03:01да, в скала 3.
в математических аспектах того, как поженить типы-пересечения и -объединения с наследованием, дженериками, и прочими, существовавшими до того, фичами систем типов разбирался конкретный человек — член команды цейлона. он же запилил систему типов котлина, о чем чуваки из джетбрэйнса тоже не любят распространяться. а теперь эти же фичи переползают в тайпскрипт и вот в скалу.
чем они 14 лет занимались — хз, пытались убедить народ, какой у них прагматичный язык получился со спейсшип операторами и встроенными html-тэгами, наверноеsolver
15.09.2018 12:19Спасибо, что объяснили основновные исторические пробелы создания скалы.
Не знал, что Одерски 14 лет пилил встроенные html-тэги, в ожидании пока освободится единственный на планете человек, который знает что такое типы-пересечения и -объединения с наследованием… Но слава богу, что через 14 лет ожидания он наконец освободился и смог запилить все необходимое для скалы.guai
15.09.2018 12:51а что конкретно Одерски сделал по теории языков программирования?
такие вещи не появляются из воздуха, у них есть конкретные авторы. это потом становится странно, а что же раньше никто так не делал, когда уже всё придумано и проработаноunabl4
15.09.2018 16:24lampwww.epfl.ch/~odersky/papers/#Scala
Вся информация тут. Не надо выставлять человека уж совсем идиотом.guai
15.09.2018 17:20я не считаю его идиотом, он выдающийся инженер
но всякий ли выдающийся инженер сделает хороший прагматичный язык программирования — думаю, скорее, не всякий
а еще мне не нравятся попытки со стороны комьюнити скалы объяснить окружающим программистам, какая скала на самом деле практичная, и замести под ковер тот факт, что это всегда был исследовательский проект. переубедить, а не исправить косяки.
возможно, в этом плане что-то поменяется в третьей версии как раз, посмотримunabl4
16.09.2018 01:39Каждый понимает «прагматичность» по своему.
Я не могу себя причислить к скала сообществу, потому что я не работаю с этим языком на постоянной основе. Но приходилось писать несколько проектов в прошлом на базе Play Framework. Перед этим я прошёл вводный курс по скале на курсере (который опять же ведёт Мартин). От этого языка всегда веяло какой-то академичностью — такое ощущение, как-будто его с интересом и любовью препарировали в стенах университетских лабораторий :) Я, кстати, не припомню, чтобы это кто-то скрывал.
И вот появился этот монстр, в основе которого JVM с своими возможностями и ограниченями, на которое сумели взгромоздить и FP и OOP, подружив их друг с другом, и доселе невиданную систему типов (я честно не знаю, украли ли они её у кого-то или сами придумали) и ещё бог пойми чего и всё это ещё и под соусом обещаний интероперабилити с java, type-safety, иммутабельности и т.д и т.п. Иронически, получился швейцарский нож. Университет EPFL, в котором преподает Мартин, так же находится в Швейцарии (Лозанна) :)
И вот тут уже конечному разработчику решать, как с этим многофункциональным ножом играться. Если юзать его аккуратно, как better java, оно, на мой взгляд, довольно хорошо работает. Писать на скале, как на улучшенной джаве действительно удобно и приятно. Прагматично? Ну, возможно.
Но можно заиграться и перерезать себе все руки (прежде, чем отстрелишь ноги) — любой обфускатор позавидует. Концов не соберёшь — в какой-то момент сдавался даже IntelliJ Idea для скалы. Отдельно радует SBT, в котором есть операторы, которые даже загуглить нельзя. :)
P.S. Я потом ещё прошёл курс по реактивному программированию на базе скалы — это просто взорвало мой мозг.guai
16.09.2018 02:16ну как «по-своему»?..
не раз видел, как разные команды приходят к примерно одному списку критериев прагматичности: починить косяки предшественников, при этом не трогать то, что и так было нормально; чтоб тулинг был возможен; и чтоб компилялось быстро. это навскидку самое основноеunabl4
16.09.2018 15:58У всех команд разный опыт, разная экспертиза и, как следствие, может быть совершенно иное видение того языка, который бы больше подходил под их конкретные задачи и требования. Для кого-то динамическая типизация = прагматичность — тогда не надо беспокоиться о системе типов (которая может быть очень даже непросто для понимания) или о скорости компиляции. Кто-то исходит из «модности», «хайповости», трендовости, размера и/или активности сообщества — как быстро можно загуглить ту или иную проблему или как быстро можно получить ответ на stackoverflow. Скала уже давно прошла свой пик популярности. Тот, кто с ней остался, вполне отдаёт себе отчёт — что, зачем и почему.
guai
16.09.2018 16:21я имел в виду команды разработчиков языков программирования и то, что они хотят заложить в свой продукт
unabl4
17.09.2018 11:48А, прошу прощения — неправильно понял о ком речь.
www.artima.com/scalazine/articles/origins_of_scala.html
Тут есть некоторые пояснения :)
Интересно, насколько корнями Scala уходит в самую первую Java и ранее. И как сама Scala, которая частично «базировалась» на малоизвестных Funnel, Pizza, в каком-то даже смысле опережала развитие Java на тот момент.
wert_lex
16.09.2018 19:08Вот кстати из моего наскального опыта, использовать scala как better java — это в самом деле дорога в никуда. Язык действительно достаточно хорошо заточен на то, чтобы возлюбить FP, FRP, иммутабельность. Правда в какой-то момент надо научиться понимать во что это всё хотя бы примерно компилируется, но тем не менее.
time2rfc
16.09.2018 02:03Не знаю с каким сообществом Вы боритесь, при мне никто таким не занимался, никто под ковер ничего не заметал.
Одна из сторон прагматичности в моей работе со Scala — количество ваканский, уровень зп и достаточный уровень сообщества для решения проблем.
DarthVictor
15.09.2018 15:09+1А можно чуток подробностей? Просто я например до этого бы уверен, что и первые и вторые и третьи просто взяли систему типов Ocaml.
guai
15.09.2018 16:05безусловно, ноги растут еще из ml и ocaml.
я их не знаю в должной мере, чтобы составить исчерпывающий список отличий, но очевидно, если бы там всё уже было в том же самом виде, не надо было бы ждать больше десяти лет, чтобы начать это повторять в скале, можно было еще в первой скале позаимствовать.
какие-то намёки на типы-пересечения и -объединения есть даже в яве. в catch(FooException | BarException e) у нас практически тип-объединение. или вот так можно: void printAndClose<T extends Printable & Closeable>(T arg)
в недрах компиляторов эти вещи тоже были до того, дело оставалось за малым — понять, что за частными случаями скрывается более общая красивая математика, которая упростит работу с типами, сообразить дать этот инструмент программисту, придумать синтаксис, попробовать кучу вариантов совмещения новой фичи с имеющимися.
а так да, всё уже было :)
wert_lex
15.09.2018 16:48А можно подробнее про этого человека? Возможно у него есть имя? Было бы интересно узнать.
guai
15.09.2018 18:10Росс Тэйт
вообще, рекомендую сайт посетить ceylon-lang.org
там не только система типов крутая, но и много чего еще. доки хорошие, и что мне больше всего нравится, не только описано, что сделано, но и почему сделано именно так. и на гитхабе обсуждения фичей интересно почитатьwert_lex
15.09.2018 19:57+1А и в самом деле интересный товарищ http://www.cs.cornell.edu/~ross/
Спасибо
nlinker
17.09.2018 14:34Вы по всей видимости говорите о Ross Tate который ведёт свою научную деятельность с 2010-го года. Его работа наверняка повлияла на Цейлон, Скалу и Котлин,
Однако Intersection и Union Types были изобретены (открыты?) и изучались задолго (эта статья 1995-й года и есть ещё более ранние) до работ Росса, и появлялись во многих экспериментальных языках. Изучать эту тему мог кто угодно, в том числе и Росс, и Мартин, и другие учёные.
Сама же Scala 3 базируется на компиляторе Dotty, основой которого является исчисление Dependent Object Types. Обоснование этой системы типов выполнено в-основном аспирантами Мартина (Nada Amin, Samuel Grutter, Tiark Rompf и Sandro Stucki). Intersection и Union типы являются частью DOT и используются для описания наименьшей верхней границы (least upper bound) для if- и match- выражений.
Так что 14 лет для построения компилятора, поддержки и развития ветки Scala 2, переосмысления ошибок, создания новой системы типов и доказательства её корректности, построения нового компилятора Dotty и использование его как бэкенда для языка Scala — вот для всей этой работы 14 лет для меня не выглядит сильно уж большим временем.
JediPhilosopher
16.09.2018 21:41+1Зачем человеку Скала? Повыпендриваться и поразминать мозг — да, но уж точно не упростить себе жизнь.
Имею опыт внедрения скалы в продакшене (чего, как мне кажется, нет у большей части горячих фанатов этого языка). Начиналось это как небольшой вебсервис почти без бизнес-логики (перекладывал объекты из одного апи в другое), поэтому решил немного поэкспериментировать, так как это казалось безопасным. Разумеется пару лет спустя оно переросло в здоровенный сервис и обросло кучей фич. Никогда такого не было и вот опять, да. И началась боль.
И дело даже не в том что писать на скале сложно, как язык она мне скорее нравится чем нет. Но вот поиск сотрудников под это дело… он непрост. Далеко не все разделяют мое желание изучать этот язык и переезжать с джавы. Новых сотрудников на скалу фиг найдешь, а если и найдешь — то за очень высокий ценник.
Ковыряться в библиотеках — то еще удовольствие. Тут не работает вариант "использовать то что нравится, а всякую сложную хаскеллеобразную муть не использовать, если не хочется". Потому что разработчики библиотек зачастую придерживаются другого мнения, и их апи представляет густо замешанную смесь из монад, функторов, имплиситов, присыпанных всякими scalaz-штуками, от которых у меня глаза кровоточат когда я пытаюсь понять, что это все значит.
В итоге столкнулся с тем, что:
- Профессиональных скалистов взять негде
- Профессиональные джависты не горят желанием менять джаву на скалу. Раньше еще можно было убеждать всякими красивыми фишками, но после выхода 8 джавы с лямбдами и стримами число фич, ради которых стоило бы учить скалу сильно сократилось. А многие из колеблющихся сделали выбор в пользу Котлина, который красивее, проще и интероп с джавой легче делается
- Написание кода сильно замедляется без какой-либо выгоды для бизнеса, так как приходится курить мануалы и страдать при попытке лазать в библиотеки
В общем никому не порекомендую повторить это. Если у вас нет команды звезд ФП, то никакого профита с переезда на скалу не получите, только боль.
На хабре уже когда-то был перевод статьи на эту тему https://habr.com/post/273535/, могу в целом подтвердить со своего опыта что так оно и получается.
Конечно всегда можно сказать, что это мы (и команда в статье по ссылке) сами дураки и просто скалу готовить не умеем. Ну ок, может и так. Но возможно именно поэтому (что все вокруг дураки, не умеющие готовить) скала взлетает-взлетает уже пятнадцать лет, а так взлететь и не может, и я думаю с появлением Котлина сдаст еще часть своих позиций.
time2rfc
17.09.2018 00:17+1Имею опыт внедрения скалы в продакшене (чего, как мне кажется, нет у большей части горячих фанатов этого языка).<
Интереса ради, не споров для — а где Вы с фанатами Scala общаетесь ?P.S.
Был перевод на хабре, о том что сам Одерски считает успехом не 1000 сервисов на Scala а Spark и Kafka.JediPhilosopher
17.09.2018 13:12Да вот тут в комментариях на хабре. Практически к каждому такому посту (в том числе и к тому, на который я ссылку дал), набегает в комментарии куча народу с криками МОНАДЫ! ТАЙПКЛАССЫ! и закидывает какашками тех, кто пытается объяснить что для успешного внедрения языка нужны не такие фичи, а простота разработки, который в скале с точки зрения среднего разработчика нет. А на все рассказы о сложности поддержки скала-программ они начинают кричать что мол это те кто внедрял — дураки.
Плюс пару раз общался с адептами ФП (не скалы) в реальности, там примерно то же самое — яростная концентрация на инструменте, а не на решаемых задачах.
Ну а Одерски считать-то может что угодно, его мнение к тому же вряд ли можно считать непредвзятым. История показывает, что сейчас зачастую даже изначально скала-сервисы постепенно возвращаются к джаве (подтягивают апи, документацию в джава-части), видимо какое-то определенное разочарование наступило.
AlexTheLost
Имхо, Scala хорошо развивает мозг и позволяет обогатить себя как профессионала за счет изучения новых подходов и принципов.
Но как язык промышленного программирования я бы не стал его использовать. Когда работаешь в команде понимание кода других участников может быть затруднительно, даже если вы более менее согласились с тем что и как будете применять. Разработка на Scala даёт много вольностей и возможности написать сложный для понимания код. Чем любят заниматься люди с целью повышения своего ЧСВ.
Сама Scala мотивирует активно думать над тем что бы писать выского абстрактный код и постоянно планировать абстрактную архитектуру. Что ни как не помогает быстро и качественно решать задачу а скорее подобно творчеству. А когда эта абстрактная архитектура написана кем то другим понять её зачастую затруднительно, хотя задачи которые она решает могут быть достаточно простыми.
Так же такую сильносвязанную абстрактную архитектуру сложно рефакторить. Потому что хоть она и должна быть отстранена от прикладной задачи(суть абстракции), в реальности основана на решаемой задаче, а новые задачи(бизнес требования) могут требовать существенных измений в коде для поддержки его согласованности или костыля, что обычно и происходит, со временем сильно ухудшая понимание кода.
По этому я начал искать другие языки которые позволяют писать быстро и качественно. Остановился на Clojure и очень доволен, язык соответствует тому что я хотел найти — быстро писать качественный код.
time2rfc
Спасибо за интересную причину не использовать на проде скалу, мне повезло работать в командах где с этой проблеммой не сталкивались, и ваш взгляд помог посмотреть немного под другим углом.
Имеющийся у меня опыт, подсказывает что на Java гиганты мысли могут написать вещи не менее страшные, ЧСВ ради, и сложность кода довольно часто не про язык а про уровень инженерных практик.
AlexTheLost
Согласен что уровень практики и контроля очень важен. Но всё же я больше хотел сказать что есть языки где при сопоставимом уровне 'инженерной практики' можно получить лучший результат. Java я бы не стал приводить как контрпример Scale т.к. она также имеет массу нюансов, но своих своих.
sndl
Я соглашусь, Scala позволяет писать высоабстрактный и «совершенный» код и этим притягивает определенный круг разработчиков, но дальше все зависит от индивидуальности разработчиков и культуры команды.
У нас, например, поощряется писать более простой код, хоть иногда и чуть больше, а иногда и чуть продублировать.
Apache Spark со своим style guide пример как огромное количество котрибьютеров с разным бэкгроундом может работать над одной большой кодовой базой
Twitter — отличный пример из индустрии, избегающий все упомянутые высокоабстрактные архитектуры и продолжающий с успехом использовать Scala
dborovikov
А вам не кажется, что язык программирования — крайне слабый и не уместный способ enforcement of policies (как это по русски — навзязываение политик, хз)?
Если в команде анархия и нет ни ревью, ни guidlines, нет способа рассмотрения и принятия архитектурных решения, то что-то не так в царстве датском.