Зависимости. Дженерики. Они часто звучат в списке проблем в Go сообществе, но есть одна проблема, о которой вспоминают довольно редко — организация кода вашего пакета.

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

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

Перевод познавательной статьи "Golang: channels implementation" о том, как устроены каналы в Go.

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

Устройство канала

Давайте начнём с разбора структуры канала:

Сегодня, 16 августа 2016, вышел восьмой стабильный релиз языка программирования Go — Go 1.7. Как обычно, релиз выпущен по намеченному плану, через пол года после предыдущего, и в нём нет обратно несовместимых изменений. В тоже время, в Go 1.7 довольно много новых и важных изменений, уменьшены время компиляции и размеры бинарников, увеличена скорость работы и в стандартную библиотеку наконец-то добавлен пакет context. Под катом более подробный обзор новшеств и нововведений.

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

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

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

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

Go является языком программирования, хорошо приспособленным для работы с байтами. Будь у вас списки байт, потоки байт или просто отдельные байты, в Go легко с ними работать. Это примитивы, на которых мы строим наши абстракции и сервисы.

Пакет io является одним из самых фундаментальных во всей стандартной библиотеке. Он предоставляет набор интерфейсов и вспомогательных функций для работы с потоками байтов.

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

интервьюер: Приветствую, хотите кофе или что-нибудь еще? Нужен перерыв?

я: Нет, кажется я уже выпил достаточно кофе!

интервьюер: Отлично, отлично. Как вы относитесь к написанию кода на доске?

я: Я только так код и пишу!

интервьюер: ...

я: Это была шутка.

интервьюер: OK, итак, вам знакома задача "fizz buzz"?

я: ...

интервьюер: Это было да или нет?

я: Это что-то вроде "Не могу поверить, что вы меня об этом спрашиваете."

интервьюер: OK, значит, нужно напечатать числа от 1 до 100, только если число делится нацело на 3, напечатать слово "fizz", если на 5 — "buzz", а если делится на 15, то — "fizzbuzz".

я: Я знаю эту задачу.

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

я: ...

интервьюер: Вот маркер и губка.

я: [задумался на пару минут]

интервьюер: Вам нужна помощь, чтобы начать?

я: Нет, нет, все в порядке. Итак, начнем с пары стандартных импортов:

import numpy as np
import tensorflow as tf

интервьюер: Эм, вы же правильно поняли проблему в fizzbuzz, верно?

я: Так точно. Давайте обсудим модели. Я думаю тут подойдет простой многослойный перцептрон с одним скрытым слоем.

• в чем отличие от интерфейсов в Java
• важные и неочевидные последствия этих отличий
• как устроены интерфейсы под капотом
• вспомним про пустой интерфейс (interface{})
• затронем сакральную тему про дженерики
• разберемся, кто и зачем должен создавать интерфейс
• и постараемся научиться не абьюзить интерфейсы и начать жить

Initech ищет опытного Разработчика, готового присоединиться к нашей команде.

Задачи
— Разработка ядра системы и компонентов бекенда
— Анализ и улучшение эффективности, масштабируемости и стабильности различных ресурсов системы

Требования
— Магистр в Computer Science или смежной области
— 2+ года опыта в Java
— Эксперт в реляционных базах данных и оптимизации запросов в MySQL

• Don't communicate by sharing memory, share memory by communicating.
• Concurrency is not parallelism.
• Channels orchestrate; mutexes serialize.
• The bigger the interface, the weaker the abstraction.
• interface{} says nothing.
• Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.
• A little copying is better than a little dependency.
• Cgo is not Go.
• Clear is better than clever.
• Reflection is never clear.
• Errors are values.

Учтите, язык объективно очень плохо спроектирован. [...] И, при этом, Go гораздо более популярен, чем Haskell, если верить GitHub. При этом, уже столько отличных проектов, написанных на Go, вроде Docker, InfluxDB, etcd, Consul, Prometheus, packer и других.