Go *

Как мы перешли с 30 серверов на 2: Go

Когда мы выпустили первую версию IronWorker около 3 лет назад, она была написана на Ruby, а API было написано на Rails. Через некоторое время нагрузка стала быстро расти и мы быстро достигли предела возможностей наших Ruby приложений. Короче говоря, мы перешли на Go. И если вы хотите узнать подробности — продолжайте читать…

CDN-провайдер CloudFlare в прошлом году разработал протокол Railgun для сжатия сетевого трафика. Бинарный протокол, написанный на языке программирования Google Go, передаёт хэши веб-страниц и diff’ы между ними, с поддержкой версионности. После внедрения этой технологии степень сжатия в некоторых случаях достигает 99.6%, что недостижимо с помощью gzip. Сайты 4Chan и Imgur после внедрения Railgun сократили некэшируемый трафик примерно на 50%.

Сейчас компания CloudFlare объявила, что поддержка протокола реализована также у Amazon Web Services и около 30 крупнейших хостинговых компаний. Поставить Railgun теперь как никогда просто: есть плагины для WordPress, Joomla, Drupal и прочих CMS, выпущены пакеты для большинства популярных дистрибутивов Linux и BSD.

Каждый раз когда речь заходит о Go приходится слышать один и тот же вопрос:

Является ли Go объектно-ориентированным языком?

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

У меня — 'cd'.

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

Но должны же быть решения!

В моей любимой оболочке zsh есть такая возможность — «разворачивание» путей по нажатию : например, "/u/in/sy" -> "/usr/include/sys/"

В остальных оболочках можно приноровиться и использовать $CDPATH или pushd/popd, но лично мне это до сих пор кажется неудобным.

А еще есть пара утилиток для ускоренной навигации. Самая известная из них, пожалуй, autojump. Она следит в каких папках пользователь проводит больше всего времени и позволяет указывать только фрагмент пути к папке. Например "incl" приведет вас в "/usr/include", если вы там часто бываете.

Autojump вдохновила другого разработчика на создание утилиты "z". "Z" использует в качестве критерия для перехода т.н. "frecency" - комбинацию частоты посещений папки (frequency) и времени последнего перехода туда (recency).

Обе утилиты хороши по-своему, и я так бы и пользовался autojump или z, однако что-то мне не давало покоя. А недавно я услышал одну фразу:

If the product is used as a tool, its interface should be as unintelligent as
possible. Stupid is predictable; predictable is learnable; learnable is usable.

И тут я понял что самое время придумать свой велосипед. Не-intelligent. Тупой и удобный.

Я снова вернулся к любимой задаче для освоения новых языков. После написания движка для блога на Go, захотелось снова поразмять пальцы, болезный TCP/IP proxy/debugger теперь написан на Go.

Вкратце, TCP/IP proxy — это программа, которая умеет принимать соединения и «пробрасывать» их на указанный адрес. Попутно ведутся логи переданных данных. Это очень удобно при отладке различных самодельных сетевых протоколов.

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

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

Я люблю писать тексты, люблю отлаживать примеры, пробовать, анализировать. Чего я не люблю, так это возиться с форматированием, закачиванием картинок, проверкой верстки и т.д.

По причине лени я начал использовать Блогспот. Тут тебе и море шаблонов, виджеты всякие, мгновенная индексация Гуглом, статистика разная, с какого-то времени даже комментарии стали древовидные, и прочие свистелки. Ну все бы хорошо, но, увы, не предназначен редактор Блогспота для создания программистских постов. Когда надо вставлять код или таблицы разные, начинаются мучения. Например, для своего другого блога, не про программирование, Яйца всмятку, сэр!, «возможностей» Блогспота вполне хватает.

Еще мне хочется хранить оригиналы постов в нормальном, не в обгаженном HTML'ем виде. Получалось, что материалы по блогу раскиданы по компьютеру там и сям в нескольких копиях. Сначала ты просто пишешь текст в редакторе, только разбивая на абзацы, без ссылок и картинок, и в конце сохраняешь почти готовый документ. Потом начинается верстка в HTML, в процессе которой, помимо, собственно, HTML'я, делаются поправки в оригинальном тексте. При этом обновлять оригинальный файл уже лень, и по сути, он остается в «сыром» виде. А в «сухом» виде остается только HTML'ная помойка. Но это еще не конец истории. Часто уже после публикации замечаешь опечатку, лезешь в Блогспот и правишь прямо на странице. Опять, самый первый оригинал и его локальная об'HTML'ная версия остаются неисправленными. В итоге: актуальные версии постов находятся только на самом Блогспоте. Конечно, можно делать автоматизированный бэкап всего блога, но опять таки — все будет уже только в HTML'е.

Некоторое время назад я начал использовать ReST. Тут жизнь хоть как-то полегчала. ReST позволяет писать текст в уже более менее предсказуемой разметке (абзацы, ссылки, код), и затем из него генерируется HTML, который вставляется (опять таки вручную) в Блогспот. Попытки автоматизировать предварительный просмотр поста через googlecl фактически провалились. Опять оставалась проблема, когда после исправления опечатки на странице оригинальный документ в ReST устаревал. Кроме того, ReST не решал проблему картинок. Их надо было куда-то заранее выкладывать, чтобы можно было полностью сделать preview.

Не могу объяснить почему, но идея динамических движков типа Wordpress'а меня как-то пугала. Сама идея держать посты в базе данных мне кажется перебором.

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

Что за горутины?

Горутина (goroutine) — это функция, выполняющаяся конкурентно с другими горутинами в том же адресном пространстве.

Запустить горутину очень просто:
go normalFunc(args...)

