Ровно шесть лет назад в этот день язык Go был открыт миру в виде open-source проекта. С тех пор, более 780 разработчиков внесли более 30000 коммитов в 22 репозитория проекта Go. Экосистема продолжает расти, и сейчас на GitHub-е создано более 90000 репозиториев. В оффлайне же мы видим постоянный рост новых событий и пользовательских групп, посвященных Go по всему миру.

Перевод статьи о вопросе выбора языка и компромиссе сложности и продуктивности.

Предупреждение: это разглагольствование.

Недавно я сделал очередной большой шаг вперед на своём пути просвещения в Хаскеле. Наконец-то я вижу, как много различных частей мозаики Хаскеля гармонично складываются воедино. На этом моменте, я почувствовал, что готов идти вперёд и писать полезные программы. Я прочёл исходный код web-фреймворка Scotty и был приятно удивлён тем, что я прекрасно понимал, как он работает. Я полностью влюблён в Хаскель. Мне нравится, что он заставляет тебя думать. Ты не просто открываешь текстовый редактор и начинаешь ударять по клавишам, чтобы написать программу на Хаскеле. Я люблю то, что Хаскель поощряет обобщения и абстракции. Одним из «эврика»-моментов в моём пути было понимание всех последствий того, почему функция типа a -> a имеет только одну реализацию. Я подсел на возможность запустить программу в первый раз и знать, что она заработает (после борьбы с компилятором целую вечность). Я думаю, что монады и линзы — очень умные вещи. Да по многим критериям, Haskell — идеальный язык программирования.

И у меня заняло 4 года прийти к этому.

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

Перевод статьи «For Better or For Worse» разработчика из компании DataDog Inc. Статья посвящена вопросу дизайна языков программирования и связи дизайна с попытками оценок качества языков. Частично является ответом на недавно переведенную тут эту статью.

В программистской тусовке возникает мем об “объективном качестве” дизайна Go. Буквально на днях я встретил его в статье про выбор языков от Honza, где он был очень хорошо виден:

Учтите, язык объективно очень плохо спроектирован. [...] И, при этом, Go гораздо более популярен, чем Haskell, если верить GitHub. При этом, уже столько отличных проектов, написанных на Go, вроде Docker, InfluxDB, etcd, Consul, Prometheus, packer и других.

Я думаю, что это крайне интересный набор противоречий, и автор с этим согласен.

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

Когда люди с таким видением пытаются объяснить популярность Go, они неизбежно приходят к парадоксу. Если Go настолько плох, почему он так популярен?

В этой статье хотелось бы поделиться одним из способов простого и удобного интеграционного тестирования http-сервиса, написанного на Go. Интеграционные тесты бывает непросто создавать так, чтобы обходиться без сложных скриптов, но на помощь нам придет Docker, пакет из стандартной библиотеки httptest и билд-теги. Для примера мы будем использовать MySQL базу данных с миграциями, управляемыми пакетом goose. Финальной целью является получить простое и удобное кроссплатформенное интеграционное тестирование простым запуском команды go test, будь это рабочий ноутбук или Continuous Integration сервер.

В игре Go очень простые правила, но стать мастером в ней непросто, нужно научиться думать паттернами, территориями и прочими стратегическими концепциями. Язык Go не совсем случайно назван аналогично названию этой игры. В своем выступлении на недавнем митапе в Сан-Франциско, Роб Пайк упомянул книгу «Постулаты Go» (Go Proverbs), которые описывают сложные стратегии простыми поэтичными фразами. Эти постулаты несут глубинный смысл для тех, кто знаком с игрой Go, и могут казаться пустыми фразами тем, кто не знаком. И в этом нетехническом докладе он предложил придумать аналогичным способом «постулаты» и для языка Go.

Вот некоторые из них:

• Don't communicate by sharing memory, share memory by communicating.
• Concurrency is not parallelism.
• Channels orchestrate; mutexes serialize.
• The bigger the interface, the weaker the abstraction.
• interface{} says nothing.
• Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.
• A little copying is better than a little dependency.
• Cgo is not Go.
• Clear is better than clever.
• Reflection is never clear.
• Errors are values.

Это чем-то похоже на Zen of Python. Вы можете не соглашаться с ними, но эти постулаты отражают идиоматичность и подход в Go. Давайте разберем подробнее каждый из них по мотивам доклада (видео в конце поста).

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

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

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

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

Когда у вашей компании не хватает опыта в инструментарии или технологиях, которые могут сделать её более продуктивной, у неё есть «долг знаний» (knowledge debt).

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

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

Задачи
— Разработка ядра системы и компонентов бекенда
— Анализ и улучшение эффективности, масштабируемости и стабильности различных ресурсов системы

