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

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

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

В данной статье я хочу рассказать о небольшом и забавном проекте выходного дня по передаче файлов через анимированные QR коды. Проект написан на Go, с использованием Gomobile и Gopherjs – последний для веб-приложения для автоматического замера скорости передачи данных. Если вам интересна идея передачи данных через визуальные коды, разработка веб-приложений не на JS или настоящая кроссплатформенность Go — велкам под кат.

Буквально пару дней назад в Денвере закончилась очередная, уже 5-я по счёту, крупнейшая конференция по Go – GopherCon. На ней команда Go сделала важное заявление – черновики предварительного дизайна новой обработки ошибок и дженериков в Go 2 опубликованы, и все приглашаются к обсуждению.

Я постараюсь подробно пересказать суть этих черновиков в трёх статьях.

Как многим, наверняка, известно, в прошлом году (также на GopherCon) команда Go объявила, что собирает отчёты (experience reports) и предложения для решения главных проблем Go – тех моментов, которые по опросам собирали больше всего критики. В течении года все предложения и репорты изучались и рассматривались, и помогли в создании черновиков дизайна, о которых и будет идти речь.

Итак, начнём с черновиков нового механизма обработки ошибок.

Содержание: Чтобы выучить Go, я портировал свой бекенд небольшого сайта с Python на Go и получил забавный и безболезненный опыт в процессе.

Я хотел начать учить Go какое-то время — мне нравилась его философия: маленький язык, приятная кривая обучения и очень быстрая компиляция (как для статически-типизированного языка). Что меня наконец заставило шагнуть дальше и таки начать его учить, так это то, что я стал видеть всё больше и больше быстрых и серьезных программ, написанных на Go — Docker и ngrok, в частности, из тех, которые я недавно использовал.

Философия Go не всем по вкусу (нет исключений, нельзя создавать свои дженерики, и т.д.), но она хорошо ложилась на мою ментальную модель. Простой, быстрый, делающий вещи очевидным способом. Во время портирования я особо был впечатлен насколько полноценной оказалась стандартная библиотека и инструментарий.

Портирование

Я начал с парочки 20-ти строчных скриптов на Go, но этого было как-бы мало, чтобы понять язык и экосистему. Поэтому я решил взять проект побольше и выбрал для портирования бекенд для моего сайта GiftyWeddings.com.

На Питоне это было около 1300 строк кода, используя Flask, WTForms, Peewee, SQLite и ещё несколько библиотек для S3, ресайзинга картинок и т.д.

Для Go-версии я хотел использовать как можно меньше внешних зависимостей, чтобы лучше освоить язык и как можно больше поработать со стандартной библиотекой. В частности, у Go есть отличные библиотеки для работы с HTTP, и я решил пока не смотреть на веб-фреймворки вообще. Но я всё же использовал несколько сторонних библиотек для S3, Stripe, SQLite, работы с паролями и ресайза картинок.

Если вы хоть раз были сбиты с толку, что означает символ "амперсанд" (&) или "звёздочка" ("знак умножения", *) или запутывались, когда что использовать, то это статья для вас. Авторы Go старались сделать язык знакомым большинству программистов, и многие элементы синтаксиса заимствовали из языка С. Но в 2017м уже сложно понять, большинство программистов владеют С или нет, и смею полагать, что уже нет. Поэтому концепции хорошо знакомые прошлому поколению разработчиков, могут выглядеть совершенной абракадаброй для для нового поколения. Давайте немного копнём историю и расставим все точки над ї в вопросах указателей в Go и использования символов & и *.

Одним из нововведений в Go 1.9 было добавление в стандартную библиотеку нового типа sync.Map, и если вы ещё не разобрались что это и для чего он нужен, то эта статья для вас.

Для тех, кому интересен только вывод, TL;DR:

если у вас высоконагруженная (и 100нс решают) система с большим количеством ядер процессора (32+), вы можете захотеть использовать sync.Map вместо стандартного map+sync.RWMutex. В остальных случаях, sync.Map особо не нужен.

Если же интересны подробности, то давайте начнем с основ.

На этой неделе мы отмечаем 10-летнюю годовщину создания Go.

Всё началось с обсуждения вечером в четверг, 20 сентября 2007. Оно привело к организованной встрече между Робертом Грисмайером, Робом Пайком и Кеном Томпсоном в 2 часа дня на следующий день в конференс-руме Yaounde в Здании 43 главного кампуса Google Mountain View. Название для языка появилось 25-го числа, несколько сообщений спустя после начала переписки о дизайне:

