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

Детали под катом.

Привет, Хабр! Предлагаю вашему вниманию перевод статьи основателя сервиса Meetspaceapp Nick Gauthier «Building Minimal Docker Containers for Go Applications».

Время чтения: 6 минут

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

Часть 1: Наше «приложение»

Для тестирования нам потребуется какое-нибудь маленькое приложение. Давайте будем фетчить google.com и выводить размер HTML.

package main

import (
    "fmt"
    "io/ioutil"
    "net/http"
    "os"
)

func main() {
    resp, err := http.Get("https://google.com")
    check(err)
    body, err := ioutil.ReadAll(resp.Body)
    check(err)
    fmt.Println(len(body))
}

func check(err error) {
    if err != nil {
        fmt.Println(err)
        os.Exit(1)
    }
}

Если мы запустимся, то получим только какое-то число. У меня вышло около 17К. Я целенаправленно решил использовать SSL, но причину объясню позднее.

Вредные советы для Go-программиста

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

Как и во всех культурах, у разработки программного обеспечения есть свои легенды, истории, которые пересказываются у кулера для воды. Все мы слышали о разработчиках, которые вместо того, чтобы сосредоточиться на создании качественного продукта, зацикливаются на защите собственной работы от посторонних. Им не нужен поддерживаемый код, потому что это означает, что другие люди смогут его понять и доработать. А возможно ли такое на Go? Можно ли сделать код на Go настолько сложным? Скажу сразу – дело это непростое. Давайте рассмотрим возможные варианты.

Вредные советы для Go-программиста



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

• Плохо названные и организованные пакеты
• Неправильно организованные интерфейсы
• Передача указателей на переменные в функции для заполнения их значений
• Использование паники вместо ошибок
• Использование init-функций и пустого импорта для настройки зависимостей
• Загрузка файлов конфигурации с использованием init-функций
• Использование фреймворков вместо библиотек

Большой клубок зла

Что будет, если собрать все наши злые практики вместе? У нас получился бы фреймворк, который использовала бы множество файлов конфигурации, заполнял поля структур с помощью указателей, определял интерфейсы для описания публикуемых типов, опирался на «магический» код и паниковала всякий раз, когда возникала проблема.

И я сделал такой. Если вы зайдете на https://github.com/evil-go, вы увидите Fall (падение), — DI фреймворк, дающий возможность внедрять любые «злые» практики, которые только захотите. Я спаял Fall с крошечным веб-фреймворком Outboy, который следует тем же принципам.

Вы можете спросить, насколько они злодейские? Давайте посмотрим. Предлагаю пройтись по простой программе Go (написанной с использованием лучших практик), которая предоставляет http endpoint. А затем перепишем ее, используя Fall и Outboy.

Несмотря на мой статус и очевидную предвзятость как одного из создателей D, я постараюсь отвечать откровенно; Я следовал путям Go и Rust, и я абсолютно точно знаю, где стирают грязное белье в D. Я поощряю людей на аналогичных позициях в сообществах Rust и Go чтобы и они делились своим мнением. Так вот.

Для начала, где то в вопросе должен фигурировать и C++. Должен ли он быть заменен вместе с С, или же он один из кандидатов на замещение С, но в любом случае С++ это ключевой элемент уравнения. Это ближайший язык к С и очевидный шаг вперед. Учитывая возраст С++, я в дальнейшем полагаю в этом вопросе что С++ вместе с С является целью для замены.

Привет, Хабр! представляю вашему вниманию перевод статьи «Go, gRPC and Docker» автора Mat Evans.

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

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

Что такое Makefile-ы?

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

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

Если вы используете Go для создания веб-сервисов, то Makefile поможет решить следующие задачи:

• Автоматизация вызова простых команд, таких как: compile, start, stop, watch и т. д.
• Управление специфичными для проекта переменными окружения. Он должен подключать файл .env.
• Режим разработки, который автоматически компилируется при изменении.
• Режим разработки, который показывает ошибки компиляции.
• Определение GOPATH для конкретного проекта, чтобы мы могли хранить зависимости в папке vendor.
• Упрощенный мониторинг файлов, например, make watch run = «go test. / ...»

Неожиданное поведение приложения в отношении работы с базой приводит к войне между DBA и разработчиками: DBA кричат: «Ваше приложение роняет базу», разработчики — «Но ведь до этого всё работало!». Хуже всего, что DBA и разработчики не могут помочь друг другу: одни не знают про нюансы работы приложения и драйвера, другие не знают про особенности, связанные с инфраструктурой. Было бы неплохо такой ситуации избежать.

Надо понимать, часто недостаточно полистать go-database-sql.org. Лучше вооружиться чужим опытом. Еще лучше, если это будет опыт, полученный кровью и потерянными деньгами.

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

Go вышел 10 ноября 2009-го. Меньше чем через сутки появился первый комментарий про дженерики. В нём также упомянуты исключения, которые мы добавили в язык в виде паники и восстановления (panic and recover) в начале 2010-го.

