СОБЫТИЯ · 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
Нашли в тексте ошибку — выделите её и нажмите Ctrl+Enter.

Обсуждение

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 это провидимому единственное что дизайном языка доступно разработчику для тюнинга.

1cdb342ea3d8a253e6a7bff7c1f3c68b?1529540451
+3

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

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

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

Missing

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

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

Missing

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

Missing

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

Missing-male
+2

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

Missing-male

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

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

6178553c3088be31671f8146ba91fd4b?1401052672
-1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Missing-male
+15

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

Missing-male
+2

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

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

Missing-male
+5

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

Missing
+2

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

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

Missing-male
+2

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

Missing-male
+1

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

Missing

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

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

Missing-male
+1

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

Picture_415?1356409808

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

Missing-male

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

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

Missing-male

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

Picture_415?1356409808

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

Конкретнее.

Picture_415?1356409808
+1

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

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

1cdb342ea3d8a253e6a7bff7c1f3c68b?1529540451
+3

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-male
+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 — хостинг в Беларуси