СОБЫТИЯ · 19 июля 2017, 10:49 · DianaVasileva - Author в dev.by
Команда Juno: за последние годы разработчики распробовали язык программирования Go

Язык Go быстро завоёвывает доверие инженеров — за прошедший год он поднялся с 54 на 13 место в индексе TIOBE (в настоящий момент 10-е место) и получил звание «язык года». Чем же он так привлекателен и какие возможности в нём есть? Об этом можно будет узнать 21 июля в SPACE на первом в Центральной и Восточной Европе событии, полностью посвящённом языку Go — GoWayFest. dev.by побывал в гостях у команды Juno, поддержавшей мероприятие, и поговорил о будущем языка, его возможностях и использовании в бэкенде каршерингового продукта.

Почему в бэкенде Juno — Go?

По словам архитектора Juno Михаила Гузелевича, выбирая технологический стек и архитектуру бэкенда, основатели компании учитывали свой богатый предыдущий опыт. Основное, чего они хотели избежать в новом проекте, — монолитная архитектура, С++ или языки на базе виртуальных машин. При большой нагрузке использование последних часто выливается в «тонкий тюнинг внутренностей виртуальной машины», а не в программирование. 

Учитывая эти вводные данные, выбор языка для фаундеров значительно сократился. «Go хоть и был молодым языком, но уже широко использовался инженерами, да и в интернете не было дефицита информации. К тому же у этого языка есть достаточно сильные преимущества для построения микросервисной архитектуры и размещения готового продукта в облаке. Основатели не боялись использовать новые языки и технологии, и это помогло нам найти заинтересованных людей», — говорит Михаил Гузелевич.

Бекенд-специалист уверен, что Go хорош для высоконагруженных систем, какой является Juno, поскольку в нём большой выбор низкоуровневых возможностей и хорошая утилизация ресурсов.

«Несколько лет назад, когда разговор заходил про Go, для ответа на многие вопросы нужно было лезть в потроха самого языка или в немногочисленные проекты, каждый из которых следовал своему чувству прекрасного. Теперь на Github можно как образец читать код известных проектов, тонкие моменты рассматриваются в многочисленных технических блогах. У нас тоже есть свои опенсорс-библиотеки, но в связи со спецификой бизнеса в общий доступ выкладывается далеко не всё. Каршеринг и логистика — очень конкурентная отрасль, но мы с удовольствием делимся решениями общего назначения. Например, библиотекой для работы с платёжными системами», — говорит собеседник.

Возросший интерес к новому языку Google он объясняет тем, что разработчики за последние годы «распробовали» его, и в интернете накопилась «критическая масса кода». Если раньше даже самые простые вещи Go-разработчику нужно было реализовывать самому, то теперь в этом нет необходимости. А это существенный бонус для захвата рынка. К тому же многие крупные игроки — Docker, Avito, Uber — сделали выбор в пользу этого языка.

Go-код Juno: нетипичное использование и собственный фреймворк

По словам Михаила Гузелевича, Juno нетипичным образом использует Go.

Обычная область применения этого языка — это консольные утилиты, сервера, работающие с потоком сетевого трафика или быстро раздающие контент. А команда Juno «замахнулась» на создание целого продукта. Найти подходящий фреймворк оказалось невозможно, поэтому все «велосипеды» — собственные — разработчики собирали и переделывали их по несколько раз.  

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

При этом Go не единственный язык, используемый в Juno: на фронтенде — JavaScript, автоматизация тестирования бэкенда выполняется на Python. На нём же разрабатываются и все части, связанные с Data science, аналитикой, «биг-датой» и машинным обучением. Для остального бэкенда — эти системы являются своего рода «чёрными ящиками», предоставляющими API. Что касается мобильной разработки, то для Android — это Kotlin, а для IOS — Swift.

«В целом наше понимание микросервисной архитектуры близкое к классическому: никакого обмена через базы данных, всё общение — через API. Но есть и особенности. Например, у нас своеобразное понимание gateway. Он у нас максимально Simple и Stupid, ничего не знает о бизнес-логике, за исключением знания о пользователях, его правах и протоколах взаимодействия. Мы широко используем очереди сообщений для коммуникации между микросервисами. А сами микросервисы оборачиваем в Docker-контейнеры и деплоим их на Amazon», — поясняет архитектор Juno.