За три года наблюдений отсутствие дженериков всегда входило список трёх главных проблем, которые необходимо исправить в языке.

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

1. Человеческим языком объяснить, что такое интерфейсы.
2. Объяснить, чем они полезны и как вы можете использовать их в своём коде.
3. Поговорить о том, что такое interface{} (пустой интерфейс).
4. И пройтись по нескольким полезным типам интерфейсов, которые вы можете найти в стандартной библиотеке.

Всем привет! Меня зовут Максим Рындин, я тимлид двух команд в Gett – Billing и Infrastructure. Хочу рассказать про продуктовую веб-разработку, которую мы в Gett ведем преимущественно на языке Go. Я расскажу, как в 2015-2017 годах мы переходили на этот язык, почему вообще его выбрали, с какими проблемами столкнулись во время перехода и какие решения нашли. А о текущей ситуации расскажу уже в следующей статье.

Для тех, кто не знает: Gett — это международный сервис заказа такси, который был основан в Израиле в 2011 году. Сейчас Gett представлен в 4 странах: Израиль, Великобритания, Россия и США. Основные продукты нашей компании — это мобильные приложения для клиентов и водителей, веб-портал для корпоративных клиентов, где можно заказать машину, и еще куча внутренних админок, через которые наши сотрудники настраивают тарифные планы, подключают новых водителей, мониторят случаи мошенничества и многое другое. В конце 2016 года в Москве открылся глобальный офис R&D, который работает в интересах всей компании.

Всем привет! Cегодня делимся заключительной частью перевода статьи «Что есть и чего нет в Go». Напоминаем, в первой части речь шла о элементах, которые есть в Go, сегодня же поговорим о том, чего в Go нет.

Перевод данного материала подготовлен в преддверии старта нового потока по курсу «Разработчик Golang».

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

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



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

Перед прочтением: Выше приведен отрывок из книги Алан А. А. Донована и Брайана В. Кернигана «Язык программирования Go». страница XIV. Пункты, упомянутые ниже, являются кратким и несколько неполным объяснением терминов, используемых при проектировании языка программирования. Я попытался объяснить все концепции с точки зрения программирования на Go. Все пункты, упомянутые ниже, не моего авторства, они взяты из других выдержек. Я никоим образом не защищаю Go или любой другой язык.

Перевод статьи подготовлен специально для студентов курса «Разработчик Golang», занятия по которому начинаются уже сегодня!

---

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

В этой статье мы рассмотрим их различия и реализации в Go.

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

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

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

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

Мы берём Go, начинаем писать конкурентный код. Конечно, ожидаем, что легко сможем обуздать мощь каждого ядра нашего процессора. Так ли это?

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

Видео с конференции GopherCon Russia

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

А еще я хотел бы пригласить вас на Golang Conf 2019, которая пройдет 7 октября в Москве. Я член программного комитета конференции, и мы с коллегами выбрали много не менее хардкорных и очень, очень интересных докладов. То, что я люблю!

Под катом передаю слово автору.

pprof — основной инструмент профилирования в Go. Профилировщик включен в стандартную библиотеку Go и про него, за годы, написано уже очень много. Чтобы подключить pprof в существующее приложение нужно просто добавить одну строчку кода:

import _ “net/http/pprof”

В HTTP-сервере по-умолчанию — net/http.DefaultServeMux — по пути /debug/pprof/ будут зарегистрированы обработчики, отдающие результаты профилирования.

curl -o cpu-profile.pb.gz http://<server-addr>/debug/pprof/profile

(подробнее см. https://godoc.org/net/http/pprof)

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

Как я писал в предисловии предыдущей статьи, я нахожусь в поисках языка, в котором я мог бы писать поменьше, а безопасности иметь побольше. Моим основным языком программирования всегда был C#, поэтому я решил попробовать два языка, симметрично отличающиеся от него по шкале сложности, про которые до этого момента приходилось только слышать, а вот писать не довелось: Haskell и Go. Один язык стал известен высказыванием "Avoid success at all costs"*, другой же, по моему скромному мнению, является полной его противоположенностью. В итоге, хотелось понять, что же окажется лучше: умышленная простота или умышленная строгость?

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

Мы обещали 5-6 причин перейти на Go, так и получилось! На GolangConf — конференции полностью посвященной Go — 7 октября будет 5 докладов с пометкой «Переход на Go» для тех, кто только собирается или начинает использовать этот язык в своих проектах.

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



В программе конференции 21 доклад, сессия блиц-докладов и митапы. В любое время гости конференции смогут выбрать из 3–4 разных тем и найти для себя что-нибудь интересное. Думаю даже, что более актуальной будет проблема выбора и невозможность разорваться между потоками (хорошо, что потом все будет на видео). Одновременно в разных залах будут обсуждаться темы, актуальные самым разным специалистам.