Требования
— Магистр в Computer Science или смежной области
— 2+ года опыта в Java
— Эксперт в реляционных базах данных и оптимизации запросов в MySQL

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

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

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

В этой статье вы узнаете:

• в чем отличие от интерфейсов в Java
• важные и неочевидные последствия этих отличий
• как устроены интерфейсы под капотом
• вспомним про пустой интерфейс (interface{})
• затронем сакральную тему про дженерики
• разберемся, кто и зачем должен создавать интерфейс
• и постараемся научиться не абьюзить интерфейсы и начать жить

(artwork by Svitlana Agudova)

интервьюер: Приветствую, хотите кофе или что-нибудь еще? Нужен перерыв?

я: Нет, кажется я уже выпил достаточно кофе!

интервьюер: Отлично, отлично. Как вы относитесь к написанию кода на доске?

я: Я только так код и пишу!

интервьюер: ...

я: Это была шутка.

интервьюер: OK, итак, вам знакома задача "fizz buzz"?

я: ...

интервьюер: Это было да или нет?

я: Это что-то вроде "Не могу поверить, что вы меня об этом спрашиваете."

интервьюер: OK, значит, нужно напечатать числа от 1 до 100, только если число делится нацело на 3, напечатать слово "fizz", если на 5 — "buzz", а если делится на 15, то — "fizzbuzz".

я: Я знаю эту задачу.

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

я: ...

интервьюер: Вот маркер и губка.

я: [задумался на пару минут]

интервьюер: Вам нужна помощь, чтобы начать?

я: Нет, нет, все в порядке. Итак, начнем с пары стандартных импортов:

import numpy as np
import tensorflow as tf

интервьюер: Эм, вы же правильно поняли проблему в fizzbuzz, верно?

я: Так точно. Давайте обсудим модели. Я думаю тут подойдет простой многослойный перцептрон с одним скрытым слоем.

Перевод одной из статей Бена Джонсона из серии "Go Walkthrough" по более углублённому изучению стандартной библиотеки в контексте реальных задач.

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

Пакет io является одним из самых фундаментальных во всей стандартной библиотеке. Он предоставляет набор интерфейсов и вспомогательных функций для работы с потоками байтов.

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

Перевод одной из статей Бена Джонсона из серии "Go Walkthrough" по более углублённому изучению стандартной библиотеки Go в контексте реальных задач.

В предыдущем посте мы разобрались, как работать с потоками байт, но иногда нам нужно работать с конкретным набором байт в памяти. Хотя слайсы байт вполне подходят для многих задач, есть немало случаев, когда лучше использовать пакет bytes. Также мы рассмотрим сегодня и пакет strings, так как его API практически идентичен bytes, только он работает со строками.

Этот пост является одним из серии статей по более углублённому разбору стандартной библиотеки. Несмотря на то, что стандартная документация предоставляет массу полезной информации, в контексте реальных задач может быть непросто разобраться, что и когда использовать. Эта серия статей направлена на то, чтобы показать использование пакетов стандартной библиотеки в контексте реальных приложений. Если у вас есть вопросы или комментарии, вы всегда можете написать мне в Твиттер — @benbjohnson.

Перевод одной из статей Бена Джонсона из серии "Go Walkthrough" по более углублённому изучению стандартной библиотеки Go в контексте реальных задач.

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

Этот пост является одним из серии статей по более углублённому разбору стандартной библиотеки. Несмотря на то, что стандартная документация предоставляет массу полезной информации, в контексте реальных задач может быть непросто разобраться, что и когда использовать. Эта серия статей направлена на то, чтобы показать использование пакетов стандартной библиотеки в контексте реальных приложений. Если у вас есть вопросы или комментарии, вы всегда можете написать мне в Твиттер — @benbjohnson.

Перевод небольшого туториала об использовании HTTP/2 Server Push в стандартной библиотеке Go.

Введение

HTTP/2 был придуман, чтобы решить многие из проблем HTTP/1.x. Современные веб-страницы используют массу дополнительных ресурсов — HTML, скрипты и таблицы стилей, картинки и так далее. В HTTP/1.x каждый из этих ресурсов должен быть запрошен явно отдельным запросом и это может очень замедлять загрузку страницы. Браузер начинает с загрузки HTML, узнаёт про новые необходимые ресурсы по мере разбора страницы. В итоге сервер ожидает пока браузер запросит очередной ресурс и сеть просто простаивает и не используется эффективно.

