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

Ничего сложного тут не будет, и ради большей наглядности я записал ascii-анимации (с помощью сервиса asciinema), но, надеюсь, будет познавательно.

Вот такими словами начинается комментарий к свежему коммиту в master-ветку Go:

This change deletes the C implementations of the Go compiler and assembler from the master branch.

(«Эти изменения удаляют C-реализацию компилятора и ассемблера Go из главной ветки»)

Эти слова — труд почти года работы команды Go по переписыванию компилятора с C на Go. Это был на 90% автоматический процесс. Теперь Go компилирует сам себя.

Зачем это было нужно и чуть больше подробностей под катом.


Картинка: Твиттер Russ Cox

На Амазоне анонсировали новую книгу Брайана Кернигана и Алана Донована с ёмким названием «The Go Programming Language». Кто не в курсе — Брайан Керниган это один из соавторов Unix, автор cron-а и автор одной из самых культовых книг в мире программирования "The C Programming Language", написанную вместе с Деннисом Ричи в 1978-м.

Книга доступна для предзаказа, релиз бумажной версии запланирован на 27 августа 2015.

Один из частых вопросов про Go — существует ли хорошая кроссплатформенная UI-библиотека на Go. Как правило, вопрошающих отсылали либо к go-qml, либо к andilabs/ui (биндинги к C-реализациям нативного UI для каждой платформы), но в целом достойного проекта по нативному Go UI пока не было. На днях же, пару разработчиков из Google открыли для open-source мира проект gxui, который нацелен восполнить нишу нативных UI-библиотек для Go.

Проект еще сырой, но выглядит неплохо и перспективно.

Давайте взглянем поближе.

Ребята из компании Mailgun презентовали новый кроссплатформенный дебаггер для Go, который использует оригинальную технологию, в корне отличающуюся от стандартных подходов. Забегая наперед — с помощью Gopherjs этот дебаггер работает даже в браузере.

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


(Credit orig.photo: Nathan Youngman)

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

TL;DR Golang был разработан специально для того, чтобы расцвести в больших проектах, которые пишут большие группы программистов разных уровней, и в мире нет такой группы больше, чем open-source сообщество.

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

В апреле 2001 Пол Грэм написал статью «Превосходя посредственность» («Beating the averages» — ориг).

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

Секретное оружие

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

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

Предлагаю читателям «Хабрахабра» перевод статьи главного архитектора компании Malwarebytes о том, как они достигли обработки 1 миллиона запросов в минуту всего на 4 серверах.

У нас в Malwarebytes мы переживаем бешеный рост и с тех пор, как я присоединился к компании около года назад в Кремниевой Долине, одной из моих основных обязанностей было проектирование и разработка архитектур нескольких систем для развития быстрорастущей компании и всей необходимой инфраструктуры для поддержки продукта, который используют миллионы людей каждый день. Я работал в индустрии антивирусов более 12 лет в нескольких разных компаниях, и знаю, насколько сложными получаются в итоге эти системы, из-за колоссальных объемов данных, с которыми приходится иметь дело ежедневно.

Данный материал представляет собой перевод блог поста, который в реальном времени ведут ребята из Sourcegraph с конференции GopherCon 2015, которая проходит в эти дни в Денвере, Колорадо. Полное видео и слайды доклада будут добавлены к посту, как только будут доступны.

Ричард Л. Хадсон (Рик) знаменит по своим работам в управлении памятью, включая изобретение алгоритмов Train, Sapphire и Mississippi Delta, а так же GC stack maps, которые позволили реализовать сборку мусора в статически-типизированных языках вроде Java, C# и Go. Под его авторством были опубликованы документы о рантаймах языков, управлении памятью, многопоточности, синхронизации, моделей памяти и транзакционной памяти. Сейчас Рик является одним из членов команды Go в Google и работает над проблемами сборщика мусора и рантайма.

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

^{(ориг. фото)}

Перевод статьи о том, как компания перевела свою инфраструктуру на Go 1.5 и уменьшила паузы сборщика мусора с ~279мс до ~10мс.

Маркетинг системы, ориентированные на клиентов, зависят от сбора и анализа как можно большего количества связанных событий. Клиенты буквально везде, и количество данных растет экспоненциально. Язык Go играет важную роль в нашей системе сбора данных. Сегодня FLXone обрабатывает 3+ миллиарда запросов в день написанным с нуля нашим приложением.

