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

Преамбула от переводчика: Это достаточно вольный перевод пусть и не самой свежей (июнь 2013 года), но доходчивой публикации о новом планировщике параллельных ветвей исполнения в Go. Достоинством этой заметки есть то, что в ней совершенно просто, «на пальцах» описывается новый механизм планирования для ознакомления. Тем же, кого не устраивает объяснение «на пальцах» и кто хотел бы обстоятельного изложения, рекомендую Scheduling Multithreaded Computations by Work Stealing — 29 страниц изложения со строгим и сложным математическим аппаратом для анализа производительности, 48 позиций библиографии.

Введение

Одной из наибольших новинок в Go 1.1 стал новый диспетчер, спроектированный Дмитрием Вьюковым (Dmitry Vyukov). Новый планировщик дал настолько разительное увеличение производительности для параллельных программ без изменений кода, что я решил написать что-нибудь об этом.

Многие пользуются Slack, Twitter и видели такие штуки:

Как это работает и как такое сделать самим?

Финализаторы

Когда сборщик мусора Go готов собрать объект, оставшийся без ссылок, предварительно вызывается функция, называемая финализатором. Добавить такую функцию к своему объекту можно при помощи runtime.SetFinalizer. Посмотрим на него в работе:

Бенчмарки

Бенчмарки это тесты для производительности. Довольно полезно иметь их в проекте и сравнивать их результаты от коммита к коммиту. В Go есть очень хороший инструментарий для написания и запуска бенчмарков. В этой статье я покажу, как использовать пакет testing для написания бенчмарков.

Под катом — перевод статьи опытного разработчика о его опыте практического применения Go. Важно — мнение переводчика может не совпадать с мнением автора статьи.

Менеджер многопоточных закачек на GO.

http://loafter.github.io/godownloader/
https://github.com/Loafter/godownloader

Вступление

Давным-давно, в году этак 1998, для выхода в интернет я использовал модем на работе у отца. Он его включал вечером после работы и я мог наслаждаться просторами сети интернет на скорости аж 31.2 кбит/c. В то время не было истеричных блогеров, страницы не весили по мегабайту, а в новостных сайтах говорили только правду. Естественно основной интерес представляли ресурсы. Картинки, программы, всякие дополнения к играм, вроде машинок. Как сейчас помню качать через IE было сущим адом. Скачать файл весом больше 500 кб было просто невозможно, древний осел был намного упрямей.

Немножко про каналы, про выполнение в основном процессе, про то как вынести блокирующие операции в отдельную горутину.

• Каналы и пустое значение
• Односторонние каналы
• Выполнение в основном треде ОС
• Вынос блокирующих операций

Если что, это вольный перевод статьи из блога Jeremy Mikkola.

Эта статья о том, как некоторое время спустя я распробовал и таки полюбил язык Go (аки golang).

Жалобы

Еще год назад у меня было полно жалоб на тот или иной аспект Go. В основном я жаловался на то, что при том, что ты не можешь использовать Go как «настоящий системный язык» (в плане написать-на-нем-операционку), тебе все равно приходится думать о том, о чем обычно приходится думать в системных языках: например, использовать тут указатель или нет. Система типов лежит в непродуктивном ущелье между достаточной строгостью, чтобы стать «автоматичной» (привет адептам Haskell!) и достаточной динамичностью, чтобы не отвлекать (как в Python). Какое-то время я тупил на таких вещах, как проход по юникодовой строке не символами, а байтами, и всякое такое. Я обвинял Go в том, что он так-то не всегда следует своему принципу простоты, так как в нем есть много разных узких штук, вроде make(). И конечно же я жаловался на то, что при работе с Go постоянно приходится повторять блоки if err != nil { return err }.

Поначалу я точно не мог назвать себя фанатом Go.