Чтобы улучшить latency, в HTTP/2 появилась поддержка server push, которая позволяет серверу самому послать ресурсы браузеру ещё до того, как они будут запрошены явно. Часто сервер знает наперёд какие дополнительные ресурсы будут запрошены данной веб-страницей и может начать передавать их вместе с ответом на начальный запрос страницы. Это позволяет серверу максимально эффективно использовать сетевой канал, который бы простаивал в противном случае, и улучшить время загрузки страницы.

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

Компании Cloudflare уже пошёл 6-й год и предоставление авторитативных DNS серверов было основной нашей инфраструктуры с самого начала. С тех пор мы выросли, став самым большим и быстрым поставщиком услуг DNS в Интернете, обслуживая около 100 000 сайтов из списка Alex top 1M sites, и более 6 миллионов DNS зон.

На сегодняшний день наш сервис DNS отвечает около 1 миллиона запросов в секунду — не считая трафика во время атак — с помощью глобальной anycast сети. Разумеется, технологии, которые мы, будучи растущим стартапом, использовали для того, чтобы обслуживать сотни и тысячи зон несколько лет назад уже не справляются с миллионами, которые мы имеем сегодня. В прошлом году мы решили заменить два ключевых элемента в нашей DNS инфраструктуре: часть нашего DNS сервера, который отвечает на авторитативные запросы и систему, которая берёт пользовательские изменения и обновляет их на пограничных серверах по всему миру.

Перевод блог поста и доклада Russ Cox с GopherCon 2017, с обращением ко всему Go сообществу помочь в обсуждении и планировании Go 2. Видео доклада будет добавлено сразу после опубликования.

25 сентября 2007 года, после того как Роб Пайк, Роберт Грисмайер и Кен Томпсон несколько дней обсуждали идею создания нового языка, Роб предложил имя "Go".

В следующем году, Ян Лэнс Тейлор и я присоединились к команде и мы впятером создали два компилятора и стандартную библиотеку, которые были публично открыты 10 ноября 2009.

Задача планировщика в Go — распределять запущенные горутины между потоками ОС, которые могут исполняться одним или большим количеством процессоров. В многопоточных вычислениях, возникли две парадигмы в планировании: делиться задачами (work sharing) и красть задачи (work stealing).

• Work-sharing: Когда процессор генерирует новые потоки, он пытается мигрировать их на другие процессоры, в надежде, что они попадут к простаивающему или недостаточно нагруженному процессору.
• Work-stealing: Недостаточно нагруженный процессор активно ищет потоки других процессоров и "крадет" некоторые из них.

Миграция потоков происходит реже при work stealing подходе, чем при work sharing. Когда все процессоры заняты, потоки не мигрируют. Как только появляется простаивающий процессор, рассматривается вариант миграции.

В Go начиная с версии 1.1 планировщик реализован по схеме work stealing и был написан Дмитрием Вьюковым. Эта статья подробно объясняет устройство work stealing планировщиков и как он устроен в Go.

Совсем недавно я открыл для себя Flutter – новый фреймворк от Google для разработки кроссплатформенных мобильных приложений – и даже имел возможность показать основы Flutter человеку, который никогда не программировал до этого. Сам Flutter написан на Dart – языке, родившимся в браузере Chrome и сбежавшим в мир консоли –  и это навело меня на мысль "хм, а ведь Flutter мог вполне бы быть написан на Go!".

Ведь почему нет? И Go и Dart созданы Google, оба типизированные компилируемые языки – повернись некоторые события чуть иначе, Go был бы отличным кандидатом для реализации такого масштабного проекта, как Flutter. Кто-то скажет – в Go нет классов, дженериков и исключений, поэтому он не подходит.

Так давайте представим, что Flutter уже написан на Go. Как будет выглядеть код и вообще, получится ли это?

Этот пост является версией моей же англоязычной статьи "How to avoid gotchas in Go", но слово gotcha не переводится на русский, поэтому я буду использовать это слово как без перевода, так и немного непрямой вариант — "наступать на грабли".

Gotcha — корректная конструкция системы, программы или языка программирования, которая работает, как описано, но, при этом, контринтуитивна и является причиной ошибок, поскольку её легко использовать неверно.

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

Но один вопрос меня мучал долгое время — почему я сам никогда не делал этих ошибок? Серьезно, самые популярные из них, вроде путаницы с nil-интерфейсом или непонятного результата при append()-е слайса — в моей практике никогда не были проблемой. Каким-то образом мне повезло обойти эти подводные камни с первых дней своей работы с Go. Что же мне помогло?

И ответ оказался довольно прост. Я просто очень вовремя прочёл несколько хороших статей о внутреннем устройстве структур данных в Go и прочих деталях реализации. И этого, вполне поверхностного на самом деле, знания было достаточно, чтобы выработать некоторую интуицию и избегать этих подводных камней.