Михаил считает, что у «детища» Google хорошее будущее. «Целиком заменить другие языки он вряд ли сможет, но вот создать и занять свою нишу — вполне. Он может потеснить VM-based языки в тех местах, где нужен лучший перформанс. Но, например, некоторые ниши функциональных языков (документооборот, финансовая аналитика, налоговая отчётность) ему в ближайшее время не занять», — говорит собеседник.

«Контрибьютить в развитие языка — задача каждого из нас»

По словам представителя Juno Яны Лашкевич, популярность Go растёт семимильными шагами уже несколько лет. Многие компании контрибьютят в его развитие, например, недавно JetBrains выпустила среду разработки для языка Go. На просторах СНГ среди русскоязычного контента появляются такие проекты, как подкасты от GolangShow, Slack-канал Go-сообщества. Но несмотря на все эти шаги, мероприятий по Go очень мало. 

«На конференции JavaDay доклады по Go вызвали резонанс как в твиттере, так и среди участников, которые пришли послушать про Java, а в итоге интересовались Go. Поэтому мы решили, что есть смысл организовать отдельную конференцию по Go, — рассказывает Яна. — Инженеры Juno выступили в качестве программного комитета: помогли составить хорошую программу конференции и пригласили докладчиков из разных городов».      

По её словам, через несколько лет событий по Go станет значительно больше. Уже в этом году мероприятие «1.8 Release Party» прошло одновременно в нескольких сотнях городов мира. «Мы гордимся тем, что первое событие такого размаха в Центральной и Восточной Европе проходит именно в Минске. Контрибьютить в развитие языка — задача не отдельной компании, а каждого из нас», — говорит Лашкевич.

На вопрос «зачем Juno поддержка таких мероприятий?» она отвечает: «Мы придерживаемся позиции: чем бы мы ни занимались, нужно облагораживать среду, в которой находимся. Поскольку в нашей стране нет лазурного берега, которым можно привлечь иностранцев, нужно делать это в рамках нашей индустрии, с точки зрения инжиниринга: приглашать людей на такие ивенты и конференции».

Доклады на GoWayFest: kubernetes, garbage collection, scheduler и pipelines

Конференция будет состоять из нескольких тематик на русском и английском языках. Архитектор Gett Эйял Пост и сооснователь Juno Игорь Магазиник расскажут о бизнесе, почему крупные игроки выбирают Go, как они переходят на этот стек, какие преимущества в итоге получает и команда, и компания.

В хардкорных технических докладах спикеры расскажут о том, как устроен язык. Ребята из Англии, например, расскажут про работу «сборщика мусора» (garbage collection), спикеры из Avito — как они используют kubernetes в работе с сервисами в dev-среде, разработчик из Украины — о визуализация concurrency в Go, лидер российского Go-комьюнити — о профилировании. Ведущая подкаста GolangShow проведёт воркшоп, как писать на Go и доводить проект до продакшена.  

Стас Афанасьев из Juno расскажет про pipelines на базе стандартных интерфейсов io.Reader и io.Writer. Этот доклад будет интересен тем, кто уже познакомился с языком и тем, кто не до конца понимает концепцию io.Reader/io.Writer.   

Философский доклад Миши Кабищева из Juno будет посвящён дизайну кода.

«Про Go часто говорят, что он настолько прост, что даже не нужно заморачиваться, просто излагайте свой поток мыслей в виде кода, и он заработает. Но в большой команде это приводит к неудобствам и сложностям — код становится неподдерживаемый и нечитабельный. Поэтому я расскажу о том, как этого избежать и приведу примеры того, как на языке Go некоторые задачи лучше не решать в лоб», — сказал разработчик.     