Функция normalFunc(args...) начнет выполняться асинхронно с вызвавшим ее кодом.

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

Сколько вешать в граммах?

Чтобы было проще ориентироваться, рассмотрим цифры полученные опытным путем.

Abtin Forouzandeh обнаружил баг в реализации go для 32-хбитной платформы Windows. Простейшая программа запускается и тут же падает.

Вступление

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

Перевод статьи

Определенно одной из причин, почему людей привлекает язык Go, является первоклассный подход к параллелизму. Такие возможности как общение через каналы, легковесные процессы (goroutines) и их надлежащее планирование — не только являются родными для языка, но и интегрированны в него со вкусом.

Если вы послушаете разговоры в сообществе в течение нескольких дней, то велик шанс, что вы услышите, как кто-то с гордостью отметит принцип:

Не общайтесь с помощью разделяемой памяти, разделяйте память с помощью общения.

На эту тему есть запись в блоге, а также интерактивное упражнение (code walk).

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

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

Go4IT

Ранее в сериале: S01E01: Неуловимый Go

Теория заГовора.

Стоит ли растекаться мыслью по древу, погрязая в теологических спорах? Мы же взрослые люди — давайте достанем и измерим! Итак, не откладывая идею в долгий ящик, ставим понятные цели — создать за 48 часов «ХабрUp», способный привлечь внимание миллионной аудитории и, что само собой разумеется, выдержать нагрузку и принести прибыль.

Только таким способом я cмогу убедительно продемонстрировать лёгкость и применимость Go language для создания Web-проектов.

Тут ко мне возникнут два закономерных вопроса:
1. А не хитрожопый ли я Борис Бритва, желающий таким образом пропиарить новый стартап?
2. А не домашняя ли это заготовка, давно дожидавшаяся своей очереди в закромах?

За ответами на эти вопросы и за сутью проекта, извольте под кат, почтенные коллеги!

Неуловимый Go.

Помните анекдот про неуловимого Джо? Именно восклицанием «Да кому он нужен!», прозвучавшим в форме вопроса "ЗАЧЕМ?", был встречен на Хабре релиз первой стабильной версии GO 1.

Именно на этот вопрос я хочу ответить циклом статей, оформленных в необычном для Хабра формате — в виде пошаговой совместной разработки действующего веб-проекта — с живым обсуждением и добавлением функционала. А чтобы вдвойне оправдать внесение цикла ещё и в хаб «Высокая производительность», мы поставим перед собой задачу создать не просто «хомяка», а проект, который наглядно продемонстрирует habri et orbi способность выдерживать значительные естественные нагрузки.

Вместо аперитива: реализация простейшего динамического веб-приложения на языке Go работает в 5-20 раз быстрее аналогичной Python-реализации. И всего в два раза уступает скорости отдачи статики Nginx-ом.

В рамках этого проекта, помимо самого языка Go, мы косвенно затронем и другие (относительно новые) технологии веб-разработки — HTML5, CSS3, Redis, MongoDB. Также я постараюсь вытащить из закутков долговременной памяти некоторые из трюков в области безопасности и экономии на спичках, коих накопилось много за полтора десятка лет работы в этой области. Устраивайтесь поудобнее, запасайтесь терпением и кофе — под катом «много букв», а ведь это только вводная часть :)

Друзья!

В продолжении поста «Google выпустила финальную версию языка программирования Go 1» интерес получил логическое продолжение и наше робкое желание было услышано администрацией Хабра и с сегодняшнего дня у языка Go есть собственный блог хаб.

Пользуясь случаем, не могу не порекомендовать книгу «Learning Go»

Вчера стало известно о том, что поисковый гигант выпустил финальную версию языка программирования Go 1, анонс о котором появился в 2009 году. Загрузить бинарные дистрибутивы языка для Linux, FreeBSD, Mac OS и Windows можно здесь. Язык выпущен под лицензией BSD.

Язык Go1, согласно команде его разработки, представляет из себя «попытку объединить скорость разработки динамических языков, таких как Python, с производительностью и безопасностью компилируемых языков, таких как C или C++» Справедливости ради, один из инженеров Google, занимающихся новым языком, признаёт, что экосистема языка ещё развита недостаточно — отсутствует IDE и набор поставляемых библиотек не очень большой, но, тем не менее, компания активно работает над улучшением ситуации.

Введение

В этом посте мы рассмотрим производительность горутин (goroutine). Горутины — это нечто в роде очень дешевых и легковесных потоков. Больше всего, наверное, они похожи на процессы в Erlang.

Согласно документации мы можем использовать сотни тысяч горутин в наших программах. И цель статьи — проверить и конкретизировать это.

Update (22.07.2013)

С момента изначального написания статьи многое изменилось. Я немного обновил пост, чтобы в сети не висела устаревшая инструкция.

Вместо вступления

Если кто не знает, Go (www.golang.org) – компилируемый язык программирования. Как и все хочет быть «лучше чем C». Разработку языка поддерживает Google (создатели языка — Rob Pike, Robert Griesemer и Ken Tompson), но Go — полностью open-source, в разработке принимает участие большое количество людей не из Google. Меня язык заинтересовал своей простотой и необычным подходом к ООП и многопоточности. Захотелось попробовать. Моя рабочая OS — Windows и будучи разбалованным платформой .Net, C# и Visual Studio мне было трудно именно начать. Хотя на самом деле это оказалось совсем просто, и достаточно быстро я настроил себе удобный Environment, состоящий, по сути, из IDE с подобием IntelliSense. О том, как это сделать за 15 минут я и хотел бы рассказать.