Тема: Re: обсуждение языка программирования 
От: Роб 'Коммандер' Пайк 
Дата: Вт, Сен 25, 2007 в 3:12 PM
Кому: Роберт Грисмайер, Кен Томпсон    

у меня появилась пара мыслей по этому поводу на пути домой.

1. имя

'go'. можно найти оправдания для такого имени, но у него очень хорошие свойства.
оно короткое, легко печатать, например: goc, gol, goa. если будет интерактивный 
дебаггер/интерпретатор, он может быть просто назван 'go'. расширение файла .go
...

Многие знакомы с gRPC — открытым RPC-фреймворком от Google, который поддерживает 10 языков и активно используется внутри Google, Netflix, Kubernetes, Docker и многими другими. Если вы пишете микросервисы, gRPC предоставляет массу преимуществ перед традиционным подходом REST+JSON, но на существующих проектах часто переход не так просто осуществить из-за наличия уже использующихся REST-клиентов, которые невозможно обновить за раз. Нередко общаясь на тему gRPC можно услышать "да, мы у нас в компании тоже смотрим на gRPC, но всё никак не попробуем".

Что ж, этой проблеме есть хорошее решение под названием grpc-rest-gateway, которое занимается именно этим — автогенерацией REST-gRPC прокси с поддержкой всех основных преимуществ gRPC плюс поддержка Swagger. В этой статье я покажу на примере как это выглядит и работает, и, надеюсь, это поможет и вам перейти на gRPC, не теряя существующие REST-клиенты.

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

Но писать код на ассемблере, всё же, сложно, анализировать его ещё сложнее, а криптография ошибок не прощает. Разве не было бы замечательно иметь возможность писать эти функции на каком-нибудь более высокоуровневом языке?

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

Перевод отрывка из интервью с создателем Node.js Раяном Далом (Ryan Dahl) в котором обсуждается модель программирования и язык Go.

— Расскажи нам, как проходила начальная разработка Node? Это ведь уже было достаточно давно, ты создал Node в 2009.

Райан: — Я думаю для себя лично, что нет лучшего момента в жизни, когда ты, как это говорится, «в потоке» и у тебя есть идея, в которую ты сильно веришь. И при этом есть время, чтобы сесть и на самом деле работать над ней. И я думаю, Node была именно такой идеей, которая ждала, чтобы её кто-то ухватил, и если бы не я, то это бы сделал кто-то другой. Но так случалось, что я был тогда достаточно свободен от работы и имел время, и мог работать нон-стоп несколько месяцев, которых как раз были нужны, чтобы выкатить начальную версию. Так что да, это был отличный период.

— Отлично, супер. Node построена на идее «полностью асинхронной» модели программирования. Удачна ли она была для Node?

Перевод статьи разработчика компании Samsara об опыте использования Go на автомобильном роутере с 170MB оперативки.

В компании Samsara мы разрабатываем автомобильные роутеры, которые предоставляют в реальном времени телеметрию двигателя через CAN шину, данные с беспроводных термосенсоров через Bluetooth Low Energy и соединение по Wi-Fi. Эти роутера очень ограничены по ресурсам. В отличие от серверов с 16 GB оперативной памяти, у наших роутеров есть всего 170MB и всего одно ядро.

Наша новая камера CM11, закреплённая в кабине.

Чуть ранее в этом году мы выпустили видео камеру, которая крепится внутри кабины, чтобы улучшить безопасность машин для наших клиентов. Эта камера, по сути, является периферийным устройством для нашего роутера, которое генерирует много данных. Она записывает 1080p H.264 видео с частотой 30 кадров в секунду.

Наша первая реализация сервиса работы с камерой, который был отдельным процессом на роутера, потреблял 60MB, то есть почти половина всей доступной памяти, но мы знали, что можем добиться лучших результатов. Мы буферизировали только 3 секунды видео потока на 5Mpbs, и 60MB было достаточно, чтобы удерживать в памяти целых 90 секунд видео, так что мы решили посмотреть, где мы можем уменьшить использование памяти.

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

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

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

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

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

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

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

Перевод статьи Дейва Чини — ответа на предыдущий пост Питера Бургона "Теория современного Go" — с попыткой провести мысленный эксперимент, как бы выглядел Go без переменных в глобальной области видимости вообще. Хотя в некоторых абзацах можно сломать язык, но пост достаточно интересный.

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

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

tl;dr магия это плохо; глобальные состояние это магия → глобальные переменные в пакетах это плохо; функция init() не нужна.

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

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

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

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

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

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

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

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

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

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

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

Введение

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

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

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

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

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