«Конференция — место для сообщества инженеров, а не пиара решений отдельных компаний. Поэтому темы, о которых будут рассказывать спикеры, в том числе и наши ребята, не имеют отношения к Juno. Но мы всегда с радостью и гордостью делимся «своей кухней» — для этого приглашаем участников конференции на pre-party в наш офис накануне в четверг. В наших стенах можно будет пообщаться с архитекторами и инженерами бэкенда Juno, а также с нашими гостями из компании Gett и узнать поподробнее о том, что и как мы делаем», — приглашает на препати Яна Лашкевич.
 

Источник: dev.by
Новые комментарии

Обсуждение

Missing
+1

Про индекс тиобе ошибочка в статье. Го скакнул не на 13 строчку а на 10

https://www.tiobe.com/tiobe-index/

Missing
+6

> "Основное, чего они хотели избежать в новом проекте, — монолитная архитектура, С++ или языки на базе виртуальных машин. При большой нагрузке использование последних часто выливается в «тонкий тюнинг внутренностей виртуальной машины», а не в программирование. " Сильные аргументы.

- Чем ГО лучше любого другого языка для построения не монолитной системы? По сути монолит вначале это хорошо, потому что проще и быстрее.

- Причем тут С++? На нем если и пишут сетевые сервисы или бизнес логику то только очень специфическую.

- Т.е. если язык компилируемый то он автоматически за программиста решает множество вопросов производительности? Я думаю что как раз нет, языки без VM требуют намного большего внимания и понимания деталей их работы для достижения высокой производительности. И вообще в Go есть GC его не нужно настраивать?

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

- Какие именно преимущества?

> Основатели не боялись использовать новые языки и технологии, и это помогло нам найти заинтересованных людей.

- Привлечение энтузиастов за счет хайпа, по видимому важнейший смысл. А сейчас все кто программировал на Go какое-то время хотят новых фич/абстракций потому что приходится писать очень много лишнего кода.

> К тому же многие крупные игроки — Docker, Avito, Uber — сделали выбор в пользу этого языка.

- Теперь одна из причины выбора Go становятся понятна.

> Обычная область применения этого языка — это консольные утилиты, сервера, работающие с потоком сетевого трафика или быстро раздающие контент.

- Не просто так этот выбор ограничен.

> Код Juno представлен в виде микросервисной архитектуры, написан с помощью собственного Фреймворка, в котором введены абстракции протокольного и транспортного уровня, изолированы работы с логированием, СУБД, трейсингом.

- Готовое решения которых много(не на Go), позволило бы выпускать фичи продукта в n раз быстрее, не тратя время на разработку и подержу.

По итогу помимо того что Go, если по честному, не дает какого то серьезного роста производительности в сравнении скажем с языками на JVM, он дает невероятно много гемора при написании кода из-за своей невыразительности. Я уже молчу про тот факт что это молодой инструмент и писать велосипедов по видимому пришлось не мало, о чем в статье и говорилось.

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

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

B993ebcd20d5803b01e1810b59038c5b?1513030427
+3

> По итогу мое впечатление, выбор был сделан, но без абсолютного понимания что и зачем

Так там же написано "Основатели не боялись использовать новые языки и технологии, и это помогло нам найти заинтересованных людей"

Пойди найди заинтересованного хорошего jvm программиста - затребует яхту.

Missing

Если быть объективным, по словам разработчиков из Juno у них очень хорошие ЗП, сам разговаривал с несколькими так же слышал о этом из сторонних источников. Так что причина не в ЗП)

В целом, я считаю что их команда молодцы, но с тем что описано в статье не согласен.

Missing

Зато продукт на Go обычно требует в сотни раз меньше памяти по сравнению с JVM "продуктами"

Missing

Соглашусь тут действительно преимущество, пока объективно одно на всю статью.

Missing-male
+2

В сотни тысяч раз!

Missing-male

>> языки без VM требуют намного большего внимания и понимания деталей их работы для достижения высокой производительности.

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

6178553c3088be31671f8146ba91fd4b?1401052672
-2

> И вообще в Go есть GC его не нужно настраивать?

В Go **можно** настраивать GC. Только никому это нужно, потому как все и так хорошо работает.

> монолит вначале это хорошо, потому что проще и быстрее

Зачем монолит, если есть понимание, что микросервисы подойдут лучше?

> Какие именно преимущества?