В техническом плане я согласен с тем, что большинство моих жалоб корректны. Я согласен с тем, что систему типов можно было бы придумать и покруче, а от указателей не помешало бы немного абстрагироваться. Но как только я начинаю понимать, что (не все, но многие) проблемы, на которые я жаловался, на самом деле вроде как даже и не непрягают. В действительности это напоминало нытье на целый лес, из-за пары некрасивых деревьев. В повседневном использовании языка большинство вещей, о которых я так волновался, вообще не давали о себе знать. Я ни разу не встречал баг, так или иначе связанный с проходом по строке. В реальном коде ты почти не кастишь interface{} так часто, как хотелось бы тем ребятам, которые дрочат на системы типов. Ах да, нет беды в том, чтобы вызывать make() в одном месте и new() в другом. Больше всего я ругался на те архитектурные решения языка, которые усложняли создание абстракций. Ты не можешь просто так сделать структуру данных, которая станет альтернативой к встроенным структурам данных (привет кодогенерации!). Без обобщений ты не сможешь строить большие обобщенные абстракции. Скорее всего, это сделано намеренно.

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

С выходом Go 1.5 появилась возможность делать go library для сторонних программ на других языках. То есть можно написать package который делает что то интересное и тяжело или просто уже готовое решения и подключить его в другую не Go программу. Это может быть C, android, objective C and etc. Я покажу как это легко можно подключить к Ruby.

Здравствуйте, меня зовут Юрий Насретдинов, я работаю старшим инженером в Badoo. За последние полтора года я сделал несколько докладов на тему того, как работает наше облако. Слайды и видео можно посмотреть тут и тут.

Сегодня настало время рассказать о ещё одной части этой системы — о сборщике логов, который мы вместе с этой статьей выкладываем в open-source. Основная часть логики нашего облака написана на языке Go, и эта подсистема не является исключением.
Исходные коды системы: github.com/badoo/thunder
В этой статье я расскажу вам о том, каким образом мы доставляем логи приложений в нашем облаке, которое мы называем просто «скриптовым фреймворком».

Логи приложений

Наши приложения, запускаемые в облаке, представляют из себя классы на PHP, которые в простейшей реализации имеют метод run() и получают на вход данные задания, например, число от 1 до N, где N — максимальное число экземпляров для этого класса. У каждого задания есть свой уникальный id, и конечной целью является доставка логов в какое-то централизованное хранилище, где можно будет легко найти логи как конкретного запуска, так и все логи класса сразу.

Перевод блог-поста главного автора сборщика мусора в 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!».

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

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

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

Если вы последний год пользовались мобильными приложениями от ВКонтакте (пусть даже не официальными), то этот материал раскроет немного данных по тому, как у нас это время работают пуш уведомления. Пушилка реализована на языке Go, и рассылает до 9 миллиардов пушей в сутки на четыре целевых платформы: GCM, APNS, MPNS, WNS.

В этом посте решил рассказать об общей архитектуре пушилки, проблемах и их обходе, нагрузках и производительности решения. Много букв и мало кода.

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

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

Сегодня, 19 августа 2015, проект Go с гордостью представляет Go 1.5 — шестой стабильный релиз языка Go.



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

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

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

Перевод статьи инженера компании AeroFS о переводе их микросервис-архитектуры с Java на Go.

TLDR; Портировав некоторые наши микросервисы с Java на Go, мы уменьшили использование памяти на несколько порядков.

В начале была Java

Архитектура AeroFS Appliance состоит из многих микросервисов, и подавляющее большинство из них написаны на Java. Это никогда не создавало нам проблем, вся система обслуживает тысячи пользователей от разных клиентов без каких-либо проблем с производительностью.

Это перевод блогпоста Сау Шон Чанга. В первой половине описывается его подход к созданию фотомозаики на Go, а во второй половине ускоряется выполнение программы за счёт добавления конкурентности (каналы, горутины).
По неточностям перевода пишите в личку.

Несколько месяцев назад мой хороший друг Сатиш Талим предложил отличную идею — создать несколько соревнований на Go, чтобы прокачать умения Go программистов. Идея проекта — каждый месяц (или около того) придумывать программерскую задачку, которая будет представлять собой свежий и интересный вызов для Go сообщества. Победители получат призы, но более важно, что это попытка помочь друг другу и себе в частности. Сатиш попросил меня придумать задание и я с удовольствием его придумал для третьего соревнования (challenge #3).

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