Иногда вещи находят себе применение неожиданно и не в том, для чего их задумывали.
В 1960-е годы Кен Томпсон легенда программирования написал компьютерную игру Space Travel для операционной системы Multics. Система была проектом компании Bell Lab, где он работал вместе с Денисом Ритчи. Позже проект закрыли, и чтобы продолжать играть в свою Space Travel, Томпсон решил портировать ее на компьютер PDP-7. Инструменты, которые он создал для порта, затем легли в основу операционной системы Unix.
Томпсон написал в одиночку первые три версии. Для Unix был нужен системный язык так появился B. Позже Денис Ритчи, коллега и друг Томпсона, подхватил разработку и написал язык C. Вот так в основе почти всего, на чем построены современные технологии, лежало желание поиграть в компьютерную игру и пет-проекты для забавы.
Кен Томпсон построил блестящую карьеру исследователя в области computer science. В середине 2000-х он устроился в Google, где вместе с Робом Пайком и Робертом Грейсмером создал Golang один из самых популярных языков последнего времени.
Go придумывали как простой язык для всего
К тому времени Google уже разрастался в гигантскую корпорацию, начинались проблемы со скоростью разработки. Там было очень много кода на C++, поддерживать его становилось все труднее. Задача, которую себе поставила компания, казалась почти наивной изобрести очень простой язык, на котором можно будет делать очень сложные вещи.
Мы все сошлись на том, что ненавидим C++, и решили, что ни одна фича не попадает в язык, пока каждый из нас троих не будет убежден в ее необходимости и тогда язык не обрастет лишним мусором, появившимся непонятно зачем.
Кен Томпсон
Создатели хотели решить проблемы медленной сборки программ, неконтролируемых зависимостей, сложной разработки инструментов и проблем межъязыкового взаимодействия. За основу языка они взяли C, Pascal и Oberton и попытались собрать из них все лучшее. В итоге они стали делать язык с очень простым синтаксисом, строгой статической типизацией, автоматической сборкой мусора и простыми средствами для управления многопоточностью.
Golang анонсировали в 2009 году, в 2012 состоялся релиз. Язык быстро стал набирать популярность, но и сталкивался с критикой. Ключевую фишку языка простоту многие разработчики посчитали и главным минусом.
Из-за стремления к простоте в Go отсутствуют конструкции, которые в остальных языках воспринимаются как что-то естественное. Вначале это может показаться хорошей идеей, но на практике выходит многословный код, писал Гэри Уилоуби. Go был разработан, чтобы быть простым, и он преуспел в этой цели. Он был написан для слабых программистов, используя в качестве заготовки старый язык. Поставляется он в комплекте с простыми инструментами для выполнения простых вещей. Его просто читать и просто использовать. Он крайне многословный, невыразительный и плох для умных программистов.
Но такая критика была и не совсем критикой для создателей языка. Сам Роб Пайк описывал язык почти также, но в отличие от критиков, не говорил о невыразительности как о чем-то плохом:
Ключевой момент здесь, что в гугле работают не исследователи. Они, как правило, молоды, идут работать после учебы, где, возможно, изучали Java, или C/C++, или Python. Они не смогут сразу разобраться в навороченном языке, но в то же время мы хотим, чтобы они создавали хорошее ПО. Именно поэтому язык должен быть прост для понимания и изучения.
Тем не менее, уже в 2012 году многие разработчики увидели перспективы Go в тех областях, для которых его изначально не задумывали. В своем твиттере Дерек Коллисон писал:
* Прогноз: в течение следующих двух лет Go станет доминирующим языком для IaaS, PaaS и оркестрации.
Так и произошло почти в то же время, когда создавали язык, в IT начала стремительно развиваться культура DevOps, в которой Go почти сразу стал стандартом.
19% в DevOps планируют использовать Go в
будущем, около 10% уже используют Go
DevOps придумывали как agile для инфраструктурщиков
Долгие годы в цикле разработки ПО царила строгая иерархия программисты писали код, системные администраторы следили, чтобы написанное нормально работало на железе каждый отвечал только за свою область. Когда где-то всплывали баги, начиналась битва профессий. Программисты утверждали, что проблема где-то на серверах и это не их дело; администраторы уверяли, что с серверами все отлично, просто на них положили кривой код.
Рано или поздно ошибку устраняли (или нет), и все начиналось заново.
Но в индустрии все очень быстро менялось, она росла страшными темпами. Сокращалось время доставки фич до пользователей, количество постоянных обновлений увеличивалось, сама неопределенность разработки продуктов становилась более явной некоторые вещи буквально собирали и дорабатывали на ходу регулярными апдейтами.
В таких условиях разобщенность отделов начинала сильно вредить, и даже существующий почти десять лет agile манифест неопределенности и гибкости не особо помогал.
В 2008 году администратор баз данных Патрик Дебуа поехал на конференцию Agile Toronto, где познакомился с другим админом Андрю Клэй Шафером. Оба интересовались аджайлом и тем, как бы получше внедрить его в сисадминское дело. На той же конференции они увидели выступление, где один из спикеров говорил, как в его команде разработчики и админы пытаются работать вместе.
Из всех этих дискуссий Дебуа и Шафер вынесли идею провести отдельную конференцию, посвященную только этим вопросам.
В то время еще не было термина Devops была только идея. Я написал в твиттере, что было бы здорово провести конференцию в Европе и обсудить саму идею. Agile System Administrators так себе название для мероприятия, поэтому мне предложили назвать его DevOpsDays с этого и началось движение Devops.
Через год конференцию провели в Бельгии. Буквально сразу название стало именем нового подхода к работе, который за несколько лет перевернул представление о ролях разработчиков и администраторов в IT.
Суть была такова разработчики участвуют в деплое, администраторы пишут скрипты, все автоматизируется. С этого начался не только сдвиг в философии и отношению к ролям в команде, но и софтверные изменения. Новая практика требовала новых инструментов. Docker, Kubernetes, Terraform и прочие вещи, которые сейчас плотно ассоциируются с работой девопс-инженера появились на этой волне. И почти все они были написаны на Go.
Почему Go и DevOps идеально подошли друг другу
Когда в Google начали разрабатывать Kubernetes у команды уже накопилось огромное наследие инструментов для контейнеризации. Но Кубер начали писать с нуля, поэтому встал вопрос выбора языка. Джо Беда, основной разработчик сервиса, рассказывал, что в Гугле используются многие языки не только свои разработки и они выбирали между С/С++, Java и Python.
Си не взяли, потому что это довольно пугающий язык для многих разработчиков, который оброс колоссально огромной инфраструктурой. Сообществу все труднее и труднее договориться, что, где и как правильно использовать.
Java не подошла, потому что разработчики стремились сделать установку простой на как можно более широком количестве платформ. Python откинули из-за динамической типизации.
А вот Go по словам Беды был и не слишком высокоуровневым, и не слишком низкоуровневым. Список причин, почему команда Kubernetes выбрала его, довольно широк:
-
Все библиотеки есть из коробки почти для всего, что им было нужно.
-
Быстрые инструменты. С ними мы подсели на скорость разработки, пишет Беда.
-
В Go не бывает сложного кода. Никто не пишет на нем фабрики фабрик. Понять любую часть системы, просто пробежавшись по ней взглядом, вполне реально.
-
Анонимные функции.
-
Сборка мусора, о которой не надо задумываться.
-
Строгая типизация.
Но это плюсы для разработки инструмента. Когда обычные девопс-инженеры рассказывают, почему Go стал стандартом в их области, чаще всего называют
Три основные причины
-
Его реально очень просто учить и читать. Многие и разработчики, и девопсы говорят, что достаточно прочитать общую документацию, чтобы идти и использовать код на продакшене без особых проблем.
-
У него самая простая для использования многопоточность. Горутины и Каналы фичи, которые хвалят даже те, кто невзлюбил Go.
-
Он невероятно прост в эксплуатации. И это, пожалуй, главная причина, почему язык так хорош для инфраструктурных инженеров.
По сравнению с Python, Ruby или Node.js, установка единственного исполняемого файла мечта инженеров по эксплуатации. Конечно, это вовсе не такая большая проблема с учетом все более широкого использования Docker, но отдельные исполняемые файлы еще и уменьшают размер контейнеров, пишет Сильвиан Валлез.
Исходный код компилируется в бинарный файл. Из-за этого при деплое приложения не надо заранее устанавливать необходимые зависимости, можно просто переносить и запускать, где угодно.
Что вы сами думаете про Go? Как и почему используете? Заходите к нам в сообщество там мы постоянно разбираем различные проблемы и задачи из сферы Devops, обсуждаем вещи, которые пригодятся и на собеседованиях, и в работе.
