Как Мы Перешли Со Scala На Go

Перевод статьи Технический директор CrowdStrike о том, как и почему они перешли со Scala на Go, когда компания выросла с 5 до 200+ человек.

Scala уже давно является частью стека CrowdStrike нашей компании, фактически даже основным языком.

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

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

Я пришел из компании Gravity, которая довольно активно использовала Scala. Это был основной язык в компании.

Я привык к нему, он мне понравился, я увидел его мощь и был уверен, что смогу предотвратить некоторые сложности, которые я видел в Scala по мере роста CrowdStrike. Мы выполняли высоконагруженную аналитику и пакетные задачи на Hadoop, а наш главный архитектор (привет, Бисселл!) использовал лямбда-архитектуру задолго до того, как она стала модной.

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

По сути, он остается дополнением к Го там, где он неэффективен.

Scala — важная часть нашего стека машинного обучения и аналитики.

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

Но он стал скорее специализированным инструментом, а не языком по умолчанию.

Я расскажу вам эту историю через призму технического директора.

Призма, в которой вам нужно развивать компанию с первых дней ее существования и от 5 разработчиков до 200+ программистов по мере роста бизнеса.

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

Я помню, как впервые увидел потенциальные проблемы масштабируемости Scala в Gravity еще в 2009/2010 году.

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

Несколько человек начали исследовать проблему, и нам удалось изолировать код, вызывающий проблему.

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

Это оператор космического корабля <|*|> .

Кто-то сказал вслух: «Что это, черт возьмиЭ» Там творилась какая-то неявная магия, совсем не очевидная.

Cmd-B для перехода к методу не помог, поскольку наша IDE не смогла найти символ (с тех пор IDE улучшились).

Быстрый поиск в Google для "<|*|> » тоже не дало никаких результатов.

Нас загнали в тупик.

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

Мы обнаружили недавно добавленную новую библиотеку под названием scalaz, и за несколько часов нашли этот мистический символ, разобрались, что он делает, выкатили исправление, и все остались довольны.

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

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

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

Обычно разработчики Scala делятся на два лагеря — лагерь «Это лучшая версия Java» и лагерь «Я (сердце) аппликативные функторы».

Те, кто принадлежит к лагерю «Это лучшая Java», любят краткость Scala и стандартные функции, которые делают Scala в целом лучше, чем Java. В их коде есть функциональное программирование, но без фанатизма.