Конкурентность из коробки, статическая компиляция.

> А сейчас все кто программировал на Go какое-то время хотят новых фич/абстракций

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

> Не просто так этот выбор ограничен.

У каждой технологии есть своя ниша. Что в этом плохого? Go свою нишу нашел и концентрируется на ней. Это скорее плюс, чем минус.

> невероятно много гемора при написании кода из-за своей невыразительности

Вам шашечки или ехать? Go - это молоток для забивания гвоздей. И с этой задачей он справляется на все 100%.

> что это молодой инструмент

Инструменту 8 лет отроду, и детсткими болезнями он уже переболел.

> На весь создаваемый языком и его экосистемой гемор закрываются глаза

Вы о чем вообще? Выглядит как заявление человека, который написал на Go максимум hello world.

> Возможность низкоуровневых оптимизации, слабое преимущество.

Go вообще не про это. В очередной раз подтверждает, что вы понятия не имеете, о чем говорите.

Missing-male
+14

Хипстеры решили заимплементить систему ... Че там на дворе 2016 так руби и нда уже не модны так так оооо Го ну все понеслась ... почему использовали потом придумаем

Missing-male
+2

"нужно облагораживать среду, в которой находимся", "место для сообщества инженеров, а не пиара решений отдельных компаний"

импонирует такой подход, молодцы ребята... и девчата...

Missing
+5

Меня как С++ разработчика очень интересует причина отказа от С++. Или хоршие С++ разработчики очень дорогие нынче и им просто С++ для их проекта не нужен? Тогда зачем упоминать С++....

Missing
+2

Скорей всего потому, что C++ это нишевый write-only язык с родовыми травмами, сомнительным прошлым, тусклым настоящим и совершенно без будущего.

(Я сейчас говорю про C++, а не про C/C99/C11)

Missing
+2

Совершенно без будущего? Сильное заявление. Аргументировать можете? Чем будете заменять С++ в тех сферах, где он применяется?

Missing
+1

Ну сколько раз повторять... Появление раста не отменяет того, что на С++ уже написана куча кода. Раст ещё слишком молод, чтобы говорить о нём как о конкуренте. Ближайший пример - D. И Вы так и не аргументировали, почему у С++ нет будущего. Из-за появления Rust ? :-)

Missing

Разрешите я вас иронично перефразирую:

"Ну сколько раз повторять... Появление джавы не отменяет того, что на COBOL уже написана куча кода. Java ещё слишком молода, чтобы говорить о ней как о конкуренте. Ближайший пример - ALGOL. И Вы так и не аргументировали, почему у COBOL нет будущего. Из-за появления Java ? :-)"

Missing
+1

Вы так и не ответили на вопрос. В чём ключевое преимущество Rust, что убьёт С++? И все в ближайшем будущем перейдут с С++ на Rust/Go/smth else?

Picture_415?1356409808

Безопасная работа с памятью по умолчанию, без «но», «если», самодисциплины и «а вот так не надо делать».

Missing

Ну не надо так всё радужно рисовать про Rust. Да, есть классный Borrow checker (привет GSL от Microsoft, который пытается им стать). Но не зря ходит столько разговоров, что в Rust много чего без #unsafe не написать.

Самодисциплина тоже вещь интересная. Если писать именно на современном С++, а не на Си с классами, то кол-во возможностей выстрела себе в ногу резко уменьшается.

Missing-male

Да даже С с классами + простые темплейты для контейнеров и врапперов уже достаточно чтобы писать хороший код.

Picture_415?1356409808

> Но не зря ходит столько разговоров, что в Rust много чего без #unsafe не написать.

Конкретнее.

Picture_415?1356409808
+1

> Самодисциплина тоже вещь интересная.

Самодисциплина вообще-то увеличивает когнитивную нагрузку. Рассмотрим в качестве примера требование парности malloc/free и new/delete. Необходимо знать, что они есть; знать как ими пользоваться _правильно_; знать, что именно произойдёт, если пользоваться ими неправильно; обмазываться valgrind, чтобы обнаруживать непарность помянутых эм, операций, потому что компилятор за этим не следит; и наконец — вишенка на тортике — никогда не пользоваться ими самому, потому что есть превосходящий их во всех отношениях RAII.

