Golang: почему стоит выбрать это направление
Привет! Я — Тарас Серегин, Golang Engineering Leader в NIX.
Ежегодно на рынок выводят сотни IT-продуктов. Со временем у пользователей появляются новые запросы: изменить интерфейс, ускорить, оптимизировать приложение и так далее. Чтобы исправить баги и улучшить систему, разработчики ищут наиболее эффективное для клиента и наименее трудоемкое для себя решение.
В поиске удобных инструментов для работы в вебе инженеры Google в 2007 году задумались о более простой версии С и С++. Идею успешно реализовали в виде Golang — компилируемого многопоточного языка программирования. Планировалось, что он будет использоваться только под задачи Google (производное от Google language). Но вскоре инженеры поделились наработками со всем комьюнити.
В этой колонке я хочу рассказать о пользе применения Golang и чем направление привлекает бэкенд-разработчиков.
Популярные среди всех программистов приложения Docker и Kubernetes написаны на Go. Бэкенд мобильной версии Uber тоже. Кстати, девелоперы компании одними из первых придумали стандарт оформления и ведения кода Golang. Преуспел Go и в области блокчейна. Hyperledger Fabric — платформа для реализации блокчейн-проектов — также активно его использует. Этот список можно еще долго продолжать, но красноречивее выглядит мировая статистика.