В лагере «Я (сердечные) аппликативные функторы» функциональный мир расцветает во всей красе, и люди начинают углублять свои знания, привнося свой уже функциональный опыт из таких языков, как Haskell. По своему опыту я разделил эти два лагеря, и в обоих были отличные программисты, поэтому я не мог сказать, что один лагерь хуже или лучше другого.

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

   

 import scalaz._
 import scalaz.std.list._
 import scalaz.syntax.monad._
 import scalaz.syntax.monoid._
 import scalaz.syntax.traverse.{ToFunctorOps => _, _}
 
 class Foo[F[+_] : Monad, A, B](val execute: Foo.Request[A] => F[B], val joins: Foo.Request[A] => B => List[Foo.Request[A]])(implicit J: Foo.Join[A, B]) {
 
 def bar: Foo[({type l[+a]=WriterT[F, Log[A, B], a]})#l, A, B] = {
 type TraceW[FF[+_], +AA] = WriterT[FF, Log[A, B], AA]
 def execute(request: Request[A]): WriterT[F, Log[A, B], B] =
 self.execute(request).

liftM[TraceW] :++>> (repr => List(request -> request.response(repr, self.joins(request)(repr))))
 ----- REDACTED -------

Некоторые из вас посмотрят и скажут, что это великолепно, но некоторые из вас скажут: «Какого чертаЭ» Подобных строк кода были тысячи.
Это были те случаи, когда вся команда могла работать с кодом, но половина из них вообще не хотела с этим кодом иметь дело.
Разработчик, написавший это, — выдающийся программист, но то, что его код разделял всю команду, было проблемой.
По мере роста команды этот раскол становился все более очевидным, когда нужно было нанять новых людей.
В Scala есть много мелких, но неприятных проблем, таких как настройка среды разработки, проблемы с SBT, проблемы с настройкой IDE, медленное время сборки, большие старые JAR-файлы.
И вдобавок к этому большая доза новых концепций ScalaZ. , что в совокупности привело к увеличению времени входа в проекты и снижению производительности разработчиков.
Теперь нам приходилось отвлекать разработчиков на предварительное обучение новичков, что тоже замедляло процессы.
СБТ тоже была отдельной проблемой.
Всегда оказывается, что есть только один человек, который действительно понимает, чем, черт возьми, занимается SBT, и может разобраться в проблемах остальных.
И это не было чем-то уникальным для компаний, в которых я работал.
Twitter пережил те же трудности роста, как и другие компании, с которыми мне доводилось общаться на конференциях, и другие люди, которых я знал, работая со Scala. На самом деле это известная тема.
Хотя вы можете быть невероятно продуктивными с Scala в небольших командах, создание команды численностью более 50 человек становится непростой задачей.
И в этот момент на сцену выходит Го.
Одна из причин использования Go заключалась в том, чтобы позволить программистам работать более продуктивно, сократить количество способов сделать одно и то же и иметь очень специфический взгляд на мир с точки зрения компилятора.
Некоторое время я сопротивлялся Go внутри себя.
Мне не хотелось еще больше дробить команду и заставлять людей учить другой язык, поскольку в стеке у нас уже было несколько технологий.
У нас было внутреннее правило даже не рассматривать технологию, пока в 3 часа ночи не найдётся хотя бы 3 человека, готовых поддержать проблему с этой технологией на производстве.
После того, как меня достаточно тыкали (спасибо, Шон Берри ), и необходимое количество 3-х человек было набрано, я углубился в изучение Go и увидел, что он решает для нас массу проблем со Scala на организационном уровне.
Быстрое время компиляции, небольшие двоичные файлы, один файл, встроенное форматирование, отличные готовые инструменты, встроенные тесты, профилировщики, отличная модель для конкурентного программирования? Ух ты, продал! Мы успешно создали тестовый проект на Go, затем еще один, потом еще, увеличили число разработчиков, взявшихся за Go, и вскоре Go стал предпочтительным языком, который выбрали люди.
Вы можете перейти к любому проекту Go и сразу понять, что он делает. Скучаю ли я по неизменяемым типам и некоторым замечательным функциям Scala? Конечно да, но я думаю, что удобство сопровождения кода здесь слишком важно, чтобы оставлять Go вне игры.
Еще одним преимуществом Go было то, что он расширил круг разработчиков, которых мы могли нанять.
Мы могли нанять практически любого программиста с разным опытом и знать, что он освоит Go за пару недель.
В Scala всегда необходимо сначала изучить JVM, мир Java-контейнеров, темную магию настройки JVM и так далее.
Новые разработчики теперь приходили в игру за недели, а не за месяцы.
Сейчас большинство наших проектов написаны на Go, и последний неохотный Go-программист буквально на днях написал свой первый проект на Go и сказал мне следующее: «Ух ты, я однажды прочитал код библиотеки и знал, что она делает. Я прочитал код Scala-версии библиотеки 4 раза и до сих пор не до конца понимаю, как она работает. Теперь я понимаю, почему вы так увлечены Go».
Это был один из наших старших разработчиков, который ранее работал в одной из крупнейших веб-компаний в мире.
Весь этот процесс перехода на Go был полностью инициирован нашими разработчиками и был выбор команды.
В настоящее время с помощью наших сервисов Golang мы обрабатываем сотни тысяч сообщений в секунду и терабайты данных в день.
В этой статье я не хочу критиковать Scala или ScalaZ (я люблю ValidationNel!), но я хочу дать больше контекста из реального мира производства с более чем 7-летним опытом работы в двух компаниях.
Я до сих пор использую Scala и люблю экспериментировать со Scalding. Некоторые из наших следующих амбициозных проектов, вероятно, будут реализованы на Scala, но я больше не считаю, что делать его нашим основным языком — правильный выбор, особенно по мере роста команды.
С тех пор Go стал моим языком по умолчанию.
Go слишком упрощает разработку.

Теги: #Go #scala #программирование #Go