B993ebcd20d5803b01e1810b59038c5b?1513030427
+2

C++ как Windows - все пророчат конец, а он никак не умирает и не собирается.

Разрабатывать убийцу плюсов без легкого интеропа в тонны существующего С++ кода (не C, а именно С++) - заведома плохая идея.

В случае rust там и синтаксис местами ещё хуже - не понятно какие цели ставили создатели.

Picture_415?1356409808
+1

> C++ как Windows - все пророчат конец, а он никак не умирает и не собирается.

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

Missing-male
+4

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

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

Missing

Мощный это слишком широкое понятие. Так мощь которая позволяет писать высокопроизводительный код, для 90% бизнес логики на бэке не нужна. Но путать геморрой и мощь, а именно 100500 вариантов синтаксиса и способов выстрелить себе в ногу я не могу назвать чем-то хорошим.

Juno это не поисковая система Google или Yandex, зачем там С++?) Невнятное упоминание в статье я не буду учитывать уже.

Missing-male

У С++ нет 100500 вариантов синтаксиса, если уж на то пошло. Это всё таки не Perl.

Бизнес логика на нём пишется легко и просто, другой момент что надо иметь людей которые понимают что они делают и излишним усложнизмом не страдают, каких мало.

C978c760e1352ba73a20562a993235f2?1427577696
m.guzelevich
– Solutions Architect в Juno Lab

+2

фаундеры Juno - это товарищи до этого сделавшие такие сервисы как IMesh и Viber

Viber до определенного уровня (несколько миллионов пользователей) был монолитом написанным на C++

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

Missing
+2

Я не спорю, что у товарищей опыт большой.

Какие проблемы у Viber? Может проблема вовсе не в технологиях, а в руках и ошибке проектирования?

Missing

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

Missing

Мне интересно, сколько ушло времени на разработку фреймворка по сравнению с затратами на разработку самого продукта? Кстати - это opensource? У них есть публичный github?

C978c760e1352ba73a20562a993235f2?1427577696
m.guzelevich
– Solutions Architect в Juno Lab

+5

сегодня ровно 2 года от дня формирования команды бэкенда Juno

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

с тех пор туда инвестируется часть времени в фоновом режиме.

надо понимать что в фреймворке у нас большой пласт логики. абстракции над транспортами (http, nats, sqs), над базами, над логингом и мониторингом, обвязки для opentracing, валидаторы протокольного уровня, инициализация и реконфигурация микросервисов...

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

func (s Service) handler(in Request) (Response, error) в которых есть только бизнес логика

вся магия получения запроса, декодирования, валидации, проверки прав и т.д. - спрятана во фреймворке

на данный момент у нас

571095 LOC *.go всего

32258 LOC *.go - фреймворк

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

Missing-male

с интересом бы глянул.

удачи вам.

Missing-male
-1

ваше описание мне напомнило сервлеты с их фильтрами и JMS queue для диспатчинга

back to 1999 как гриться

Missing-male
-2

ты мыслишь жава статикой, тут речь скорее о динамике (которую к целюлитной заднице жавы обычно присобачивают "скочем" и "жувачкой", бо не дано)

Missing-male

тебе бы к сексологу - явно какие проблемы с женским полом.

Missing-male
-2

я уже с ним похоже разговариваю.

Missing-male
-1

спроси о какой динамике речь идет

Missing-male
-1

спрашиваю. и ?

6178553c3088be31671f8146ba91fd4b?1401052672

а для оркестрации вы что используете? для service discovery?

Missing-male

настоящий профи и на басике сделает все как надо. не важно на чем, важно как.

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

Missing-male

причем тут многообразие?

ресь скорее шла о зресолти языка и его экосистемы

Missing-male
-3

женятся не на зрелых, а на молодых и красивых.


Авторизуйтесь, чтобы оставлять комментарии

Использование материалов, размещенных на сайте, разрешается при условии прямой гиперссылки на dev.by. Ссылка должна быть размещена в подзаголовке или в первом абзаце публикации.
datahata — хостинг в Беларуси