По данным Stack Overflow, Golang входит в топ-3 языков, на котором программисты хотели бы писать код. Лидируют Python и JavaScript. В майском рейтинге PopularitY of Programming Language Golang на
Golang прост в изучении
Авторы Golang стремились сделать его не перегруженным. От этого язык выглядит более дружественным для новичков — порог входа в него низкий. Даже те, кто относительно недавно освоил Java, C, C++ или Python, быстро поймут и привыкнут к синтаксису Go. У него нет классов, поддержки наследования, исключений и аннотаций, что упрощает изменение кода. А с помощью утилиты GoDoc удобно документировать код.
Языку уже более десяти лет. Массивы опенсорс-кода и библиотек уже реализованы для Go, а результаты доступны на GitHub. Поэтому для многих задач можно найти готовое решение. Есть различные интеграции, а стандартная библиотека Go включает много полезных инструментов, в том числе веб-сервер и пакет тестирования, чего нет во многих языках «из коробки».
Эффективность Go — быстрый в компиляции и выполнении команд
Go компилируется гораздо быстрее, чем его аналоги С/С++. Одно из преимуществ — то, что он компилируется в бинарные файлы, и виртуальная машина не нужна (как в Java, например). Мы работаем с кроссплатформенным языком, то есть разрабатываем для любой платформы: Windows, Linux, MacOS. Просто компилируем и сразу запускаем.
Golang — один из самых быстрых и эффективных языков программирования. То, как он справляется с любой нагрузкой, не сравнимо с возможностями интерпретируемых языков вроде РНР, Node.js, Ruby и другими.
В Java или С# вы могли встретить такой термин, как многопоточность. Этот механизм призван задействовать все ресурсы компьютера, на котором запускается программа, чтобы решать трудоемкие задачи максимально эффективно и быстро. Например, перелопачивание больших объемов данных в нескольких потоках или рассылка огромного количества писем. Достигается это с помощью встроенных примитивов — горутин (threads). Создать такую процедуру в Go просто: добавляем ключевое слово go перед функцией.
Горутины очень легковесны. Если сравнивать с потоками Java, который потребляет много оперативной памяти, Go требуются буквально мегабайты. Он является достаточно щадящим для ресурсов системы. Среда выполнения Golang позволяет одновременно запускать тысячи горутин. При этом обслуживание инфраструктуры обойдется недорого. Переплачивать за хостинг не придется.
Легок в интеграции с текущим бэкендом
Полностью переписывать на Go действующий проект, на которым вы работаете, бизнесу может быть дорого и долго. Есть решение — интегрировать в текущий проект Go-бэкенд. Например, есть большое приложение на РНР. Мы можем дополнить его новыми сервисами на Go, и они будут отлично уживаться вместе. То же самое касается интеграции с Java, Python и другими бэкенд языками. Еще один плюс — на Go есть множество библиотек для интеграции: PostgreSQL, MySQL, RabbitMQ, Redis, GraphQL и другие.
Удобен для реализации микросервисной архитектуры
Сегодня в больших проектах очень популярен подход микросервисной архитектуры. Почему? Современные приложения содержат большое количество внешних сервисов: базы данных, кеши, поисковые движки, очереди сообщений и так далее. Разработчики смотрят в будущее и разбирают сложные проекты на более мелкие, закрывающие конкретные запросы бизнеса. Одни конечные продукты клиент может предоставлять определенным пользователям, другие — перепродавать сторонним компаниям. Go отлично подходит для последующих разработок. В нем используется асинхронный ввод/вывод, поэтому приложение может взаимодействовать с любым количеством сервисов, не блокируя веб-запросы. Протоколы gRPC позволяют микросервисам беспрепятственно общаться между собой.
Широкие возможности применения
Язык обладает встроенными возможностями (concurrency) многопоточности для обработки больших объемов данных. Например, для email-рассылок и нотификаций. Все, что касается в этом плане web-сервисов, легко реализовать на Go:
- системы потокового видео/аудио (чаты, стриминговые сервисы);
- высоконагруженные API;
- парсеры с большими объемами данных (XML, JSON, CSV);
- system apps (системные кроссплатформенные приложения, которые можно запускать на разных операционных системах);
- serverless web services (AWS Lambda, Google cloud functions for Firebase);
- notification services.
А где Golang лучше не применять? В открытых источниках вы можете найти библиотеки для реализации GUI-интерфейса на Go. Но, на мой взгляд, Desktop GUI приложения лучше на нем не писать. Все-таки язык создавался для решения задач в вебе. Такие же сомнительные «поделки» попадаются на GitHub в сферах геймдева и мобильной разработки.
Опыт нашей команды
Мы в NIX пишем на Golang с 2019 года. На данный момент в команде порядка 20 человек с экспертизой в этом языке. За два года мы успешно реализовали около десяти проектов на Go. Среди них — разработки в таких доменах, как fintech, real estate, высоконагруженный сервис по обработке видео, спортивные новости и другие.
Почему выбрали Go? Например, в проекте с онлайн-банкингом мы имели дело с сотнями тысяч пользовательских транзакций. В приложении для обработки видео — с сервисом, который должен был запускаться на Windows, так как был задействован вспомогательный софт и «железо» под эту платформу. В сервисе спортивных новостей — тысячи онлайн-юзеров, real time данные и высокие требования по скорости доставки контента на фронтенд. Во всех случаях нам пригодились ключевые возможности языка — concurrency и кроссплатформенность. Словом, везде, где мы использовали Go по назначению, имеем только положительный опыт.
Как и в любом бизнесе, в IT время на разработку — это деньги. Заказчики не хотят терять ни того ни другого. Поэтому команде важно оперативно решать технические таски. Современному бэкенд-разработчику нужно владеть как минимум одним языком, на котором быстро решаются бизнес-задачи. Golang отлично для этого подходит. При необходимости некоторые участки приложения вы сможете выносить в микросервисы на Go. При грамотном проектировании сочетание Golang с другими бэкенд-языками дает потрясающие результаты — конкурентный продукт и довольного клиента.
156 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів> Я — Тарас Серегин, Golang Engineering Leader в NIX.
То есть вы пишете сам язык? NIX это теперь часть гугла?
Или вы всё же занимаетесь какими-то конкретными продуктами?
> В поиске удобных инструментов для работы в вебе инженеры Google в 2007 году задумались о более простой версии С и С++. Идею успешно реализовали в виде Golang — компилируемого многопоточного языка программирования.
Названную идею не реализовали. «Реализовали» — а на самом деле реанимировали — одну древнюю разработку.
> Кстати, девелоперы компании одними из первых придумали стандарт оформления и ведения кода Golang.
«Кстати», эта реплика тут абсолютно не в тему. Зато весь постинг словно написан по инструкции «Текст, который продаёт».
> быстро поймут и привыкнут к синтаксису Go.
Ключевое — «к синтаксису». Потому что к функциональному убожеству привыкнуть таки сложно.
> Преуспел Go и в области блокчейна.
Хорошая антиреклама языку.
> У него нет классов, поддержки наследования, исключений и аннотаций, что упрощает изменение кода.
Х Х и в П
(и это 100% так по отзывам знакомых, которые пишут на нём)
> Мы работаем с кроссплатформенным языком, то есть разрабатываем для любой платформы: Windows, Linux, MacOS. Просто компилируем и сразу запускаем.
А потом перекомпилируем под каждое минимальное изменение среды запуска. Ну впрочем и так докер-обжуёкер, 20 релизов в продуктин за рабочий день, какая там разница...
> В Java или С# вы могли встретить такой термин, как многопоточность. Этот механизм призван задействовать все ресурсы компьютера, на котором запускается программа, чтобы решать трудоемкие задачи максимально эффективно и быстро.
Что, и весь диск она помогает задействовать? Как интересно... или вы под «ресурсами» ничего кроме CPU не слышали?
> Например, перелопачивание больших объемов данных в нескольких потоках или рассылка огромного количества писем.
А чего не «толстых потоков данных»? И зачем нам спамерские средства?
> Достигается это с помощью встроенных примитивов — горутин (threads). Создать такую процедуру в Go просто: добавляем ключевое слово go перед функцией.
Вообще-то не перед функцией. Впрочем, для такого откровенно рекламного текста — какое значение имеют технические детали?
> Горутины очень легковесны. Если сравнивать с потоками Java, который потребляет много оперативной памяти, Go требуются буквально мегабайты.
А не буквально?
> При этом обслуживание инфраструктуры обойдется недорого. Переплачивать за хостинг не придется.
Даёте гарантию? (вы ещё даже не попытались узнать, какой хостинг)
> system apps (системные кроссплатформенные приложения, которые можно запускать на разных операционных системах);
Что, даже перекомпиляции не требуется?
> А где Golang лучше не применять?
Я дам свой ответ на это: везде, кроме systemd :)
> Например, в проекте с онлайн-банкингом мы имели дело с сотнями тысяч пользовательских транзакций.
В год?
Серьёзно, ваш блин по «продающему» тексту откровенно пошёл комом.
Лучше вернитесь к тому, что лучше получается — блокчейнам там всяким...
Дещо зі злобою, але в цілому у мене такі самі питання до «кращої кращості Го».
+1. Cерйозно сприймати дану публікацію немає сенсу, це більше схоже на рекламу для найму. Напевно був проект/клієнт який потребував знання Go, клієнта «зачіпили», якомусь розробнику дали премію у вигляді поїздки на конференцію/ноутбука/крісла/подарунковий набір, а зараз щоб додати до команди розробника (зазвичай сейли в аутсорсі говорять клієнтам що в них 100500 сеньйорів) виникає гостра необхідність знайти хочаб когось. А так як Go — це не Java/C#/JavaScript/Python, і на ринку немає купи спеціалістів (місцевий ІТ бізнес — це не про знання основ, це про знання як конфігурувати фреймворки) то NIX намагається якось привернути увагу, пише статті/проводить якісь мітапи де можна когось знайти, хочаб з мінімальними знаннями.
Гарною рекламою Go будуть результати зарплатної статистики в цьому місяці, в зарплати українських розробників — зима 2021 Go займає перші місця.
Якщо для вас даний рейтинг орієнтир, тоді за вашою логікою ви б мали зараз активно мігрувати на Scala.
А я розглядав Scala раніше (до початку роботи з Go), Scala сподобалась, але зазвичай у вакансіях зі Scala хотіли ще й досвід з Java.
В2016-2017 роках ще вчив Swift та придивлявся до Go, але вакансії Swift server-side, що раніше, що зараз, рідкість.
Swift мені подобався більше ніж Go, але із-за відсутності Swift server-side вакансій та наявності цікавих проєктів на Go, вибрав все ж Go, задоволений вибором.
Якщо наступного року рейтинг очолить Prolog?
Prolog також вивчав, як і Haskell.
Було б цікаво таке побачити.
Rust ще вищі
Жаль, что у вас сложилось такое мнение.
Проблем с девами у нас нет. Касательно технологии — практически во всех случаях выбор стека стоит за нами, соотвественно мы применяем Go там, где он хорошо подходит под задачу и вызовы бизнеса.
Цель статьи — обратить внимание тех девов, которые еще не знакомы с Go, и в последствии толчек для расширения комьюнити. Заметьте, в статье не слова о вакансиях и 0 рекламы от компании.
Будемо вважати що це не ви і
проводиться винятково щоб
Чи за замовником?
да ладно, в переважній більшості вакансій тре Го — сінйори із мінімум 2 роки з Golang.
На Джині умовно 100 вакансій 25 розробників, які Го або трохи знають, або хочуть знати.
Ось і вся казачка.
Я бы не против поковырять Go (в перерывами между ковыряния Rust’а), но токсичное, неадекватное, нетолерантное и малообразованное комьюнити вокруг языка отбивает любое желание этим заниматься.
Українська спільнота чи світова?
У вас есть уникальная возможность стать первым во вселенной благоухающим высокообразованным адекватом в этом комьюнити. Воспользуйтесь этим шансом, и придите к успеху! Успеха достигают только те, кто увидели уникальный шанс и первыми им воспользовались!
а ти спецом тут же демонструєш те, про що казав Артем?
оке-е-ей
К сожалению, я пока что не достоин носить гордый статус представителя комьюнити Go, поскольку в разработке языка не участвую, с разработчиками лично ничего не обсуждал, на stackoverflow ни на какие вопросы не отвечал. У меня нет возможности проявить неадекватность, как у всех нормальных гоферов.
тоді чому ти відреагував на цей закидон
?
у тебе получається
Почему вдруг закидон? Вы всё не так поняли. Человек просто мечтает присоединиться к комьюнити Go, ну в общем как и я, но не знает как это лучше сделать. У него есть некоторые страхи и опасения, мы просто должны его поддержать, развеять все сомнения.
Эх, вашими устами да мёд бы пить.
с РНР перепутал что ли? :D
Нет, он DOU читает.
Пользуясь случаем, напоминаю Валялкину, чтобы отдал проигрыш.
а в чем суть спора была?
dou.ua/...rums/topic/20885/#1130689
От до речі правда — не стільки Го цікавий сам по собі, як його адепти які з ходу називають усі інші технології лайном навіть не знаючи про них достатньо.
а можно узнать в каком месте? а то я знаю про приколы с удалением известного раст фреймворка в ответ на критику автора за искользование unsafe кода во имя перформанса, но в гошке пока ни на какой негатив не натыкался.
Я не говорю, что в Rust комьюнити пони какают радугами. В истории про тот фреймворк не все так однозначно. Но это позитивный пример. Ситуация была сложная, комьюнити и контрибьютор нашли достойный выход из ситуации, комьюнити от этого только выиграло.
Ви це мали на увазі? dou.ua/...rums/topic/33949/#2169467
Спорный момент. Во-первых, Python лидирует весьма субъективно, поскольку является языком обучения программированию школьников в Штатах. А поскольку на stackoverflow школьники — это подавляющее большинство контингента, Python выбился в якобы «лидерство». Во-вторых, js является безальтернативным языком программирования на стороне фронтенда. Его не могут не выбрать фронтэдщики, поскольку у них нет других вариантов. Ну и в-третьих, в сухом остатке получаем, что Go является безусловным лидером симпатий программистов. Нужно на вещи смотреть взвешенно, и писать объективные факты, что Go занимает реально первое место.
Не совсем так. Вернее совсем не так. Во-первых, Go является языком с полной поддержкой ООП. Почему? Потому, что полностью соответствует 3 ключевым принципам ООП: инкапсуляция, полиморфизм и наследование. С инкапсуляцией всё очевидно, полиморфизм обеспечивается через утиную типизацию и интерфейсы. Ну а наследование реализовано через встраивание анонимных структур, методы которых наследуются. Во-вторых, классы в Go не нужны, поскольку реализована другая вышеописанная модель ООП. Ну и в-третьих, исключения в Go реализованы в виде механизма panic-recover.
Ну пожалуй только это здесь бесспорное утверждение.
=
=
=
бо в такому випадку виявиться, що всіх школярів і жсників хтось змушує голосувати на стековерлов, а за го голосують тільки «тру» програмісти,але це не так, бо у багатьох універах США використовують го — отже у нас буде заруба між школярами і студентами.
Конечно, за Go голосуют только «тру»-программисты, это вы верно заметили. Школьников обучать программированию по Go не станут, поскольку там нет лишних абстракций и усложнений, необходимых школьникам для проявления академичности. Go рассчитан исключительно на профессионалов, ориентированных прежде всего на результат. Поэтому, возможно Go будут преподавать в университетах, но только правда в самых лучших и продвинутых. Поэтому в итоге ведущий рейтинг Go всегда будет отражать количество профессионалов в отрасли, которое конечно же будет расти.
Валялкин, перелогинься, фразеология выдает)
Его уже клонируют. Надо же как-то программистов набрать...
Даже не надейся на коньяк от клонов.
Я ж от оригинала хочу получить свой выигрыш. Клоны то такое...
Як тільки він стане хоч трошки популярним — звісно стануть.
Наприклад там немає черги на яку накинули мьютекс і назвали це каналом.
А є якісь популярні мови,що розраховані на непрофесіоналів або професіоналів які не орієнтовані на результат?
Ні, го будуть викладати там, де потрібно максимально ванілізувати multithreading незалежно від того, чи буде це факультет CS MIT чи Жашківський педагогічний коледж.
Як і будь яка інша мова програмування, бо школяр якому не цікаво — зайде на стаковерфлоу 1 раз щоб скопіювати відповідь і опитування на 10 хвилин він проходити явно не буде
Не стане він популярним, так як він нішовий — мікросервіси на бекенді.
От там він і буде мати якийсь свій % поряд з конкурентами.
гагага, більше ніде нема мультитредінга, щоб аналізувати.
Ну, як на мене, це дуже позитивна риса, яка справджує більшість іншого убозтва...
Ось одна з основних проблем го — інфантили в комюніті:
Тайпскрипт?
«3 кити» не є ні необхідною, ні достатньою умовою.
Тайпскрипт всё равно компилируется в js, и по сути является синтаксическим сахаром к js. Перспективы к нативному исполнению на стороне браузера нет и не будет, это провальный проект, MS только пытается делать хорошую мину при плохой игре. Играют в гонку со стандартом с ES, это вообще признак эпик фейла.
Як це впливає відсутність альтернативи джаваскріпту? :)
Тем, что ts является производной от js, и полностью зависит от js. Разработчики ts не могут принять никакого самостоятельного решения без оглядки на стандарт ES. ts — это не альтернатива, это фикция альтернативы.
Не тільки. Я не раз чув, що goroutines легкі, але Dropbox свої сервіси на Go переписали на Rust. Основна причина — споживання пам’яті.
Для легкої «багатопоточності» в Rust є async / await із zero abstract cost.
Golang вимагає свого рантайму для корутин, що дає накладні витрати. Тому тут програш в ресурсах та перфомансі.
Так в расті також потрібен райнтам для корутин, просто в расті його можна обирати.
Ніт, в расті нема корутин, є
, по суті, маленький скінчений автомат, який не вимагає рантайму
docs.rs/...7.1/tokio/task/index.html
В пітоні теж є async/await разом з корутинами, в расті воно якось не так працюе під капотом чи що?
до чого тут токіо, якщо я пишу про асинк-евейт
rust-lang.github.io/...started/02_why_async.html
наскільки я знаю, застосування async/await в расті потребує райнтайму або async-std або tokio, ні?
почитай.
вимагає фюче і промісів,
і маленький скінчений автомат.
В Го хіба є асинк-евейт.
Наскільки я в темі, нема, тому що вирішили що досить корутин.
Корутини вимагають рантайму.
Асинк-евейт не вимагають.
rust-lang.github.io/..._state_of_async_rust.html
Що я розумію не так?
прочитай про фюче, що не вимагають спеціального рантайму, а компілюються в FSM
асинк авайт базується на фюче.
далі включи логіку, щоб зрозуміти, чому зеро абстракшенк кост і відсутність рантайма
ти читаєш про різні моделі асинка, які можуть бути в расті, та береш за приклад корутини
я ж про одну з них, яка є асинк-евейт.
Вже 4й раз пишу це. А ти застряв на корутинах
Корутини хочуть рантайм.
Багато читати, може потім прочитаю повністю, наскільки я розумію у будь якому випадку потрібне щось що ці футури буде запускати і перевіряти чи вони повернули результат. У будь якому випадку, я не чув щоб десь був async/await без токіо.
думаю що, де токіо, там є асинк-евейт,
але де асинк-евейт, там не обов"язково токіо (можна без нього)
С Async/Await в расте сейчас полный п****ц.
Приведу аналогию.
Представь себе, что я делаю спецификацию для языка X. Но я не хочу добавлять в язык ненужные фичи, и усложнять язык тем, что юзерам не понадобится. Поэтому моя спецификация говорит: программы должны быть написаны латинскими символами и сохранены в файл с расширением .x. Все остальное — implementation defined.
Это офигенный язык, появляются компиляторы, которые уточняют синтаксис языка, пилят свой ABI и т.п. Ты можешь выбрать компилятор на свой вкус и писать. Проблема в том, что программа, написанная для одной реализации языка X не скомпилируется в другой реализации. Две программы, скомпилированный разными реализациями не могут друг с другом взаимодествовать (ибо ABI не определен). Иногда даже библиотека, скомпилированной одной версией компилятора не слинкуется с программой, которая пишется под тот же компилятор, но новой версии.
Я хватаюсь за голову и говорю «вот беда, я сделал такой гибкий язык, а оказывается, надо было делать его менее гибким, ибо с этой свободой экосистема катится в полную жопу», сейчас я буду допиливать синтаксис и ABI в уже существующий язык (ломая все реализации, которые уже есть).
Это примерное описание Rust Async State Of The Union
Если ты пишешь асинхронный код, тебе нужно выбрать рантайм. Рантаймы несовсместимы друг с другом. Часто разные версии одного и того же рантайма не совместимы друг с другом.
Допустим, ты пишешь библиотеку, какой именно рантайм выбрать? Хрен знает, ибо ты не знаешь кто и как будет эту библиотеку юзать. Ты можешь выбрать, например, tokio, потому что он популярный, но теперь тебе надо постоянно обновлять свой crate каждый раз когда выходит новая версия tokio.
Как разработчик ты постоянно имеешь дело с геморроем — твои dependencies все используют разные рантаймы и надо плясать с бубном чтоб просто весь этот ворох депенденсей притянуть и запустить. Представь, например, приложение, которое непррямо подтягивает три разные версии tokio.
Как я понимаю, сейчас схватились за голову и пытаются добавить какую-то стандартнизацию в экосистему Async/Await, чтоб можно было писать runtime-agnostic код, который будет переносим между разными рантаймами.
+++ велика кількість сервісів від Hashicorp написані на Go..
Что является отличным подтверждением того, что Golang — это отличный язык для написания middleware (и здесь можно смело приплюсовать ещё и Docker с Kubernetes)
Но, хайпа ради, язык усиленно тащат в прикладное программирование.
В Go уже устранили уязвимость HTTP Desync Attacks связанную с UTF-8 в хэдерах? news.ycombinator.com/item?id=25857729
Прикольна мова. Якби не мав ніякої спеціалізації, то б подивився.
А так — поки не бачу змісту.
вибачте — сенсу.
жизнь слишком коротка, чтобы тратить ее на язык со статической типизацией и отсутствием templates/generics.
Надо смотреть на вещи шире: там есть утиная типизация. А когда во2-ой версии добавят дженерики, станет даже слишком много полиморфизма.
А таки обещают добавить? А то, помнится, одно время у создателей языка была принципиальная позиция «нет, и никогда не будет»
Уже3-ий год драфты готовят, вышел 3-ий драфт. Если в первом всё крутилось вокруг контрактов, в последнем — вокруг интерфейсов. Я думаю, что и этот драфт тоже ещё сырой, пусть дальше разрабатывают.
У мене склалося враження, що автори прямим текстом казали «програмісти для яких призначено Го не зможуть в дженеріки».
Агащазз.
До «поціновування простоти».
І це в них вийшло. Але далі сталося щось дивне — табуни го-неофітів почали агресивно цей shell script з тредами впарювати де тільки можна. Як той веган, що загубив дитину в торгівельному центрі.
Go справді прекрасний, коли стоїть завдання написати легковісний сервіс з примітивною роботою. Мені дуже сподобалась робота з каналами і простотою запуску корутини. Однак, все ж дійшов висновку, що якщо саме стоїть питання складної доменної моделі і бізнес процесів (привіт ентерпрайз) то тут вже його як основний інструмент брати не найкраща ідея.
Чого?
ну то есть Uber это все еще крохотный простенький сервис без бизнес процессов? :)
а Docker? супер легковесный сервис с примитивной работой?
він оперує апі, що йому надала ОС
Крім того, якість коду там ну не фонтан www.cvedetails.com/...-28125/Docker-Docker.html
Саме тому треба хоч якісь реальні коментарі по тому як в реальних людей пишуть нормальні речі
так мы все таки про качество кода или про его сложность?
ну да, и что там с убером? aws?
Не знаю
both
AWS на 99% написан на Java, Python и, прости меня господи, Bash, а остальной 1% — на C/C++, которые теперь активно замещают Rust’ом
скіки пітону в цій суміші?
Больше чем мне бы хотелось.
Що саме у них написано на Го?
Наведіть приклад складного бізнес процесу в докері (реалізованого на Го, а не на пітоні)
бекенд мобильной апликухи. Они же вроде как и первые кто придумал стандарты и бест практисы uber style guide
Що саме сюди входить? Які саме складні бізнес процеси?
Враховуючи, що убер активно розповідають про мікросервіси, можемо спекулювати, що складна логіка там розмазана по сервісам. Тобто на го у них лише прості шматки. А це те з чого ми почали розмову.
Мировая статистика это конечно прикольно. Но я захожу в список вакансий на доу а там го 117 против .Net 498 и Java 591. Камон, это же даже не смешно:) Даже на плюсах 150+ вакансий.
Порівняйте зростання C++ та Go
С Мая 2020 по Май 2021 +61 для GO, +59 для C++ . Куда смотреть то?=)
Дивіться на перспективу або з 2019 року
интереснее соотношение — количества кандидатов / на эти вакансии
А тут рекрутери-компанії самі винні, бо відгуки на вакансії часто ігноруються.
Нашли что сравнивать, плюсы и Go. Я раньше всю жизнь писал на плюсах, пока не появился Go, и теперь начинать новые проекты на плюсах — вообще не вижу смысла. Ни в какой сфере.
Надо пацанам из эмбеддеда сказать чтобы завязывали со своими плюсами и чистым си и вкатывались в гулаг, ой, то есть в golang. Потому что анонимус на форуме так сказал:)
С++ і ембеддед оксюморон
не зав"язувати з С
а доучувати Go\Rust
github.com/...ssLRS/tree/master/src/src
github.com/...ngoose-os/tree/master/src
github.com/...lin/tree/2.0.x/Marlin/src
В чем проблема то?:)
Як на мене, то у го всього 2 кіллер фічі:
1) Надзвичайно
примітивнийпростий синтаксис2) Дуже проста і ефективна з точки зору користувача робота з concurrency and parallelism.
3) php макаки отлично на него переходят ( это без шуток крутая фича, *** так на scala переедешь прости господи)
Для жсон вже є core ліба, щоб чік-чік і не описувати типи полів
І де подивитись на заміри отих «великих даних»
Мой любимый язык. После него на джаву и ноду даже смотреть не хочется, кринжово становится. Единственное чего объективно не хватает, так это хорошего орма.
Gorm не понравился чем-то?
пустой интерфейс пустым интерфейсом погоняет :( много рефлекта внутри
Всем.
он рулит и бибикает, но кажется сильно медленнее чем альтернативы. Или уже не? Плюс там, вроди бы, были лишние запросы местами... Или и такого уже нет?
github.com/ent/ent вроде годный
В NIX якийсь конкурс по розхвалюванні своєї спеціалізації?
В принципі в заголовку криється основна проблема: Мова програмування (та її інфраструктура) — це не напрямок, а засіб досягнення якоїсь мети, вирішення якоїсь проблеми.
В контексті програміста на ринку праці, все що ви описали не важливо, важливо ЗП, наявність проектів, і екстраполяція цих параметрів на майбутнє.
В контексті вибору платформи для побудови нового проекту, як вже вказали нижче, ви не привели жодного аргументу, що вирізняв би го від інших мов: обирайте го бо це мова загального призначення.
Что важно, а что нет, у каждого своё. Касательно востребованности Go девов на рынке труда и их ЗП, отчет stackoverflow вам в помощь, они чуть ли не в самом топе.
Читайте внимательнее: кроссплатформенность, легковестность, производительность. Это key аргументы. Кого заинтересует, тот сам загуглит бенчмарки в сравнении с тем языком, с которым сравнивает, будь-то php, nodejs или другие. Инфы предостаточно в сети и это не тема этой статьи.
Перекладаю: у вас немає аргументів
Джава, Ц№, Пітон.
1) Тоді для чого ви писали статтю, якщо корисну інфу треба гуглити.
2) Те що я гуглив: для лямбд перформанс був гірше ніж у джави :)
джава дрочер ?
колд старт на джаве хуже. Пробывали юзать в лайве ?
Жах в тому, що джава (плейн, а не спрінг-хібернейт) таки мала кращий час колд старту ніж го :)
Ось тому і хотілося б почитати щось корисніше ніж «Кого заинтересует, тот сам загуглит»
Пробував, більш-менш норм, але пітон показав кращі результати
Компиляция в graalvm native image решает проблему колд старта, а также падает среднее время выполнения: arnoldgalovics.com/...-aws-lambda-with-graalvm
Но питон все же лучше подходит для таких задач
дефіцит гоферів,
це тіпа як в ГЛ школа автозар-автомотів, не баг а фіча.
Ну очень спорные аргументы.
Важно упомянуть, что Golang «easy to learn, hard to master»
Конечно, быстро впрыгнуть в этот поезд и начать писать на Го очень легко. Но начать писать так, что бы это работало надежно, не паниковало, не текло по памяти и не лочилось — задача не тривиальная.
Потом приходят на собеседование, говорят какой простой Го язык, а сами с 3+ годами опыта не могут объяснить устройство интерфейсов или отличие слайсов от массивов :)
Ну не так же все просто с этими горутинами, ну блин :(
Запускать тысячи горутин что бы что? что бы они просто были запущены и все?
goroutine != thread же
точно так же в любой проект вписываются микросервисы на Python, PHP, JAVA, etc.
Свобода выбора языка — одно из преимуществ архитектуры же, а не языка.
А Python, PHP и NodeJS нет? А что такое «удобен»?
И что значит I/O не блокирует веб запросы? Шедулер же этим и занимается, нет? А GOMAXPROCS? Конечно, Го сервер может принять в себя 10к rps, но он все еще зависит от количества ядер.
Ну и gRPC не может быть аргументом в пользу только Го :)
Тут даже смешнее то, что это подаётся как уникальная фича Golang, хотя того же самого эффекта можно добиться и в NodeJS, и в Java, и в .NET, и, если не ошибаюсь, даже в Python c помощью asyncio.
Вот в PHP, да, асинхронное I/O пока ещё вроде бы не стало мэйнстримом, но движение в этом направлении есть.
Вот только в ноде надо заморачиваться с Promise/async-await, в Java тоже со специфичными API а в Go просто пишешь синхронный код, а за тебя шедулер уже разбросает корутины на epoll.
В ноде то же самое, только в Golang твоя корутина возвращает channel, а в Ноде — promise.
В Golang нужно явным образом объявлять корутину как возвращающую канал, создавать этот канал внутри корутины и публиковать в созданный канал возвращаемое значение.
levelup.gitconnected.com/...-async-await-ee62d93078ec
И чем так принципиально отличается await в ноде от конструкции типа
r := <-longRunningTask()в Golang — я, если честно, не очень понимаю.
Если же не нужно дожидаться результата корутины, то и в ноде прекрасно можно обойтись без await.
Синхронізація в Go простіша
Описанные в статье примитивы синхронизации не уникальны для Golang.
Promise.allSettled будет прямым аналогом WaitGroup. Для throttling / rate limiting есть github.com/SGrondin/bottleneck.
Mutex’ы в разработке на JS используются не так часто, но и они есть: github.com/DirtyHairy/async-mutex.
Вот каналы — действительно, уникальная фича Golang, как минимум, в плане легковесности. В ноде есть worker threads и postmessage/onmessage, но воркеры нужно выносить в отдельные модули (или морочиться с fork паттерном а-ля Юникс стайл)
а нода уже умеет вm-n scheduler?
Моего гугл-фу не хватило, чтобы найти описание этого термина. Но, подозреваю, что не умеет, так как нода была изначально спроектирована для асинхронного ввода/вывода, а не для параллельного выполнения вычислительных задач.
В WorkerThreads используется стандартный планировщик потоков ОС.
Речь о M:N threading model, в которую очень хорошо умеет шедулер Go, жонглируя горутинами по тредам. Нода в такое вроде пока не умеет.
Но имхо всё равно это аргументы уровня «а почему Redis однопоточный?» Исторически сложилось©(тм). ))
FB уже давно завез асинхронное I/O и еще сто миллионов новых вещей в PHP, было бы желание юзать.
Было бы желание авторов добавлять поддержку асинхронности в PHP фреймворки :)
Визначення того, що вони назвали «wanted»:
Тобто розробники з цією мовою ще не працювали, але чули що вона є хорошою. Краще звертати увагу на таб «Loved».
Насправді у TypeScript найкраща динаміка і дуже хороші перспективи, в тому числі і на бекенді.
Есть такая поговорка — «Каждый кулик своё болото хвалит».
В хвалебных статьях про Golang очень часто «забывают» упомянуть про ниши, где баланс между преимуществами и, скажем так, особенностями и ограничениями языка будет в пользу преимуществ. Как минимум, далеко не везде оправданы микросервисы, а для написания больших монолитных систем Golang подходит не то, чтобы очень хорошо.
Что касается TypeScript, то он автоматически подразумевает NodeJS в качестве рантайма. Который, аналогично, имеет свою нишу — преимущественно, это обработка запросов, где львиная доля времени выполнения приходится на ожидание I/O. Да, я в курсе про worker threads и про кластеризацию ноды, но и то, и другое — это костыли, которые позволяют хоть с грехом пополам сделать то, для чего Нода изначально не была спроектирована.
Дмитрий, видимо, «будет НЕ в пользу преимуществ», судя по контексту комментария?
Можно читать и так, и так :) Так или иначе, моя мысль была в том, что есть ниши, в которых использование Golang более чем оправдано (то же потоковое видео или парсинг больших объёмов данных), а есть ниши, куда Golang тянут исключительно из-за хайпа.
Откровенно говоря, от обсуждений в духе «как заменить PHP на Golang» подгорает больше всего, поскольку, при всей репутации PHP как «несерьёзного» языка, в его экосистеме есть вполне зрелые фреймворки для написания довольно больших по масштабу систем.
Golang же, изначально проектировался создателями как язык для небольших систем, откуда и его популярность в микросервисах (где она, в целом, оправдана, если вынести за скобки стоимость и сложность поиска разработчиков).
Згоден за мікросервіси. В теорії, для них треба мати хоча б таке навантаження, яке воно є наприклад на сайті rozetka.com.ua, prom.ua, hotline.ua і т.д. Іто я сумніваюсь, що моноліт на кластері не потягне їх.
Згоден теж. Напрягає, що мені треба обходити CPU intensive задачі за допомогою різних трюків. Разом із тим, нода надає досить хороші можливості для веб-розробників, хорошу швидкість роботи, хорошу швидкість розробки.
Так и есть. Я ни в коем случае не подразумевал, что у Ноды нет сильных сторон. Бесспорно, они есть и перечислены в вашей цитате. Я исключительно против того, чтобы превращать любой язык или любой рантайм в «священный Грааль», чем, увы, порой грешат фанаты Golang.
А чому?
Я без підвоха, дійсно цікаво.
Ібо, згідно моїх уявлень, якщо мова компільована, модульна і строго типізована, що заважає зробити моноліт?
дженериків і ооп немає
а каким образом отсутствие дженериков и ооп мешает писать монолиты?
Йшла мова про великі моноліти.
Я бы TypeScript не назвал «языком», т.к. без спецификации — то просто удобная тулза для автокомплита с тысячами разных конфигов.
Просто оставлю это здесь:
www.typescriptlang.org/docs
Стыдно на вашей позиции то путать документацию к либе и спецификацию языка.
github.com/...t/TypeScript/issues/15711
По ссылке какой-то многостраничный срач. Вы правда думаете, что кто-то будет тратить своё время на чтение всех этих словесных баталий? Если уж вы приводите эту ссылку как аргумент, то неплохо бы процитировать саму суть, оставив ссылку как пруфлинк.
Из прочтения «по диагонали» сложилось впечатление, что у нескольких человек подгорает от того, что у TS нет формальной академичной спецификации, и они выносят мейнтейнерам мозг по этому поводу.
Вмесе с тем,
— это уже за гранью добра и зла. Можно спорить о том, что TypeScript не имеет ECMA стандарта, или о том, что TypeScript reference недостаёт «академичности» описания языка, или даже о том, что описание языка «размазано» между разделами Handbook и Reference.
Но, так или иначе, это именно язык со своим синтаксисом, надстроенным поверх ES6, и со своей системой типов.
Той документации, которая есть на официальном сайте, на практике более чем достаточно для комфортной работы. А пуристы, чем тратить время и силы на срачи, лучше бы потратили их на помощь с созданием формальной спецификации (вот только в написание таких спек ещё нужно уметь).
Если брать утверждение предыдущего оратора, что дока тайпскрипта это «спецификация», то циклов в тайпскрипте действительно нет. Точнее есть, но один for .. of и то в секции what’s new.
Typescript является расширением ES6, поэтому просто нет смысла повторять в его документации то, что уже и так отлично задокументировано в стандарте ECMA-262.
Если бы он действительно являлся
, то да. Но на практике это некое выборочное подмножество, которое нигде не описано.
Простейший пример:
class Foo { async constructor() {} }Глупости. Любой валидный код на ES6 является валидным кодом на TypeScript. By design. Но твой пример не является валидным кодом с точки зрения ES6.
Соответственно, пример выглядит как edge case, который не документирован, но воспринимается транслятором. Ну так, ни один язык и ни один компилятор не застрахованы от такого.
Ты сам пробовал транслировать этот пример в JavaScript? Какой версией TS, и что получается на выходе?
Эта конструкция не валидна и в ES6 strict mode:
developer.mozilla.org/...rrors/Reserved_identifier
слово interface является зарезервированным и в ES6.
Схоже вас розводять (ну або проявилась проста некомпетентність «Alexander js dev»). Я із TypeScript майже із самого початку його створення, ніколи така конструкція валідною не була.
class Foo { async constructor() {} }Спасибо, версию троллинга я тоже не исключал )
Но, и с недокументированным поведением компиляторов сталкивался ещё в 90х, поэтому, допустил, что в TS непреднамеренно могли оставить «задел» под синтаксический сахар для класса с асинхронной инициализацией.
Тем более, что народ с таким экспериментировал и в plain JS тоже:
gist.github.com/...e5f42c859f64be3ad7fc6f4ed
ну так після жс і не таке полюбиш
/kekw
К сожалению: `программисты хотели бы писать код != заказчики хотели бы платить`
Дякую за статтю!
Популяризація Go в Україні це дуже важливо бо багато відкритих вакансій з Go (jobs.dou.ua тренди Golang) з гарними винагородами від $6000 до $8000.
Цьогорічна стаття як перекваліфікуватись з PHP на Go.
А ще в Україні є спільнота GolangUA, яка активно розвивалась до карантину, мала щомісячні конференції.
Тарас ви б могли в статті прорекламувати Go вакансії вашої компанії. А ще чи розглядає ваша компанія PHP спеціалістів без комерційного досвіду з Go, але з домашніми проєктами?
Да, рассматриваем. Сейчас в одном из быстрорастущих проектов переписываем с Symfony на Golang. Для ребят которые хотят перейти, как раз хорошая возможность влиться в технологию, с учетом того, что рядом есть опытные тиммейты.
В целом на сайте есть вакансии от Jun до Sen + открыт набор на бесплатную обучающую программу по Golang с возможностью трудоустройства после её успешного завершения.
это только в ХК?
да, только Харьков.