Перевод статьи из официального блога компании Basecamp (создателей Ruby on Rails) о том, как Go используется в их компании.

Basecamp это компания, полностью завязанная на Ruby. Все наши клиентские приложения написаны на Ruby on Rails, мы используем Ruby для автоматизации с помощью Chef, мы деплоим с помощью Ruby через Capistrano, и для почти любой задачи вы найдете у нас Ruby скрипт, который делает эту работу.

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

Перевод блог-поста главного автора сборщика мусора в Go, Ричарда Хадсона, изобретателя многих алгоритмов для GC в других языках, одного из ведущих инженеров Intel (сейчас работает в Google).

Go планирует свой сборщик мусора (GC) не только для 2015 года, но и для 2025 и дальше: это должен быть GC, который поддерживает современные принципы разработки программ и хорошо масштабируется вместе с появлением нового софта и железа в следующие десятилетия. В этом будущем нет места для пауз GC с «остановкой мира» (stop-the-world), которые были преградой для более широкого применения таких безопасных и надёжных языков, как Go.

Go 1.5, первый проблеск этого будущего, достиг цели уменьшить верхнюю планку пауз до 10мс, которую мы поставили перед собой год назад. Некоторые впечатляющие цифры вы можете посмотреть в докладе на GopherСon. Эти улучшения времени отклика привлекли много внимания; блог пост Робина Верлангена «Миллиарды запросов в день встречают Go 1.5» подтверждает наши расчеты реальными результатами. Отдельно нам понравились скриншоты графиков продакнш-сервера от Алана Шреве и его комментарий «Holy 85% reduction!».

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

В недавнем посте с критикой Go, который был выдан за перевод, пользователь tucnak, помимо избыточной фамильярности в адрес Роба Пайка, поднял несколько интересных моментов языка. Поскольку формат статьи предполагал, увы, не желание разобраться в теме, а разжечь холивары, предлагаю в этой статье пройтись по озвученным «проблемам» и понять, о чём же речь на самом деле, и что же заставляет современные компании выбирать Go.

Перевод статьи Роба Пайка из официального блога Go о автоматической кодогенерации с помощью go generate. Статья немного устарела (была написана перед выходом Go 1.4, в котором и появился go generate), но хорошо объясняет суть работы go generate.

(Перевод статьи из официального блога Go)

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

if err != nil {
    return err
}

появляется слишком часто. Недавно мы просканировали все open-source проекты, которые мы только смогли найти и увидели, что этот сниппет появляется лишь раз на страницу или две, гораздо реже, чем многие могли бы подумать. И всё же, если впечатление того, что вы должны всегда писать

 if err != nil

остается, значит, очевидно, что-то тут не так, и мишенью оказывается сам Go.

Это неверно, это вводит в заблуждение и это легко исправить. Наверное происходит следующее — программист, знакомясь с Go, задаёт вопрос — «Как я должен обрабатывать ошибки?», заучивает этот паттерн и тут и останавливается. В других языках, это может быть блок try-catch или другой механизм обработки ошибок. Соответственно, думает программист, там где я бы использовал try-catch в моём старом языке, в Go я просто напечатаю if err != nil. Со временем, в Go коде накапливается много таких сниппетов, и результат выглядит неуклюже.

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

(Перевод статьи с советами о написании по-настоящему кросс-платформенного кода в Go)
Go великолепно приспособлен для работы с разными платформами. Моя основная среда разработки на Windows, но я всегда работаю с Linux-системами. Поэтому я естественным образом пытаюсь избегать вещей, которые могут создать проблемы.



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

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

Недавно я перевёл великолепную статью Роба Пайка «Ошибки это значения», которая не получила должной оценки на Хабре. Что неудивительно, поскольку была размещена в официальном блоге Go и рассчитана на Go программистов. Впрочем, суть статьи не всегда сразу очевидна и опытным программистам. И всё же, я считаю её посыл ключевым для понимания подхода к обработке ошибок в Go, поэтому постараюсь объяснить его своими словами.

Я хорошо помню своё первое впечатление от прочтения этой статьи в момент её выхода. Это было примерно следующее: «Странный пример тут выбран — очевидно же, что с исключениями код будет лаконичней; выглядит как попытка оправдаться, что и без исключений можно как-то сократить». При том что я никогда не был фанатом исключений, пример, который рассматривается в статье, прямо напрашивался на это сравнение. Что хотел сказать Пайк фразой «ошибки это значения» было не очень ясно.

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