Это заключительная часть расследования о Scala-движении в России. В первой части я узнал от Романа Гребенникова о воронежском бомонде, C++ и Erlang, а от Романа Тимушева о первой Akka и рождении московских митапов. Во второй части побеседовал с Александром Подхалюзиным и Михаилом Муцянко: знакомство со Scala, 2007-й, Scala Days, Scala Native, переход в Kotlin, чем Scala хороша для банков, первые ивенты в Санкт-Петербурге, Eclipse, Jason Zaugg, IDE и Scala Plugin.
Во время подготовки второй части Владимир Успенский (vuspenskiy) направил меня к Александру Подхалюзину, с которым мы записали огромное интервью. На следующий день я получил от Владимира сообщение, но теперь уже с его личной историей: Qiwi, Scala в Тинькофф, первые встречи, ссылки на старые блоги (отдельное спасибо за это), и функциональщина из 2008 от Rúnar, которая исполняется на Java, — этота еще кровь из глаз как минимум необычно. В дополнение — истории Романа Елизарова, Алексея Фомкина и Николая Татаринова. Особенности найма Scala-разработчиков, курсы на Coursera, «идеальный код», «демоническая» компиляция, дизайн в Kotlin, 10 000 строк кода, интернет-банк Тинькофф, опять Тинькофф, Play Framework, скончавшийся Flash, «Восход» и питерские митапы — обо всем этом в заключительной части трилогии под катом.
Владимир: В то время я работал в Qiwi и перерефакторил много кода на Java, но всё равно получалось много воды и бойлерплейта. Я мучался, но как-то смирился.
Через какое-то время вышел на блоги Александра Темерева и Влада Патрышева. Влад был в первых рядах ещё по внедрению Java, как я понял. Прочитал у них о Scala, начал замечать упоминания странных тогда для меня конструкций вроде опций на Java. Эту опцию я даже пустил где-то в продакшн. Были и более экзотичные Lazy Error Handling in Java и Higher-Order Java Parallelism от Rúnar Bjarnason. Все это адски взрывало мозг и было интересно, как это все применить.
Когда изучал конкретные примеры, например, у Daniel Spiewak: Scala for Java Refugees, это было именно то, чего мне не хватало. Ушла вся вода и странные непоследовательности, вроде
Это была Scala 2.7 и, мягко говоря, она не была стабильной. Многие проекты пробовали её для unit-тестов или Case Classes. Чтобы добавить Scala в Java-проект надо было настроить joint-компиляцию в Maven. Но я решил попробовать и добавил поддержку в один некритичный проект в Qiwi. Всё заработало — я был очень рад, но на том всё закончилось.
Неожиданно меня позвали в Тинькофф руководить разработкой нового интернет-банка, который полностью разработали внутри компании. Сначала я разобрался с текущими задачами, но когда добрался до backend, понял, что пора внедрять Scala.
Как раз вышла Scala 2.9 с современным, на то время, синтаксисом. Модные параллельные коллекции отлично подходили, чтобы что-то быстро запускать параллельно, если не принципиальны детали. Да ещё и создатель Groovy James Strachan выдал: «I can honestly say if someone had shown me the Programming Scala book by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I’d probably have never created Groovy».
Другой фактор выбора Scala это то, что все люди, которые тогда работали над инструментами, языком, библиотеками или писали о Scala, были суперумными и энергичными. Поэтому была уверенность, что это правильный выбор для будущего.
Как раз во время работы в банке, я начал ездил на зарубежные конференции. Первые Scala Days в 2012 году, гиковский flatMap в Осло. В то время я познакомился с Женей Бурмако. Сейчас мы иногда прогуливаемся вдоль океана уже здесь, в Калифорнии.
Постепенно написали интернет-банк. В 2012 году он стал лучшим в России по версии Global Finance. Для меня это подтверждение утверждения «Нормально делай, нормально будет», а не что-то экстраординарное.
Олег Тиньков продвигал тему банка, что было забавно. Возможно, это помогло нам нанимать хороших разработчиков — люди в команде были, но хотелось расширять. Сначала мы писали в вакансии «Java-программист, Scala — плюс». Но упоминание Java в вакансии для Scala-разработчиков отрезает людей, которые не хотят иметь ничего общего с Java. Поэтому мы изменили вакансию на «Старший разработчик Scala». Это позволило нанять пару ребят, с которыми я бы очень хотел ещё когда-нибудь поработать.
Мне хотелось понять кто вообще в России и Москве тоже независимо заинтересовался Scala, и какие у сообщества мысли. Встреч или чатов не было, и появилась идея всех собрать. Сделал группу на Facebook, в которой мы спланировали несколько первых митапов. Какой же митап без группы на Meetup? Пошёл создавать, а группа уже есть — Роман Тимушев создал. Мы решили объединить силы, и еще добавили Мишу Аксарина.
Первую встречу собрали под предлогом Scala-курса про реактивное программирование на Coursera. Многие приглядывались, но пришло около 20 человек: познакомились, рассказали кто чем занимается и интересуется, пообсуждали упражнения с курса и договорились встретиться ещё.
Так и понеслась.
Роман Елизаров (elizarov) — руководитель группы JetBrains, участвовал в работе над корутинами, библиотеками в Kotlin.
Примечание автора. Перед записью интервью, я подумал, что получится беда, если я буду брать их только у людей причастных к Scala. Сплошные «обожательства» или, что хуже — «ошибка выжившего». Поэтому я решил, что обязательно добавлю ложку дегтя.
С этим сложнее — людей с реальным опытом, которым почему-то не зашел язык, на порядок меньше, чем хейтеров с нулевым опытом в Scala. Но тут я вспомнил пост Романа Елизарова (elizarov) — руководителя группы JetBrains — в котором он между делом набросил на Scala, что вызвало множественные подгорания, в том числе и у меня. Несмотря на негатив, вряд ли Роман написал пост по каким-то слухам о языке. Должна быть причина, какой-то негативный опыт от использования — так и оказалось. Ниже интервью с ним как раз об этом, и немного обсуждений о дизайне и связи корутин со Scala CPS Plugin.
Роман Елизаров: Примерно с 2000 года я программировал на Java всякие энтерпайзы. Поэтому следил за JVM-языками, в том числе за Scala. Кажется, что первый раз я прочитал о языке примерно в 2005-2006 году.
Когда ты абстрактно читаешь, синтаксис, всё очень круто. Я помню, прочитал описание, поигрался, и мне всё очень понравилось. Многие вещи, которые в Java подробные и тяжелые для работы, в Scala сделаны удобно. Меня это все интересовало уже тогда не с точки зрения ФП, а с прагматической — как мы пишем код. Но, так как кодовая база на Java уже большая, куча текущих занятий, воспользоваться на практике не удалось, пока не произошла история в 2010 году.
В 2010 году наши партнеры из Штатов, из энтерпрайза, заскучали. Им захотелось новизны, и они написали новую подсистему целиком на Scala. У него был какой-то web-интерфейс, он делал что-то несложное. При этом это никакой не Play Framework — просто web-сервис принимал запросы от пользователей, вызывал Java API. Нормальный web-сайт для выполнения каких-то внутренних интерактивных функций. Партнеры его запилили, он успешно работал, всё хорошо.
В то время мы были их подрядчиками. Разработчики подсистемы наигрались и решили заниматься другими делами. Наши клиенты пришли к нам и говорят: «Ребята, возьмите эту штуку на поддержку? Она же все равно использует ваше API». Отлично, вот он — реальный способ попробовать со Scala. Так бы нам никто не разрешил программировать на Scala, потому что всё жестко, но так как уже есть проект — вот и повод. Это, собственно, первый продакшн-опыт со Scala.
Первое впечатление от Scala — это насколько код компактней, чем в Java. Scala позволяет сложные вещи записывать компактно. Подсистема занимала примерно 10 000 строчек кода, но на Java это заняло бы в два раза больше из-за классов. Синтаксис, все внутренние объекты для передачи данных, даже вся адаптация Java API — все компактно.
Когда разработчики ушли, они оставили код в разобранном виде — в том смысле, что просто код. Мы попробовали взять его на поддержку, но появилась проблема — компиляция.
Скомпилировать Scala-код это квест. Код компилируется только с конкретной версией Scala Compiler — с точностью до точка-версии, до патч-версии. Версия больше или меньше — уже не компилируется.
Это решило для меня в 2010 году судьбу Scala в энтерпрайзе, где миллионы строк кода. Страшно представить как жить, если ты меняешь минорную версию компилятора и ничего не собирается.
— Точно не вспомнишь, почему?
Роман Елизаров: Почему она разваливалась точно не вспомню, конечно. Что-то там постоянно менялось от версии к версии. Может, мы попали в неудачное время?
Но я продолжил следить за развитием Scala, несмотря на то, что только в энтерпрайзе так мы не внедрили. В итоге функционал перенесли в другие Java-приложения. На этом Scala в этой компании перестала существовать.
Эти 10 000 строчек были первыми и единственными. Код достаточно долго проработал в продакшн, но потом были разобран по другим сервисам и устранен.
Конкретно моей профессиональной деятельности этот опыт оставил неизгладимый след, в том смысле, что всё-таки нужна совместимость этого всего. Сейчас я занимаюсь Kotlin. Неудивительно, что мы просто нереальное количество времени и дополнительных сил тратим, чтобы обеспечить совместимость всего и вся. Порой дикое количество времени уходит не в функционал, а просто, чтобы всё было совместимо. В том числе, на это влияет мой прошлый опыт.
Еще постоянно вспоминаем Python. По поводу совместимости у нас две баги: Scala и Python. Когда заходит речь о совместимости, никто не хочет повторения перехода со 2 на 3 Python, и никто не хочет быть как Scala.
— Часто хочется что-то переделывать так, чтобы было всё «шоколадно»?
Роман Елизаров: Я занимаюсь дизайном и мне постоянно хочется все переделать. Мне никогда не нравится то, что я сделал. Пока я подготавливаю нечто к релизу, то нахожу несколько вещей, которые хочется поменять. Как только я что-то зарелизил, уже вижу в нём недостатки: это не доделано, здесь надо переписать с нуля. Но это путь в никуда. Есть только два подхода: либо я буду улучшать код до бесконечности и никогда не доберусь до релиза, либо запущу в релиз и это станет Legacy. Нельзя зарелизить идеальный код.
Дальше я половину времени трачу на улучшение продукта, а вторую — на совместимость с тем, что уже зарелизил. Опыт помогает заранее «подстелить соломки». Я вижу, что скоро придётся переделать, и много времени в момент релиза трачу на подстраховку в ожидании будущих изменений. Конечно, делать что-то с нуля и не заботиться о совместимости намного проще. Но компромисс в том, что либо ты делаешь идеально, либо твой продукт используют. Одно исключает другое.
Роман Елизаров: Я непрерывно следил за Scala, потому что когда мы дизайним что-то в Kotlin, то изучаем, что есть в других языках, в том числе в Scala. Года два назад мы дизайнили Kotlin корутины. Основное «вдохновение» — это, конечно, C#. Всё началось с него и оттуда уже родилось вот это вот всё. Потом уже мы стали изучать Go.
Когда дизайн стал отклоняться от C# и появились «continuations», а потом и «delimited continuations», мы стали в очередной раз изучать другие языки. В Google я натыкаюсь на Scala — оказывается в нем уже были «delimited continuations».
— Это ты про Compiler Plugin?
Роман Елизаров: Да. При этом дизайн был фантастически похож на тот, что сейчас в Kotlin. Есть, конечно, синтаксическое отличие: в Kotlin мы пишем модификатор «suspend» в начале, а в Scala ты писал аннотацию csp на возвращаемое значение. Но какая разница где ставить модификатор: в типе возвращаемых значений или в начале?
Дизайн в Scala был очень похож на текущий в Kotlin. Я заинтересовался — как же так, раз такой клёвый дизайн, почему не полетел? Почему в современном Scala так никто не пишет? Мне показывали как там пишут в Play Framework — там нет никакого плагина.
Все пишут фьючи, а у нас была замечательная идея фьючи изжить, потому что этот дизайн удобней. Так и получилось в Kotlin: фьючи не нужны, есть корутины. В Scala же отказались от «continuations» и не полетело. Почему?
В процессе поиска я нашёл самый оригинальный анонс. В тот год в Scala появились «delimited continuations». В Scala тогда всё делалось то же самое, что сейчас в Kotlin.
Анонс в этом смысле показателен. В нем говорилось: «Мы сделали „delimited continuations“, смотрите, мы можем писать такие же клевые штуки, как в Lisp». Для примера взяли пример на Lisp из работ 80-90-х годов, и переписали на Scala: списочки состыкованы, тут «shift/reset». В Lisp и подобных языках есть конструкция для delimited continuations, которая обозначена как «shift/reset». Название взрывает мозг — никто не знает, что такое «shift/reset». Ни тот, кто изучал Lisp, ни тот, кто никогда с ним не встречался.
Главное в этом анонсе это комментарии типа такого: «This makes about zero sense. I just spent some time on Wikipedia as well as a few other places to try to understand this. From my perspective, these are convoluted ways of adding numbers and I have no idea what is being gained or accomplished». Они объясняют всю суть поста.
Поэтому такой анонс важной фичи абсолютно бесполезен. Если его прочитает человек, который пишет код для приложения, то он не получит ответ на вопрос: «Зачем это мне вообще нужно? Какую проблему это решит?» Такой вопрос автором и не ставился. Поэтому фича и не полетела — не потому, что плохая, а потому что задачи полететь не было.
— Ее неправильно подали?
Роман Елизаров: Да, неправильно подали. Её как бы анонсировали, но не объяснили зачем она нужна и какие проблемы может решать. Но дело не «правильности» или красоте. Мы в Kotlin, кстати, тоже не умеем писать красивые блогпосты, но для правильной подачи написать красивый анонс недостаточно. Правильная подача — это не столько объяснение зачем, а еще объяснение с точки зрения API.
Я читаю код, а там используются методы «shift/reset». Почему в 70-х это назвали «shift/reset»? Пытался найти автора названия из прошлого, но не смог. Просто кому-то пришло в голову это название. Современному программисту вообще ни о чём эти слова не говорят. Они ничего не значат.
Я занимаюсь корутинами столько, что кажется, должен всё про них знать, потому что прочитал кучу научных работ. Но когда я вижу код, который использует «shift/reset», каждый раз напрягаюсь, чтобы понять, что там происходит и зачем вообще это надо. Это кажется какой-то черной магией, при этом бессмысленной.
Алексей Фомкин (yelbota) — программист, спикер, подкастер, Open Source контрибьютор, Scala энтузиаст.
Примечание автора. После отхода от дел Тимушева и Успенского, весь движ в Москве держался на Алексее Фомкине. Помимо этого, он запустил подкаст Scalalaz, и заглядывал в другие подкасты: DevZen, Разбор Полетов, Remote Talk. Пропустить его в этом цикле статей, было бы большой ошибкой.
Алексей Фомкин: У меня, наверное, все будет очень скучно — ничего интересного и не было. У меня есть моя личная история. Она интересна мне, но для читателей, возможно, будет скучна.
Вообще, я занимался Action-Script, а позже у меня был собственный небольшой бизнес. Когда бизнес закрылся, я остался без всего, потому что Flash к тому времени сдох. Соответственно, ничего другого у меня в резюме не было. Я искал работу, был эмоционально подавлен, потому что все потерял.
Я не видел себя не то что техническим директором, даже тимлидом. После неудачи со своей компанией, амбиций было только на рядового программиста. Пытался устроиться JS-разработчиком в Яндекс. Но мне отказали, потому что я плохо его знаю — что было правдой, конечно.
Тогда я вспомнил о Scala. Я ее пробовал многократно, начиная с 2010-го года, — язык мне нравится. Пробовал я потому, что в конторе, в которой я работал в 2010-ом году, был OСaml. Мне хотелось, как OCaml, только чтобы был JVM — она мне нравилась. На стороне я написал несколько проектов на Scala, а в 2014 году уже начал применять в своей компании.
Возникла идея двигаться в сторону Scala: много предложений, много проектов, а разработчиков дефицит. Тогда я напрягся и за несколько месяцев подтянул и актуализировал все свои знания. Мне повезло — я устроился техническим директором и набрал Scala-команду.
Одновременно с этим я подумал, что надо пытаться мутить какие-то штуки, пока тема не сильно развита в России. Поговорил с Успенским, Тимушевым и Аксариным. Оказалось, что Аксарин остался один — Успенский был «на чемоданах». Я поговорил, устраиваете в Meetup или не устраиваете. «Да, устраиваем». И это был последний митап, который устраивала старая команда. Это было в каком-то госучреждении, НИИ «Восход» Я сходил туда, рассказал про Scala JS что ли, а потом вообще эта тема заглохла. Раз все так плохо и нет никакой активности, я решил все организовывать сам — начал активничать в Skype-чате, в котором тусовались скалисты.
— Сколько там было людей?
Алексей Фомкин: Не помню — их и в современном чатике немного. Основной костяк — это человек 10-50, которые постоянно разговаривают. Остальные приходят, уходят, спрашивают вопросы — также, как сейчас.
Это был 2015 год: Skype-чат, Scala.js, первые митапы вместе с компанией, в которой работал. Мы мощно использовали Scala, а я продвигал Scala.js. Ходил ко всяким JS-разработчикам, в подкасты, рассказывал о Scala.js и звал на Meetup.
В 2016 году мы стартанули подкаст. Я кинул клич и откликнулось много народу. В принципе, практически все до сих пор и остались, кроме Тараненко. Потом подключились Григорий Помадчин и Оля Махасоева.
— Кто-нибудь помогал с митапами? Я расстроился, когда ты уехал — будто все заглохло.
Алексей Фомкин: Внутри компании помогал Макс Павлов. Он умеет программировать, но больше менеджер. Я занимался докладами, Scala-частью, а Макс помогал с организацией: помещение, оборудование, регистрация.
Все спонсировалось Data Monsters, она же Flexis, она же Adi Sait — в разные времена разные названия. Я там как раз тогда работал. Еще один Meetup я провел в 2018 году. Он был один.
Николай Татаринов — разработчик в SoundCloud, бывший организатор SPb Scala Meetup.
Примечание автора. Теперь о питерской ветке митапов. Хотя они и стартанули не так давно, прошло уже 9 мероприятий. По качеству проведения они сильно подняли планку: свой канал на YouTube, прямые трансляции.
Один из организаторов — Николай Татаринов. Хотя сейчас он уже отошел от дел из-за переезда, но я пришел к нему со стандартными вопросами. Николай рассказал про заход в язык, движуху, немного затронул статус Play Framework до релиза 2.0 и судьбу Actor Messaging.
Николай Татаринов: На моей первой работе в 2012-ом году мы использовали еще первый Play Framework. Он был сделан по подобию Rails. Было интересно, потому что у нас было приложение, в котором было легко проводить изменения. Но оно было в состоянии прототипа — не эволюционировало в какую-то продакшн-систему. Там было все намешано — так и развивалось.
В первом Play Framework была Java и Groovy. Все было самописное, даже система сборки какая-то урезанная — просто какие-то Python-скрипты. Это не библиотека, которую надо подключать в Maven или Sbt. Это было полностью рабочее решение — берешь Play Framework и запускаешь Play Framework.
По ощущения, в первом Play Framework гораздо меньше возможностей расширяемости, чем во втором. Во втором есть отдельная система сборки — свободно выбираешь, как именно делать и все работает «из коробки».
Я узнал про второй Play Framework, и, что там есть Scala, но, что за язык — не имел понятия. Решил попробовать написать что-нибудь на втором Play — было очень неудобно. Я не понимал, что происходит — все было иначе, чем в первом. Нужно было писать гораздо больше бойлерплейта, все явно прописывать. В первом Play Framework те же самые роуты решались соглашением на счет того, где лежат контроллеры. Во втором все приходилось писать руками, и собирать тоже руками.
C первого раза новая версия Play Framework мне не понравилась. Мне показалось, что это как-то странно, и сама Scala не очень понятный язык. Все это на время отложил.
В 2013 была конференция в Пензе — «Secon», на которой выступал Лев Валкин. Он приезжал в Пензу, рассказывал о ФП — было интересно, что-то новое. Я подумал, что надо посмотреть в сторону Scala. На какое-то время забыл, а потом наткнулся на курсы по Scala на Coursera.
Первый курс назывался «Функциональное программирование в Scala». Я решил его пройти, посмотреть, что это такое. На курсе было базовое понимание, но мозг порядочно взрывался — перестраивался, когда думал о программах, как все строится. Прошел курс, узнал базовые вещи, но на первой работе затащить Scala не получилось.
Зато я стал активно использовать Guava во времена 7-ой Java. В нашем проекте появились всякие трансформации: когда тащишь данные и начинаешь их трансформировать. Это было странно. Наверное, после того, как я ушел, это все выпилили.
Николай Татаринов: Я прошел курс в 2014 году. В это время я начал искать работу, и подумал, что было бы неплохо найти что-то на Scala. В итоге в 2015 в Питере устроился в стартап, который разрабатывал платформы для месседжинга Actor. Сейчас его уже нет, но зато есть Dialog, который используется в Сбербанке.
— Dialog на базе Actor?
Николай Татаринов: Да. Часть команды, которая работала над Actor, стала разрабатывать Dialog. Я не знаю, насколько там много Actor. Возможно, все уже переписано, но связь есть.
Итак, я устроился в Actor, переехал в Питер и начал работать. До этого опыта в продакшн со Scala вообще не было — было непросто держать вот это вот все. Первый курс дает понимание о ФП, о синтаксисе Scala, знание каких-то паттернов, но как композировать и обрабатывать ошибки и все такое — ноль.
В работе с продакшн-кодом в Scala одна из первых задач, которая возникает — как это все скомпозировать так, чтобы имело смысл. При этом важно не кинуть где-нибудь посередине исключение, даже если хочется. Все это было самое сложное, но интересное, в начале.
Задачи, которые мне давали, я дико затягивал. Я думал, что все нужно делать по функциональному, не как в Java и все такое. Со временем многое меняется — постепенно понял, где и что лучше использовать. В итоге, где-то через полгода, стал чувствовать себя комфортно с языком и всем инструментарием. Примерно так я вкатился в Scala.
Следующие работы, которые я находил, тоже были связаны со Scala. Сейчас работаю в SoundCloud. Здесь тоже большая часть сервисов на Scala.
Николай Татаринов: По поводу сообщества. IT Global Meetup — слет IT-сообществ, проходит 2-3 раз в год. Разные сообщества там выступают с разными докладами. Одно из них — FProg Spb. Они больше в функциональщину: там есть кложуристы, скалисты, хаскелисты, да и более специфические вещи, типа Coq.
Я был далек от всего этого. Одно время ходил к ним, но чаще это либо о Clojure, где все относительно понятно, без усложнений — базовые вещи, либо они доказывают теоремы через Coq, жесть, хардкор и я ничего не понимаю. Для меня серединки не было.
Я никого не знал из тех, кто занимался Scala. Но на одном из IT Global Meetup я как раз делал доклад. Он получился не очень, в духе «Java против Scala». Я рассказывал как сделать код чище, добавил базовый пример и пытался его разобрать. Но я плохо подготовился, поэтому мне доклад не очень нравится. Кроме этого, когда я начал работать в eLama, работал над какими-то внутренними вещами, и пару раз выступал с тем, что раскапывал в Scala.
Еще у меня было одно выступление, но это было на московском Scala-митапе, человек на 50. Я рассказывал о реализации классов в Scala, как это сейчас выглядит. Меня пригласил Фомкин в 2016 году. Мне сказали, что доклад хороший, но я в это особо не верю. Кроме меня там рассказывали про использование Slick, а Фомкин рассказывал о своей библиотеке, которая называлась Vodka.
В Питере Scala-митапы начались в 2017. Со мной связался Никита Мельников, предложил сделать доклад, потому, что видел мое выступление в Москве. Я был рад поучаствовать, и с тех пор митапы периодически проводятся. Основная инициатива это Тинькофф. eLama" тоже в этом участвовала — проводили пару раз у себя.
Еще один Meetup был в DINS. Я участвовал и в организации, и выступил с докладом два раза. Самое непонятное и сложное для меня — поиск докладчиков. Что интересно, на Meetup ходят довольно много людей. На те митапы, которые проводились в Тинькофф и у нас, приходило 60-70 человек — это нормально. Но при этом кого-то убедить выступить с докладом уже сложно.
Мы много чего еще пропустили. Не рассказали о Новосибирске. Там тоже был движ, но как-то ни с кем не удалось организовать запись. Возможно, когда-то мне удастся поговорить с Алексеем Романчуком или с Павлом Павловым из Excelsior JET, который начинал еще раньше. Можно найти интервью с Павлом, где он совсем скромно обмолвился об этом, и не стало основной темой разговора.
Запись в PartialFunction.
В «Записках Программиста» — eax.me, который ведет Александр Алексеев, Scala начинает упоминаться с 2013 года. С Александром мы тоже не стали записываться, потому что он давно отошел от дел, но суммарный опыт с языком он зафиксировал в своем блоге.
Во время подготовки второй части Владимир Успенский (vuspenskiy) направил меня к Александру Подхалюзину, с которым мы записали огромное интервью. На следующий день я получил от Владимира сообщение, но теперь уже с его личной историей: Qiwi, Scala в Тинькофф, первые встречи, ссылки на старые блоги (отдельное спасибо за это), и функциональщина из 2008 от Rúnar, которая исполняется на Java, — это
Владимир Успенский: Coursera, Тинькофф и особенности найма для Scala
Владимир: В то время я работал в Qiwi и перерефакторил много кода на Java, но всё равно получалось много воды и бойлерплейта. Я мучался, но как-то смирился.Через какое-то время вышел на блоги Александра Темерева и Влада Патрышева. Влад был в первых рядах ещё по внедрению Java, как я понял. Прочитал у них о Scala, начал замечать упоминания странных тогда для меня конструкций вроде опций на Java. Эту опцию я даже пустил где-то в продакшн. Были и более экзотичные Lazy Error Handling in Java и Higher-Order Java Parallelism от Rúnar Bjarnason. Все это адски взрывало мозг и было интересно, как это все применить.
Когда изучал конкретные примеры, например, у Daniel Spiewak: Scala for Java Refugees, это было именно то, чего мне не хватало. Ушла вся вода и странные непоследовательности, вроде
`_` vs `*` vs `?` из Java-кода, и осталась суть.Это была Scala 2.7 и, мягко говоря, она не была стабильной. Многие проекты пробовали её для unit-тестов или Case Classes. Чтобы добавить Scala в Java-проект надо было настроить joint-компиляцию в Maven. Но я решил попробовать и добавил поддержку в один некритичный проект в Qiwi. Всё заработало — я был очень рад, но на том всё закончилось.
Работа в Тинькофф и внедрение Scala
Неожиданно меня позвали в Тинькофф руководить разработкой нового интернет-банка, который полностью разработали внутри компании. Сначала я разобрался с текущими задачами, но когда добрался до backend, понял, что пора внедрять Scala.
Как раз вышла Scala 2.9 с современным, на то время, синтаксисом. Модные параллельные коллекции отлично подходили, чтобы что-то быстро запускать параллельно, если не принципиальны детали. Да ещё и создатель Groovy James Strachan выдал: «I can honestly say if someone had shown me the Programming Scala book by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I’d probably have never created Groovy».
Другой фактор выбора Scala это то, что все люди, которые тогда работали над инструментами, языком, библиотеками или писали о Scala, были суперумными и энергичными. Поэтому была уверенность, что это правильный выбор для будущего.
Как раз во время работы в банке, я начал ездил на зарубежные конференции. Первые Scala Days в 2012 году, гиковский flatMap в Осло. В то время я познакомился с Женей Бурмако. Сейчас мы иногда прогуливаемся вдоль океана уже здесь, в Калифорнии.
Найм Scala-разработчиков
Постепенно написали интернет-банк. В 2012 году он стал лучшим в России по версии Global Finance. Для меня это подтверждение утверждения «Нормально делай, нормально будет», а не что-то экстраординарное.
Олег Тиньков продвигал тему банка, что было забавно. Возможно, это помогло нам нанимать хороших разработчиков — люди в команде были, но хотелось расширять. Сначала мы писали в вакансии «Java-программист, Scala — плюс». Но упоминание Java в вакансии для Scala-разработчиков отрезает людей, которые не хотят иметь ничего общего с Java. Поэтому мы изменили вакансию на «Старший разработчик Scala». Это позволило нанять пару ребят, с которыми я бы очень хотел ещё когда-нибудь поработать.
Группа на Facebook
Мне хотелось понять кто вообще в России и Москве тоже независимо заинтересовался Scala, и какие у сообщества мысли. Встреч или чатов не было, и появилась идея всех собрать. Сделал группу на Facebook, в которой мы спланировали несколько первых митапов. Какой же митап без группы на Meetup? Пошёл создавать, а группа уже есть — Роман Тимушев создал. Мы решили объединить силы, и еще добавили Мишу Аксарина.
Первую встречу собрали под предлогом Scala-курса про реактивное программирование на Coursera. Многие приглядывались, но пришло около 20 человек: познакомились, рассказали кто чем занимается и интересуется, пообсуждали упражнения с курса и договорились встретиться ещё.
Так и понеслась.
Роман Елизаров: 10 000 строк на Scala, перфекционизм и беспощадная компиляция
Роман Елизаров (elizarov) — руководитель группы JetBrains, участвовал в работе над корутинами, библиотеками в Kotlin.Примечание автора. Перед записью интервью, я подумал, что получится беда, если я буду брать их только у людей причастных к Scala. Сплошные «обожательства» или, что хуже — «ошибка выжившего». Поэтому я решил, что обязательно добавлю ложку дегтя.
С этим сложнее — людей с реальным опытом, которым почему-то не зашел язык, на порядок меньше, чем хейтеров с нулевым опытом в Scala. Но тут я вспомнил пост Романа Елизарова (elizarov) — руководителя группы JetBrains — в котором он между делом набросил на Scala, что вызвало множественные подгорания, в том числе и у меня. Несмотря на негатив, вряд ли Роман написал пост по каким-то слухам о языке. Должна быть причина, какой-то негативный опыт от использования — так и оказалось. Ниже интервью с ним как раз об этом, и немного обсуждений о дизайне и связи корутин со Scala CPS Plugin.
Случай в 2010
Роман Елизаров: Примерно с 2000 года я программировал на Java всякие энтерпайзы. Поэтому следил за JVM-языками, в том числе за Scala. Кажется, что первый раз я прочитал о языке примерно в 2005-2006 году.
Когда ты абстрактно читаешь, синтаксис, всё очень круто. Я помню, прочитал описание, поигрался, и мне всё очень понравилось. Многие вещи, которые в Java подробные и тяжелые для работы, в Scala сделаны удобно. Меня это все интересовало уже тогда не с точки зрения ФП, а с прагматической — как мы пишем код. Но, так как кодовая база на Java уже большая, куча текущих занятий, воспользоваться на практике не удалось, пока не произошла история в 2010 году.
В 2010 году наши партнеры из Штатов, из энтерпрайза, заскучали. Им захотелось новизны, и они написали новую подсистему целиком на Scala. У него был какой-то web-интерфейс, он делал что-то несложное. При этом это никакой не Play Framework — просто web-сервис принимал запросы от пользователей, вызывал Java API. Нормальный web-сайт для выполнения каких-то внутренних интерактивных функций. Партнеры его запилили, он успешно работал, всё хорошо.
В то время мы были их подрядчиками. Разработчики подсистемы наигрались и решили заниматься другими делами. Наши клиенты пришли к нам и говорят: «Ребята, возьмите эту штуку на поддержку? Она же все равно использует ваше API». Отлично, вот он — реальный способ попробовать со Scala. Так бы нам никто не разрешил программировать на Scala, потому что всё жестко, но так как уже есть проект — вот и повод. Это, собственно, первый продакшн-опыт со Scala.
Первое впечатление от Scala — это насколько код компактней, чем в Java. Scala позволяет сложные вещи записывать компактно. Подсистема занимала примерно 10 000 строчек кода, но на Java это заняло бы в два раза больше из-за классов. Синтаксис, все внутренние объекты для передачи данных, даже вся адаптация Java API — все компактно.
Первые и последние 10 000 строк на Scala
Когда разработчики ушли, они оставили код в разобранном виде — в том смысле, что просто код. Мы попробовали взять его на поддержку, но появилась проблема — компиляция.
Скомпилировать Scala-код это квест. Код компилируется только с конкретной версией Scala Compiler — с точностью до точка-версии, до патч-версии. Версия больше или меньше — уже не компилируется.
Это решило для меня в 2010 году судьбу Scala в энтерпрайзе, где миллионы строк кода. Страшно представить как жить, если ты меняешь минорную версию компилятора и ничего не собирается.
— Точно не вспомнишь, почему?
Роман Елизаров: Почему она разваливалась точно не вспомню, конечно. Что-то там постоянно менялось от версии к версии. Может, мы попали в неудачное время?
Но я продолжил следить за развитием Scala, несмотря на то, что только в энтерпрайзе так мы не внедрили. В итоге функционал перенесли в другие Java-приложения. На этом Scala в этой компании перестала существовать.
Эти 10 000 строчек были первыми и единственными. Код достаточно долго проработал в продакшн, но потом были разобран по другим сервисам и устранен.
Конкретно моей профессиональной деятельности этот опыт оставил неизгладимый след, в том смысле, что всё-таки нужна совместимость этого всего. Сейчас я занимаюсь Kotlin. Неудивительно, что мы просто нереальное количество времени и дополнительных сил тратим, чтобы обеспечить совместимость всего и вся. Порой дикое количество времени уходит не в функционал, а просто, чтобы всё было совместимо. В том числе, на это влияет мой прошлый опыт.
Еще постоянно вспоминаем Python. По поводу совместимости у нас две баги: Scala и Python. Когда заходит речь о совместимости, никто не хочет повторения перехода со 2 на 3 Python, и никто не хочет быть как Scala.
«Идеальный код»
— Часто хочется что-то переделывать так, чтобы было всё «шоколадно»?
Роман Елизаров: Я занимаюсь дизайном и мне постоянно хочется все переделать. Мне никогда не нравится то, что я сделал. Пока я подготавливаю нечто к релизу, то нахожу несколько вещей, которые хочется поменять. Как только я что-то зарелизил, уже вижу в нём недостатки: это не доделано, здесь надо переписать с нуля. Но это путь в никуда. Есть только два подхода: либо я буду улучшать код до бесконечности и никогда не доберусь до релиза, либо запущу в релиз и это станет Legacy. Нельзя зарелизить идеальный код.
Дальше я половину времени трачу на улучшение продукта, а вторую — на совместимость с тем, что уже зарелизил. Опыт помогает заранее «подстелить соломки». Я вижу, что скоро придётся переделать, и много времени в момент релиза трачу на подстраховку в ожидании будущих изменений. Конечно, делать что-то с нуля и не заботиться о совместимости намного проще. Но компромисс в том, что либо ты делаешь идеально, либо твой продукт используют. Одно исключает другое.
Дизайн в Kotlin
Роман Елизаров: Я непрерывно следил за Scala, потому что когда мы дизайним что-то в Kotlin, то изучаем, что есть в других языках, в том числе в Scala. Года два назад мы дизайнили Kotlin корутины. Основное «вдохновение» — это, конечно, C#. Всё началось с него и оттуда уже родилось вот это вот всё. Потом уже мы стали изучать Go.
Когда дизайн стал отклоняться от C# и появились «continuations», а потом и «delimited continuations», мы стали в очередной раз изучать другие языки. В Google я натыкаюсь на Scala — оказывается в нем уже были «delimited continuations».
— Это ты про Compiler Plugin?
Роман Елизаров: Да. При этом дизайн был фантастически похож на тот, что сейчас в Kotlin. Есть, конечно, синтаксическое отличие: в Kotlin мы пишем модификатор «suspend» в начале, а в Scala ты писал аннотацию csp на возвращаемое значение. Но какая разница где ставить модификатор: в типе возвращаемых значений или в начале?
Дизайн в Scala был очень похож на текущий в Kotlin. Я заинтересовался — как же так, раз такой клёвый дизайн, почему не полетел? Почему в современном Scala так никто не пишет? Мне показывали как там пишут в Play Framework — там нет никакого плагина.
Все пишут фьючи, а у нас была замечательная идея фьючи изжить, потому что этот дизайн удобней. Так и получилось в Kotlin: фьючи не нужны, есть корутины. В Scala же отказались от «continuations» и не полетело. Почему?
Бессмысленность и беспощадность компиляции
В процессе поиска я нашёл самый оригинальный анонс. В тот год в Scala появились «delimited continuations». В Scala тогда всё делалось то же самое, что сейчас в Kotlin.
Анонс в этом смысле показателен. В нем говорилось: «Мы сделали „delimited continuations“, смотрите, мы можем писать такие же клевые штуки, как в Lisp». Для примера взяли пример на Lisp из работ 80-90-х годов, и переписали на Scala: списочки состыкованы, тут «shift/reset». В Lisp и подобных языках есть конструкция для delimited continuations, которая обозначена как «shift/reset». Название взрывает мозг — никто не знает, что такое «shift/reset». Ни тот, кто изучал Lisp, ни тот, кто никогда с ним не встречался.
Главное в этом анонсе это комментарии типа такого: «This makes about zero sense. I just spent some time on Wikipedia as well as a few other places to try to understand this. From my perspective, these are convoluted ways of adding numbers and I have no idea what is being gained or accomplished». Они объясняют всю суть поста.
Поэтому такой анонс важной фичи абсолютно бесполезен. Если его прочитает человек, который пишет код для приложения, то он не получит ответ на вопрос: «Зачем это мне вообще нужно? Какую проблему это решит?» Такой вопрос автором и не ставился. Поэтому фича и не полетела — не потому, что плохая, а потому что задачи полететь не было.
— Ее неправильно подали?
Роман Елизаров: Да, неправильно подали. Её как бы анонсировали, но не объяснили зачем она нужна и какие проблемы может решать. Но дело не «правильности» или красоте. Мы в Kotlin, кстати, тоже не умеем писать красивые блогпосты, но для правильной подачи написать красивый анонс недостаточно. Правильная подача — это не столько объяснение зачем, а еще объяснение с точки зрения API.
Я читаю код, а там используются методы «shift/reset». Почему в 70-х это назвали «shift/reset»? Пытался найти автора названия из прошлого, но не смог. Просто кому-то пришло в голову это название. Современному программисту вообще ни о чём эти слова не говорят. Они ничего не значат.
Я занимаюсь корутинами столько, что кажется, должен всё про них знать, потому что прочитал кучу научных работ. Но когда я вижу код, который использует «shift/reset», каждый раз напрягаюсь, чтобы понять, что там происходит и зачем вообще это надо. Это кажется какой-то черной магией, при этом бессмысленной.
Алексей Фомкин: скончавшийся Flash, «Восход» и первые московские митапы
Алексей Фомкин (yelbota) — программист, спикер, подкастер, Open Source контрибьютор, Scala энтузиаст.Примечание автора. После отхода от дел Тимушева и Успенского, весь движ в Москве держался на Алексее Фомкине. Помимо этого, он запустил подкаст Scalalaz, и заглядывал в другие подкасты: DevZen, Разбор Полетов, Remote Talk. Пропустить его в этом цикле статей, было бы большой ошибкой.
От своего бизнеса до Scala-разработчика
Алексей Фомкин: У меня, наверное, все будет очень скучно — ничего интересного и не было. У меня есть моя личная история. Она интересна мне, но для читателей, возможно, будет скучна.
Вообще, я занимался Action-Script, а позже у меня был собственный небольшой бизнес. Когда бизнес закрылся, я остался без всего, потому что Flash к тому времени сдох. Соответственно, ничего другого у меня в резюме не было. Я искал работу, был эмоционально подавлен, потому что все потерял.
Я не видел себя не то что техническим директором, даже тимлидом. После неудачи со своей компанией, амбиций было только на рядового программиста. Пытался устроиться JS-разработчиком в Яндекс. Но мне отказали, потому что я плохо его знаю — что было правдой, конечно.
Тогда я вспомнил о Scala. Я ее пробовал многократно, начиная с 2010-го года, — язык мне нравится. Пробовал я потому, что в конторе, в которой я работал в 2010-ом году, был OСaml. Мне хотелось, как OCaml, только чтобы был JVM — она мне нравилась. На стороне я написал несколько проектов на Scala, а в 2014 году уже начал применять в своей компании.
Возникла идея двигаться в сторону Scala: много предложений, много проектов, а разработчиков дефицит. Тогда я напрягся и за несколько месяцев подтянул и актуализировал все свои знания. Мне повезло — я устроился техническим директором и набрал Scala-команду.
«Восход», Skype-чат и организация первых митапов
Одновременно с этим я подумал, что надо пытаться мутить какие-то штуки, пока тема не сильно развита в России. Поговорил с Успенским, Тимушевым и Аксариным. Оказалось, что Аксарин остался один — Успенский был «на чемоданах». Я поговорил, устраиваете в Meetup или не устраиваете. «Да, устраиваем». И это был последний митап, который устраивала старая команда. Это было в каком-то госучреждении, НИИ «Восход» Я сходил туда, рассказал про Scala JS что ли, а потом вообще эта тема заглохла. Раз все так плохо и нет никакой активности, я решил все организовывать сам — начал активничать в Skype-чате, в котором тусовались скалисты.
— Сколько там было людей?
Алексей Фомкин: Не помню — их и в современном чатике немного. Основной костяк — это человек 10-50, которые постоянно разговаривают. Остальные приходят, уходят, спрашивают вопросы — также, как сейчас.
Это был 2015 год: Skype-чат, Scala.js, первые митапы вместе с компанией, в которой работал. Мы мощно использовали Scala, а я продвигал Scala.js. Ходил ко всяким JS-разработчикам, в подкасты, рассказывал о Scala.js и звал на Meetup.
В 2016 году мы стартанули подкаст. Я кинул клич и откликнулось много народу. В принципе, практически все до сих пор и остались, кроме Тараненко. Потом подключились Григорий Помадчин и Оля Махасоева.
— Кто-нибудь помогал с митапами? Я расстроился, когда ты уехал — будто все заглохло.
Алексей Фомкин: Внутри компании помогал Макс Павлов. Он умеет программировать, но больше менеджер. Я занимался докладами, Scala-частью, а Макс помогал с организацией: помещение, оборудование, регистрация.
Все спонсировалось Data Monsters, она же Flexis, она же Adi Sait — в разные времена разные названия. Я там как раз тогда работал. Еще один Meetup я провел в 2018 году. Он был один.
Николай Татаринов: Play Framework, первый курс и питерская ветка митапов
Николай Татаринов — разработчик в SoundCloud, бывший организатор SPb Scala Meetup.
Примечание автора. Теперь о питерской ветке митапов. Хотя они и стартанули не так давно, прошло уже 9 мероприятий. По качеству проведения они сильно подняли планку: свой канал на YouTube, прямые трансляции.
Один из организаторов — Николай Татаринов. Хотя сейчас он уже отошел от дел из-за переезда, но я пришел к нему со стандартными вопросами. Николай рассказал про заход в язык, движуху, немного затронул статус Play Framework до релиза 2.0 и судьбу Actor Messaging.
Play Framework
Николай Татаринов: На моей первой работе в 2012-ом году мы использовали еще первый Play Framework. Он был сделан по подобию Rails. Было интересно, потому что у нас было приложение, в котором было легко проводить изменения. Но оно было в состоянии прототипа — не эволюционировало в какую-то продакшн-систему. Там было все намешано — так и развивалось.
В первом Play Framework была Java и Groovy. Все было самописное, даже система сборки какая-то урезанная — просто какие-то Python-скрипты. Это не библиотека, которую надо подключать в Maven или Sbt. Это было полностью рабочее решение — берешь Play Framework и запускаешь Play Framework.
По ощущения, в первом Play Framework гораздо меньше возможностей расширяемости, чем во втором. Во втором есть отдельная система сборки — свободно выбираешь, как именно делать и все работает «из коробки».
Я узнал про второй Play Framework, и, что там есть Scala, но, что за язык — не имел понятия. Решил попробовать написать что-нибудь на втором Play — было очень неудобно. Я не понимал, что происходит — все было иначе, чем в первом. Нужно было писать гораздо больше бойлерплейта, все явно прописывать. В первом Play Framework те же самые роуты решались соглашением на счет того, где лежат контроллеры. Во втором все приходилось писать руками, и собирать тоже руками.
C первого раза новая версия Play Framework мне не понравилась. Мне показалось, что это как-то странно, и сама Scala не очень понятный язык. Все это на время отложил.
В 2013 была конференция в Пензе — «Secon», на которой выступал Лев Валкин. Он приезжал в Пензу, рассказывал о ФП — было интересно, что-то новое. Я подумал, что надо посмотреть в сторону Scala. На какое-то время забыл, а потом наткнулся на курсы по Scala на Coursera.
Первый курс на Coursera
Первый курс назывался «Функциональное программирование в Scala». Я решил его пройти, посмотреть, что это такое. На курсе было базовое понимание, но мозг порядочно взрывался — перестраивался, когда думал о программах, как все строится. Прошел курс, узнал базовые вещи, но на первой работе затащить Scala не получилось.
Зато я стал активно использовать Guava во времена 7-ой Java. В нашем проекте появились всякие трансформации: когда тащишь данные и начинаешь их трансформировать. Это было странно. Наверное, после того, как я ушел, это все выпилили.
Первая работа со Scala
Николай Татаринов: Я прошел курс в 2014 году. В это время я начал искать работу, и подумал, что было бы неплохо найти что-то на Scala. В итоге в 2015 в Питере устроился в стартап, который разрабатывал платформы для месседжинга Actor. Сейчас его уже нет, но зато есть Dialog, который используется в Сбербанке.
— Dialog на базе Actor?
Николай Татаринов: Да. Часть команды, которая работала над Actor, стала разрабатывать Dialog. Я не знаю, насколько там много Actor. Возможно, все уже переписано, но связь есть.
Итак, я устроился в Actor, переехал в Питер и начал работать. До этого опыта в продакшн со Scala вообще не было — было непросто держать вот это вот все. Первый курс дает понимание о ФП, о синтаксисе Scala, знание каких-то паттернов, но как композировать и обрабатывать ошибки и все такое — ноль.
В работе с продакшн-кодом в Scala одна из первых задач, которая возникает — как это все скомпозировать так, чтобы имело смысл. При этом важно не кинуть где-нибудь посередине исключение, даже если хочется. Все это было самое сложное, но интересное, в начале.
Задачи, которые мне давали, я дико затягивал. Я думал, что все нужно делать по функциональному, не как в Java и все такое. Со временем многое меняется — постепенно понял, где и что лучше использовать. В итоге, где-то через полгода, стал чувствовать себя комфортно с языком и всем инструментарием. Примерно так я вкатился в Scala.
Следующие работы, которые я находил, тоже были связаны со Scala. Сейчас работаю в SoundCloud. Здесь тоже большая часть сервисов на Scala.
Выступления
Николай Татаринов: По поводу сообщества. IT Global Meetup — слет IT-сообществ, проходит 2-3 раз в год. Разные сообщества там выступают с разными докладами. Одно из них — FProg Spb. Они больше в функциональщину: там есть кложуристы, скалисты, хаскелисты, да и более специфические вещи, типа Coq.
Я был далек от всего этого. Одно время ходил к ним, но чаще это либо о Clojure, где все относительно понятно, без усложнений — базовые вещи, либо они доказывают теоремы через Coq, жесть, хардкор и я ничего не понимаю. Для меня серединки не было.
Я никого не знал из тех, кто занимался Scala. Но на одном из IT Global Meetup я как раз делал доклад. Он получился не очень, в духе «Java против Scala». Я рассказывал как сделать код чище, добавил базовый пример и пытался его разобрать. Но я плохо подготовился, поэтому мне доклад не очень нравится. Кроме этого, когда я начал работать в eLama, работал над какими-то внутренними вещами, и пару раз выступал с тем, что раскапывал в Scala.
Еще у меня было одно выступление, но это было на московском Scala-митапе, человек на 50. Я рассказывал о реализации классов в Scala, как это сейчас выглядит. Меня пригласил Фомкин в 2016 году. Мне сказали, что доклад хороший, но я в это особо не верю. Кроме меня там рассказывали про использование Slick, а Фомкин рассказывал о своей библиотеке, которая называлась Vodka.
Начало митапов в Питере
В Питере Scala-митапы начались в 2017. Со мной связался Никита Мельников, предложил сделать доклад, потому, что видел мое выступление в Москве. Я был рад поучаствовать, и с тех пор митапы периодически проводятся. Основная инициатива это Тинькофф. eLama" тоже в этом участвовала — проводили пару раз у себя.
Еще один Meetup был в DINS. Я участвовал и в организации, и выступил с докладом два раза. Самое непонятное и сложное для меня — поиск докладчиков. Что интересно, на Meetup ходят довольно много людей. На те митапы, которые проводились в Тинькофф и у нас, приходило 60-70 человек — это нормально. Но при этом кого-то убедить выступить с докладом уже сложно.
Вот и все
Мы много чего еще пропустили. Не рассказали о Новосибирске. Там тоже был движ, но как-то ни с кем не удалось организовать запись. Возможно, когда-то мне удастся поговорить с Алексеем Романчуком или с Павлом Павловым из Excelsior JET, который начинал еще раньше. Можно найти интервью с Павлом, где он совсем скромно обмолвился об этом, и не стало основной темой разговора.
Запись в PartialFunction.
В «Записках Программиста» — eax.me, который ведет Александр Алексеев, Scala начинает упоминаться с 2013 года. С Александром мы тоже не стали записываться, потому что он давно отошел от дел, но суммарный опыт с языком он зафиксировал в своем блоге.
Эта серия приурочена ScalaConf 2019 — к первой (15 лет жизни языка) настоящей конференции в России. Конференция полностью посвящена Scala и пройдет 26 ноября. Проповедник Джон, «Профессора Hаskell», Святой Грааль и много функциональщины — только хардкор, только Scala. Ждем вас на ScalaConf 2019. Подробная программа в нашем специальном анонсе.