Go

Go 1.21, gonew и lego

Evrone digest — Tue, 15 Aug 2023 10:15:52 +0000

В этом выпуске рассказываем про нововведения в языке Go, экспериментальную утилиту gonew, позволяющую создавать проект из шаблона, и альтернативную реализацию клиента Certbot.

Вышел Go 1.21

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

В Go 1.21 появилось три новых фичи. Первая добавляет функции min и max, вычисляющие наименьшее и наибольшее значение фиксированного числа аргументов упорядоченного типа. Гораздо проще объяснить, как это работает, на примере кода:

var x, y int m := min(x) // m == x m := min(x, y) // m is the smaller of x and y m := max(x, y, 10) // m is the larger of x and y but at least 10 c := max(1, 2.0, 10) // c == 10.0 (floating-point kind) f := max(0, float32(x)) // type of f is float32 var s []string _ = min(s...) // invalid: slice arguments are not permitted t := max("", "foo", "bar") // t == "foo" (string kind)

Вторая фича добавила универсальный «ластик», функцию clear. Она отлично справляется с двумя вещами: стирает всё содержимое из ассоциативных массивов (карт) или обнуляет все элементы среза. Учтите, что если карта или срез nil, то clear не работает.

Третья фича — изменённый алгоритм инициализации пакетов. Теперь процесс инициализации сортирует все пакеты по пути импорта и итеративно повторяет это действие, пока список пакетов не опустеет. Вначале система находит первый пакет, для которого импорты инициализирован, затем инициализирует его и удаляет из списка. Учтите, что это может повлиять на поведение некоторых приложений, которые полагаются на определённый порядок инициализации.

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

Это наиболее важные изменения релиза. Чтобы узнать подробности и ознакомиться с полным списком изменений, рекомендует прочитать примечания к выпуску Go 1.21.

Приложения из шаблонов

Любой писатель, хотя бы раз в жизни, сталкивался со страхом чистого листа. Открываешь текстовый редактор, заносишь руки над клавиатурой… и пустота. Ни мыслей, ни идей. Разработчики тоже довольно часто испытывают нечто подобное, когда создают новый проект.

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

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

Сразу оговоримся, что это пока только прототип, имеющий минимальную функциональность. Пощупать его своими руками можно после установки:

$ go install golang.org/x/tools/cmd/gonew@latest

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

Чтобы создать проект по заданному шаблону достаточно вызвать gonew с двумя аргументами: путь к шаблону и имя модуля создаваемого проекта:

$ gonew golang.org/x/example/helloserver example.com/myserver $ cd ./myserver

Разработчики просят сообщать обо всех найденных ошибках, чтобы сделать работу gonew лучше и удобнее.

Конструктор LeGo

На Go делается много крутых и интересных приложений. Одно из них, библиотека lego, выполняющее сразу две полезных функции: ACME (Automatic Certificate Management Environment) библиотека и удобный клиент для сервиса Let’s Encrypt. Он полностью написан на Go и распространяется в виде исходников, предварительно скомпилированных пакетов и в виде Docker-контейнера.

Краткая справка от Капитана Очевидность про Let’s Encrypt. Эта компания взяла на себя благородную миссию сделать современный интернет более защищённым и стала выдавать бесплатные TLS-сертификаты для сайтов. Имея такой сертификат, выпущенный центром сертификации Let’s Encrypt, для любого веб-сайта можно включить защищённый HTTPS-протокол и получить заветный символ закрытого замка в адресной строке.

Это означает, что даже если трафик между узлами будет перехвачен злоумышленниками, то использовать они его не смогут. Весь передаваемый трафик шифруется криптографическими ключами, взлом которых, даже на современном железе, займёт тысячи лет. Звучит здорово, но теперь поговорим об ограничениях. Поскольку Let’s Encrypt бесплатен, сертификаты выдаются на ограниченное количество времени (90 дней). Если сертификат истёк, то его нужно перевыпустить.

Для работы с Let’s Encrypt был разработан клиент Certbot. С помощью него можно полностью контролировать процесс выпуска и перевыпуска сертификатов. Его активно применяют для автоматизации процесса, чтобы админам не приходилось вручную обновлять сертификаты каждые 90 дней. Certbot представляет собой реализацию ACME протокола, упомянутого выше. Альтернатив достаточно много, список доступен на сайте проекта.

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

Митапы

Онлайн

Go meetup

8 ноября 2023

Осенью у нас запланирован Go Meetup. Программа мероприятия формируется, но регистрация уже открыта. Кстати, вы уже можете подать доклад прямо в режиме онлайн. Заявки на участие спикера принимаются до 15 октября.

Интересуетесь нашими мероприятиями? В Telegram-канале Evrone meetups мы выкладываем анонсы с подробными описаниями докладов, а также студийные записи прошедших митапов. Тем для кого выступать в новинку, мы оказываем всяческую поддержку и помогаем оформить экспертизу в яркое выступление. Подписывайтесь и пишите @andrew_aquariuss, чтобы узнать подробности.

Регистрация

Вакансии

Удаленка / Офис

Evrone

Мы открыты для новых Go-разработчиков. В Evrone можно работать удалённо с первого дня, мы поддерживаем и оплачиваем участие в Open-source проектах и выступления на конференциях, а расти в грейдах можно с помощью честной системы проверки навыков и менторства.

Подробнее

Вечеринка гоферов

Evrone digest — Fri, 14 Jul 2023 11:16:47 +0000

Отвлекитесь от абстракций. Сегодня мы поговорим, как извлекать данные об оборудовании с помощью ghw, делать запросы в генеративные нейросети OpenAI и даже скачивать себе на компьютер больше оперативной памяти… серьёзно!

Читаем состав

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

Давайте отвлечёмся от привычного и посмотрим на небольшую библиотеку ghw (Golang HardWare). Её задача: определение и проверка работы оборудования. Она полностью поддерживает операционные системы Windows и Linux, а также частично macOS. Часть функций ghw работает без root-привилегий. Если какую-то часть информации считать не удалось, то библиотека не станет генерировать ошибку, а всего лишь выдаст warning message. Кстати, эти сообщения можно отключить через переменную окружения.

Скажем сразу, что ghw не годится на роль системного монитора. Если надо собирать и анализировать метрики, вам подойдёт самый обычный Prometheus. Библиотека gwh нужна, чтобы собирать подробную информацию обо всех возможностях оборудования хоста. В качестве источников данных используются штатные утилиты операционной системы. Так, например, в Linux для получения информации о CPU используется /proc/cpuinfo, а для расширенных данных о сетевых адаптерах — ethtool.

Вот пример запроса данных об установленных процессорах:

package main import ( "fmt" "math" "strings" "github.com/jaypipes/ghw" ) func main() { cpu, err := ghw.CPU() if err != nil { fmt.Printf("Error getting CPU info: %v", err) } fmt.Printf("%v\n", cpu) for _, proc := range cpu.Processors { fmt.Printf(" %v\n", proc) for _, core := range proc.Cores { fmt.Printf(" %v\n", core) } if len(proc.Capabilities) > 0 { // pretty-print the (large) block of capability strings into rows // of 6 capability strings rows := int(math.Ceil(float64(len(proc.Capabilities)) / float64(6))) for row := 1; row < rows; row = row + 1 { rowStart := (row * 6) - 1 rowEnd := int(math.Min(float64(rowStart+6), float64(len(proc.Capabilities)))) rowElems := proc.Capabilities[rowStart:rowEnd] capStr := strings.Join(rowElems, " ") if row == 1 { fmt.Printf(" capabilities: [%s\n", capStr) } else if rowEnd < len(proc.Capabilities) { fmt.Printf(" %s\n", capStr) } else { fmt.Printf(" %s]\n", capStr) } } } } }

Пример вывода:

cpu (1 physical package, 6 cores, 12 hardware threads) physical package #0 (6 cores, 12 hardware threads) processor core #0 (2 threads), logical processors [0 6] processor core #1 (2 threads), logical processors [1 7] processor core #2 (2 threads), logical processors [2 8] processor core #3 (2 threads), logical processors [3 9] processor core #4 (2 threads), logical processors [4 10] processor core #5 (2 threads), logical processors [5 11] capabilities: [msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt aes lahf_lm pti retpoline tpr_shadow vnmi flexpriority ept vpid dtherm ida arat]

Получаемые данные можно сериализовать двумя способами: превратить в JSON или YAML. Для этого предусмотрены методы JSONString() и YAMLString(). Ещё одна полезная фича — возможность создания снапшотов. Работает она пока только с Linux, а снапшоты представляют собой частичные копии деревьев /proc и /sys. В снапшот включаются только те данные, которые могут быть сняты при помощи ghw.

Играем с OpenAI

Только ленивый сейчас не говорит о продуктах OpenAI. Эта компания изначально была некоммерческим проектом, а ныне объединила усилия с Microsoft и получила от них внешнее финансирование. Множество разработок OpenAI уже были представлены общественности. Среди них чат-бот ChatGPT, генеративная нейросеть DALL-E, система распознавания голоса Whisper и большие языковые модели (LLM) GPT-3 и GPT-4.

OpenAI даёт доступ к своим продуктам через собственное API и предоставляет документацию, позволяющую создавать приложения на их основе. Но вместо того, чтобы каждый раз создавать собственную «обёртку»‎, проще ‎воспользоваться готовой. Такой как go-openai, содержащей неофициальные клиенты OpenAI API. Устанавливается стандартно, через go get:

go get github.com/sashabaranov/go-openai

Прежде чем использовать go-openai, нужно получить ключ доступа к API. Для этого надо зайти по адресу https://platform.openai.com/account/api-keys, cоздать аккаунт и сгенерировать секретный ключ на странице управления доступом. Помните, что ключ относится к чувствительным данным и его нельзя раскрывать третьим лицам. Теперь можно выполнять запросы, например:

package main import ( "context" "fmt" openai "github.com/sashabaranov/go-openai" ) func main() { client := openai.NewClient("your token") resp, err := client.CreateChatCompletion( context.Background(), openai.ChatCompletionRequest{ Model: openai.GPT3Dot5Turbo, Messages: []openai.ChatCompletionMessage{ { Role: openai.ChatMessageRoleUser, Content: "Hello!", }, }, }, ) if err != nil { fmt.Printf("ChatCompletion error: %v\n", err) return } fmt.Println(resp.Choices[0].Message.Content) }

Жонглируем оперативной памятью

Помните знаменитое высказывание Билла Гейтса про то, что 640 КБ ОЗУ хватит всем? Шутить над ним, на самом деле, начали ещё до капитальных изменений порядка доступа к памяти в Windows NT. Чтобы запускать сложные приложения или игры, приходилось задействовать расширители памяти, вроде CWSDPMI. Это позволяло обходить существующие ограничения и использовать всю доступную оперативную память.

Когда приложение не помещается в RAM, задействуется swap. Традиционно это файл или отдельный раздел на локальном дисковом накопителе. Без этого приложение прекратило бы работу, выдав ошибку. Размер swap-раздела может быть любым, но на практике он ограничивается объёмом локального диска. Недостатком swap на диске можно считать большое значение latency, в тысячи раз медленнее, чем с обычной ОЗУ. Концепция «всё есть файл» в Linux позволяет обойти и это ограничение, выполняя хранение данных swap не на локальном накопителе, а примонтировав часть оперативной памяти с другой машины.

В основе проекта ram-dl лежит go-nbd, серверная часть и клиентская библиотека для управления сетевыми блочными устройствами. Объединив это с r3map, библиотекой монтирования и миграции оперативной памяти, получаем уникальный инструмент, позволяющий расширить swap до любого размера. Это может пригодиться в разных сценариях: от тестирования до запуска специализированных приложений.

Выглядит монтирование RAM следующим образом: на удалённой системе запускается серверная часть, которая резервирует участок памяти и делает его доступным по fRPC. Клиентская часть изменяет поведение команд mkswap, swapon и swapoff, заворачивая их на fRPC-бекэнд. На скоростных линиях связи производительность такого трюка будет сравнима с производительностью локального накопителя.

Интересно посмотреть

Пропустили наш предыдущий митап? Не страшно! Видеозаписи докладов уже выложены на нашем YouTube-канале в кинематографическом качестве 4K и со студийным звуком.

Подписывайтесь и ставьте 🔔колокольчик, чтобы получать уведомления о будущих трансляциях и видео! А ещё присоединяйтесь к Telegram-каналу и будьте в курсе всех наших будущих мероприятий.

Митапы

Онлайн

Go meetup

13 сентября 2023

Регистрация

Вакансии

Удаленка / Офис

Evrone

Подробнее

Ископаемые реликвии

Evrone digest — Tue, 20 Jun 2023 10:42:39 +0000

Сегодняшний выпуск мы посвятили улучшению поддержки Go в мейнфреймах IBM, скриптовому языку Tamarin и проверке адресов электронной почты. Усаживайтесь поудобнее, наливайте чай и доставайте печеньки. Приятного чтения!

Go на z/OS

Поговорим о священном граале — мейнфреймах. Если спросить далёкого от этой темы человека, что такое мейнфрейм, то услышим что-то вроде: «Ну это такой очень большой и мощный сервер». Это верное определение, но вообще не дающее представления, насколько это производительная штука.

Мейнфрейм жрёт невероятное количество электроэнергии и имеет внутри запредельное количество ресурсов. Как вам цифра в 200 ядер процессора собственной разработки с тактовой частотой 5.2 ГГц и 40 ТБ оперативной памяти? Речь о мейнфрейме IBM z16 построенном на чипах IBM Telum и представленном в 2021 году.

Кому нужны эти проприетарные динозавры, стоящие до $4 млн за штуку да ещё и с помесячной оплатой за процессорное время? Ответ прост: банкам, биржам, крупным производствам, телекоммуникационным компаниям и государственным ведомствам (по сути всем, кому нужна высочайшая надёжность, отказоустойчивость и безопасность).

Мейнфреймы — это даже не пресловутые «пять девяток» аптайма. У них «семь девяток», то есть 99.9999999% или максимум 3 секунды простоя в год. Заявляются такие SLA, как 9 мс на обработку транзакции. Вспомните об этом, когда будете платить за кофе банковской карточкой. За эти 9 мс платёжная система успеет проверить, что ваша операция не содержит признаков фрода и завершит транзакцию.

Ещё мейнфреймы — это про обратную совместимость. Она возведена в абсолют настолько, что софт, созданный 30 лет, спокойно запустится и на современном мейнфрейме. Вот мы и подошли к новости, ради которой пришлось написать столь длинное вступление. IBM сообщила о выходе Open Enterprise SDK для Go 1.20. В нём есть инструмент, позволяющий автоматически портировать исходники Go для запуска на мейнфреймах под управлением z/OS.

Prometheus для z/OS желаете? Легко! Перенести собственное приложение? Тоже не составит труда. Делается это с помощью утилиты Wharf с открытым исходным кодом. Да, да… вы не ослышались – консервативный гигант уже второй год подряд пополняет свой репозиторий ZOSOpenTools и прилагает усилия чтобы как можно больше разработчиков смогли портировать свои приложения на z/OS.

Портирование с Wharf выглядит весьма удобным. Инструмент создаёт отдельное рабочее пространство (workspace) и начинает исследовать код, выявляя участки, которые точно сломаются при сборке на z/OS. Найденные ошибки Wharf автоматически исправляет, расставляет, где нужно, тег «zos» и заносит все сделанные изменения в лог. Есть также ручной режим, позволяющий самостоятельно принимать решение о внесении изменений.

Автоматическое портирование иногда не срабатывает. Система умеет решать большинство рутинных задач, но если сталкивается с неразрешимой проблемой, то передаёт управление пользователю. Так что какие-то пакеты придётся портировать ручками. Несмотря на это, инструмент выглядит логичным и правильным шагом к дальнейшему развитию экосистемы z/OS. Так что Go-разработчикам стоит учитывать, что их приложения могут быть перенесены на мейнфреймы IBM.

Tamarin 2.0.0 Alpha

Множество волшебных сказок имеют один и тот же сюжет: «Поди туда — не знаю куда, принеси то — не знаю что». Разработчика этим не напугать, ведь они привыкли создавать то, чего ещё нет. Так произошло и с Tamarin – скриптовым языком для проектов на Go. В нём автор реализовал всё то, чего в Go не было и появиться в обозримом будущем вряд ли могло.

Началось всё с книги Writing An Interpreter In Go, которую написал software-инженер Торстен Болл (Thorsten Ball). В ней он рассказывает, как с нуля разработать свой язык программирования. На примере абстрактного Monkey programming language он последовательно демонстрирует, как без сторонних библиотек разобраться с абстрактным синтаксическим деревом, лексическим анализом и парсингом. Задумка отличная: пока решаешь конкретные задачи, начинаешь понимать процессы на более низком уровне.

История умалчивает, как эта книга попала к автору Tamarin, Кёртису Мизи (Curtis Myzie). Но в ней он явно увидел способ запилить собственный «обезьяний» язык. Название «Tamarin» было выбрано не случайно, поскольку это маленькие прикольные приматы из семейства игрунковых. В этом скриптовом языке было реализовано много фишек из других языков, таких как Rust и Python. Вот пример кода, фактически смеси из Go и Python, с пайпами и обращением к частям стандартной библиотеки Go:

array := ["gophers", "are", "burrowing", "rodents"] sentence := array | strings.join(" ") | strings.to_upper print(sentence)

Этот код выводит фразу:

GOPHERS ARE BURROWING RODENTS

Первая версия работала достаточно медленно. Но автор Tamarin подумал о производительности, спросите вы? Нет, просто у Торстена Болла вышла ещё одна книжка Writing A Compiler In Go, а за ней случились и доработки.

В июне 2023 увидела свет альфа-версия Tamarin v2.0.0, которая обзавелась компилятором и одноимённой виртуальной машиной. За счёт этого удалось добиться радикального увеличения производительности. Tamarin v2 даже в альфа-версии работает в 127 раз быстрее, чем v1. Описанные в книге методы сработали идеально.

Боимся предположить, что произойдёт, если Торстен Болл выпустит книгу «Becoming a Dark Lord in Go» 😀

Верификация email без отправки писем

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

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

Но как только начинаешь изучать RFC, открываются врата ада. Спецификация одобряет различную экзотику, до которой обычному пользователю додуматься сложно. Самый простой пример: по RFC пробел в адресе — это нормально. Например, вот такой адрес формально соответствует спецификации:

"Jane Doe"@example.com

Если бы Джон Коннор был ирландцем, то вполне возможно завёл бы себе почтовый адрес с апострофом (но без кавычек), строго по RFC:

John.O'Connor@example.com

И это лишь начало спуска в кроличью нору. В 2014 году на Хабре была прекрасная статья на эту тему.

Переходим ко второму акту Мерлезонского балета, а именно к проверке адреса на существование. Здесь используется сразу несколько приёмов:

lookup через SMTP;
проверка MX-записей в DNS;
валидация через бесплатных email-провайдеров;
проверка не является ли адрес одноразовым (Disposable Email Address).

И тут, наконец-то, станет полегче. Чтобы не изобретать велосипед, Go-разработчикам возьмите на вооружение библиотеку email-verifier. В ней уже реализованы все вышеперечисленные способы проверки. Так что вылезайте из кроличьей норы, а в освободившееся время заглядывайте на наш YouTube-канал.

Немного IT

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

Выпуски длятся 50-70 минут, а значит можно совместить какие-нибудь скучные занятия с обучением. Отличная возможность погрузится в нюансы Go, стоя в пробке или проезжая очередную станцию метро!

Ну а если вам есть что сказать — добро пожаловать в комментарии!

Митапы

Онлайн

Go meetup

13 сентября 2023

Регистрация

Вакансии

Удаленка / Офис

Evrone

Подробнее

Модульный монолит

Evrone digest — Thu, 18 May 2023 11:59:10 +0000

В нашем майском Go-дайджесте мы задумались о низкоуровневых задачах и собственном Git-сервере с блэкджеком и хуками. А ещё изучили подходы к структурированию проектов на Go и нашли слово moduliths в словаре Google.

Пишем бутлоадер

Иногда мы слышим, что на Go пишут хипстеры, а чтобы создать что-то значимое, нужен язык C. Аргументируют так: Windows, Linux и macOS написаны на C, а ваш этот новомодный Go годится лишь для высокоуровневых вещей. Сегодня постараемся опровергнуть это.

Любые персональные компьютеры имеют BIOS или UEFI в качестве базовой микропрограммы. они взаимодействуют с железом на самом низком уровне, а также передают управление загрузчику операционной системы. Сложность заключается в том, что обе этих системы не совместимы друг с другом. Благо, существует универсальный загрузчик GRUB, который совместим и с BIOS, и c UEFI.

Портировать его на Go будет сложно по множеству причин. Первое, что приходит на ум — стандарт мультизагрузки требует размещения специальной структуры в первых 4 Kб бинарника. Но у Go бинарник даже в пустом виде будет весить 5 Kб. Альтернативой GRUB могут быть BOOTBOOT и Limine. Они не поддерживают старые 32-битные ядра, но с современными 64-битными никаких сложностей нет. При этом оба умеют запускать бинарники в формате ELF c нативной поддержкой go build (через настройку GOOS=linux).

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

func _start(){ // Code goes here for { /* loop forever */ } }

Вроде бы всё просто и с помощью флага -E можно добиться желаемого. Но сразу же появляется проблема. Что Limine, что BOOTBOOT требуют специального формата ELF-бинарника. Этот формат создаётся с помощью скриптов компоновщика… которые компоновщик Go не поддерживает.

Придётся прибегнуть к хитрости и скрестить ежа с ужом, то есть стандартный Go-компилятор со сторонним компоновщиком (например, из GCC). Опустим процесс установки GCC для разных архитектур и операционных систем, сосредоточившись на подключении компоновщика:

-ldflags="-linkmode external \ -extld x86_64-elf-ld \ -extldflags '-nostdlib -n -v -static -m elf_x86_64 -T link.ld'"

Это лишь начало сложного и долгого пути. Если вам интересно узнать, как разобраться с cgo, что такое прагмы и какой недокументированный флаг надо передать при сборке, то все ответы вы найдёте в статье Writing an OS in Go: The Bootloader.

Self-hosted GIT

Причин завести свой небольшой клон Github может быть много. Это удобно, позволяет самостоятельно контролировать свои данные. Можно получить независимость от конкретного поставщика сервиса, но продолжать пользоваться базовыми возможностями Git.

Сначала подумайте, нужен ли вам self-hosted вообще? За сохранность данных вы отвечаете самостоятельно, но и обслуживание, поддержка сервера также становится вашей задачей. Для обеспечения защиты от несанкционированного доступа потребуется регулярно обновлять программное обеспечение. Ну а чтобы предотвратить потерю данных в случае сбоя, регулярно делать резервные копии.

Но давайте всё-таки о том, как без особых усилий такой локальный Git создать. На помощь приходят те же ребята, которые создали BubbleTea и Wish. Мы рассказывали об этих инструментах в одном из прошлых дайджестов. Их Git-сервер называется Soft Serve и прекрасно работает прямо из командной строки:

Весь Git-сервер представляет собой один бинарник, который после запуска создаёт директорию data, где будет хранить репозитории, ключи и базу данных. При первом запуске потребуется определить переменную окружения SOFT_SERVE_INITIAL_ADMIN_KEYS. Любой ключ, добавленный в эту переменную, будет считаться ключом администратора и иметь полный набор разрешений для выполнения любых действий.

Используя эту переменную, Soft Serve создаст пользователя admin. Потом его можно будет переименовать или изменить настройки профиля. Также при первом запуске внутри директории data будет создан конфигурационный файл config.yaml с настройками сервера. Там можно кастомизировать базовые настройки, такие как используемые порты. Ну а управление репозиториями осуществляется из консоли с помощью команды repo.

Soft Serve имеет поддержку стандартных хуков git и кастомных хуков. Они могут работать глобально для всех репозиториев (удобно для выстраивания цепочек CI/CD) или быть заданы для конкретных репозиториев. По нашему мнению, это отличный инструмент, который достоин быть в арсенале разработчиков и DevOps-инженеров. А если хотите пощупать своими руками его текстовый UI, то просто подключитесь к демонстрационной версии по SSH:

ssh git.charm.sh -t soft-serve

В поисках лучшей структуры

Если о своём опыте рассказывают международные компании, такие как HUMAN Security, обычно это попадает в best practices. Недавно в блоге израильского software-инженера Авива Карми (Aviv Carmi) были выложены две части статьи, посвящённых поиску лучшей структуры для проекта на Go. Это вторая серьёзная попытка выбрать подход к структурированию кода. Первая была сделана 4 года назад и изложена в статье OK Let’s Go: Three Approaches for Structuring Go Code.

Если времени читать нет, то суть сводится к тому, что есть три основных подхода:

Single Package — вся кодовая база лежит в одной директории, никаких отдельных пакетов не создаётся.
Coupled Packages — разбиваем код на пакеты, единолично отвечающие за некоторое определённое поведение. Пакеты взаимодействуют друг с другом и знают друг о друге. Гарантируется, что каждая часть логики полностью реализована в отдельном пакете.
Independent Packages — полностью независимые пакеты, которые, как и в предыдущем подходе, взаимодействуют друг с другом, но ничего не знают друг о друге. Для каждого сервиса пакет объявляет собственный интерфейс.

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

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

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

Третий же подход Independent Packages тоже годится, а благодаря полной независимости пакетов, компоненты можно безопасно переносить или копировать между проектами. Ценой станет необходимость написания и поддержки большего количества интерфейсов.

В HUMAN Security решили остановиться на Coupled Packages. Спустя несколько лет написания проектов на основе этого подхода провели ретроспективный анализ и осознали, что это было хорошее, но не лучшее решение. Детали вы найдёте в первой и второй частях оригинальной статьи.

Фреймворк Service Weaver

Забавную попытку усидеть на двух стулья сразу сделала Google, выпустив фреймворк Service Weaver. Представьте, что вы разрабатываете приложение так, словно оно монолит, но при этом у вас есть магическая кнопка, позволяющая распределить его по кластеру микросервисов. Они даже термин соответствующий придумали — moduliths, сокращение от слов modular monoliths. По замыслу авторов такая штука заполнит пробел между монолитом и микросервисами.

На бумаге всё выглядит замечательно. Фреймворк оперирует компонентами, которые могут взаимодействовать друг с другом, но при этом очень мало знают друг о друге. Чем-то напоминает отношения покупателей и продавцов на Авито. Обычный интерфейс Go становится контрактом компонента, например:

type Reverser interface { Reverse(context.Context, string) (string, error) }

При этом у каждого компонента есть одна или несколько реализаций:

//go:generate go run github.com/ServiceWeaver/weaver/cmd/weaver@latest generate type reverser struct { weaver.Implements[Reverser] } // Reverse is a concrete implementation of the Reverser interface func (r *reverser) Reverse(ctx context.Context, s string) (string, error) { // concrete implementation }

Здесь видно встраивание weaver.Implements[Reverser] в reverser. Может показаться, что нарушены все принципы интерфейсов, гласящие, что интерфейсы не должны знать друг о друге. Не всё так просто. В Service Weaver это служит триггером для генератора кода, который сделает основную магию. При запуске приложения (словно это монолит) он сделает локальную заглушку и привяжет Reverser к reverser конкретной реализации. Затем перенаправит все вызовы методов.

Когда мы захотим раскидать компоненты на микросервисы, вызов метода Reverse(...) из Reverser фактически превратится в цепочку:

сериализация ввода;
выполнение сетевого вызова;
десериализация на другой стороне;
выполнение действия;
возврат ответа по этой же цепочке.

Также будут инициализированы зависимости компонентов, то есть определённые локальные или сетевые прокси в зависимости от способа развёртывания. Таким образом, фреймворк Service Weaver — это гибрид из генератора кода, сетевого прокси и контейнера внедрения зависимостей (DI). Хотите узнать детали? Тогда советуем прочитать статью Преслава Рачева (Preslav Rachev) — Digging into Service Weaver: Dependency Injection.

Митапы

Онлайн

Go meetup

14 июня 2023

Совсем скоро мы встретимся на Go Meetup. Программа мероприятия формируется, но регистрация уже открыта. Кстати, вы уже можете подать доклад прямо в режиме онлайн. Заявки на участие спикера принимаются до 25 мая.

Регистрация

Вакансии

Удаленка / Офис

Evrone

Подробнее

Made in …

Evrone digest — Tue, 18 Apr 2023 09:41:16 +0000

В нашем сегодняшнем дайджесте не будет особенностей языка, библиотек и фреймворков. Предлагаем повысить насмотренность и взглянуть на приложения, созданные с помощью Go. В нашем меню: аналог MongoDB, приложение для превращения команд CLI в видео или гифку, а также порт модели LLaMa GPT.

FerretDB GA 1.0 released

«Свято место пусто не бывает» — эта поговорка актуальна во все времена. MongoDB создавалась как приложение с открытым исходным кодом, лицензируемым под GNU AGPL. Языковые драйверы распространялись по лицензии Apache. Инновация в чистом виде и одно из самых простых решений на рынке. MongoDB было легко использовать, она обладала качественной документацией и получила заслуженное внимание со стороны разработчиков.

Осенью 2018 года создатели MongoDB плотно занялись монетизацией своего продукта, отодвинув на задний план интересы сообщества open source. Copyleft-лицензия AGPL была заменена на SSPL, что сделало нецелесообразным создание DBaaS-версий MongoDB. Единственным вариантом оставалось приобретать коммерческую лицензию, что было невыгодно многим облачным провайдерам. Также они сделали собственную облачную версию MongoDB Atlas, работающую в рамках мультиоблака из AWS, Azure и GCP.

Естественной реакцией разработчиков открытого ПО стало создание полностью свободной альтернативы MongoDB. Проект получил название FerretDB. Он представляет собой stateless-прокси и преобразует протокол MongoDB в SQL, а в качестве движка использует PostgreSQL. Такая архитектура даёт совместимость с существующими драйверами MongoDB и позволяет использовать FerretDB в качестве полноценной замены. Это решение подойдёт и обычным пользователям, и облачным провайдерам для построения DBaaS-решений.

FerretDB создавался с упором на совместимость и производительность. Оригинальная MongoDB была разработана на «плюсах». FerretDB в качестве стека выбрал чистый Golang. Привычные инструменты, такие как mongosh, MongoDB Compass, NoSQL Booster или Mingo спокойно воспримут FerretDB и будут работать с ним, как с нативной инсталляцией MongoDB. Забавно, но гиганты вроде SAP сейчас работают над поддержкой FerretDB в HANA. Подробности читайте в блоге проекта.

CLI хоум видео

Создание визуальных материалов – это целое искусство. Особенно, если речь идёт о скучных командах консоли. Конечно, записать небольшой скринкаст и слепить из него гифку сможет любой технический писатель. Но хочется идеально, красиво и без запинок. Чтобы размер получившегося файла был адекватный, а качество приемлемым. К счастью, такой инструмент существует, называется VHS. Название полностью отражает смысл и воркфлоу. Вначале надо создать «кассету», затем записать на неё серию команд и пауз, вставить в проигрыватель и на выходе получить красоту.

Инструкция по установке VHS доступна в репозитории проекта на GitHub. Поддерживаются практически все операционные системы (Windows, Linux, macOS). Единственное, что слегка портит впечатление – приложение тянет за собой приличное количество зависимостей. Также VHS можно запустить внутри Docker-контейнера (сразу вместе со всеми зависимостями). После того, как VHS установлен, советуем сразу ознакомиться с коротким мануалом по командам:

vhs manual

Теперь можно приступать к подготовке нашей «кассеты». В Linux это будет выглядеть приблизительно так:

touch demo.tape nano demo.tape

Теперь вводим команды, по которым будет пробегать терминал, формируя нужную нам GIF. В начале файла задаём формат вывода и некоторые настройки, а только потом команды, например:

# Where should we write the GIF? Output demo.gif # Set up a 1200x600 terminal with 46px font. Set FontSize 46 Set Width 1200 Set Height 600 # Type a command in the terminal. Type "echo 'Welcome to VHS!'" # Pause for dramatic effect... Sleep 500ms # Run the command by pressing enter. Enter # Admire the output for a bit. Sleep 5s

Сохраняем эту последовательность и запускаем файл на рендер:

vhs demo.tape

Поскольку в качестве выходного файла мы задали наименование demo.gif, этот файл появится в папке, откуда мы делали вызов:

Таким образом можно «на лету» создавать учебные и иллюстрационные материалы для баз знаний и статей. Помимо создания файлов «кассет» вручную, можно воспользоваться записью команд:

vhs record > cassette.tape

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

Отдельно стоит отметить, что получаемые файлы будут очень небольшого размера. Гифка выше занимает всего 84 Кбайта. Поскольку VHS создан на Golang, его можно кастомизировать, как душа пожелает. Репозиторий открыт всем желающим, так что не поленитесь поставить «звездочку» и взять на вооружение этот прекрасный инструмент.

LLaMA GPT на Go

Большие GPT-модели совершили прорыв и теперь удивляют нас своими способностями. Проблема лишь в том, что запустить такую модель на обычном компьютере не выйдет. Речь даже не об одном GPU, а о кластере из GPU, который позволит загрузить всю модель в VRAM и уже после этого приступать к работе. Поэтому такие модели крутятся где-то в дата-центрах по всему миру, а мы покупаем к ним временный доступ. Но что если хочется локальное решение, пускай даже оно не будет идеальным?

Такое решение есть — LLaMA. Эта модель была представлена в феврале 2023 года, обучена на 20 языках и существует в четырёх версиях:

LLaMA-7B,
LLaMA-13B,
LLaMA-33B,
LLaMA-65B.

Цифра в названии означает количество параметров (в млрд). Изначально её хотели предоставлять исключительно научным и учебным организациям, но волей судеб слили на торренты. С тех пор она стала доступна всем желающим. Самый известный и часто упоминаемый порт был создан на чистом С/С++ болгарским программистом Георгием Гергановым (Georgi Gerganov). Познакомиться с исходным кодом можно в репозитории проекта.

Мечтой большинства ML-хакеров стало вникнуть в суть (на сленге это называется «грокнуть») больших языковых моделей, не тратя кучу денег, используя лишь простое оборудование. Идея отказа от GPU легла в основу порта llama.go, созданного программистом Сергеем Гоцуляком (Serge Gotsuliak).

Кросс-платформенность, поддержка всех существующих моделей LLaMA и первый стабильный релиз — всё это лишь начало пути. Дальше запланирована разработка чата в реальном времени (аля ChatGPT), автозагрузка конвертированных моделей весов из интернета, увеличение скорости за счёт поддержки инструкций AVX2 и INT8-квантование, дабы большие модели помещались в тот же объём памяти. Работы — непочатый край, так что не забудьте поддержать автора звёздочкой.

Митапы

Онлайн

Go meetup

14 июня 2023

Летом мы встретимся на Go Meetup. Программа мероприятия формируется, но регистрация уже открыта. Кстати, вы уже можете подать доклад прямо в режиме онлайн. Заявки на участие спикера принимаются до 25 мая.

Регистрация

Вакансии

Удаленка / Офис

Evrone

Подробнее

От простого к сложному

Evrone digest — Mon, 20 Mar 2023 14:10:10 +0000

В мартовском Golang-дайджесте расскажем, как удобно демонстрировать результаты работы заказчикам, создавая туннели в публичный интернет. Также рассмотрим легковесную альтернативу веб-фреймворку makaron, почитаем стайлгайд от Uber и узнаем, как ускорить отдельно взятую функцию, переписав её на языке ассемблера.

Пробиваем туннели

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

При разработке интеграции с внешними сервисами им тоже надо достучаться до рабочего компьютера, отправить или получить данные. Это сложно, поскольку в большинстве случаев разработчики выходят в сеть из-за NAT и не имеют статического IP-адреса. Это значит, что нужно сделать проброс портов (port forwarding) на маршрутизаторе, открыть порт файервола и стать клиентом сервиса, который будет актуализировать IP-адрес и привязывать к какому-либо домену (собственному или предоставляемому сервисом).

Такой набор действий может не сработать. Если вы сидите через мобильный интернет, то у вас будет серый IP без возможности подключения извне. Ваш рабочий ноутбук вполне может иметь ограничение на управление файерволом, исходя из принятой в компании политики безопасности. Да и время обновления DNS-записей (штатно до 24 часов) может стать проблемой, если надо «здесь и сейчас».

Одним из способов решения может быть аренда VDS со статическим IP, но это не всегда удобно. Получается, что либо разработку надо вести сразу там, либо тратить время на перемещение и запуск проекта на удалённом сервере. Куда проще воспользоваться сервисами, организующими туннель до вашего рабочего компьютера. Один из таких сервисов ngrok, реализует модель ingress-as-a-service. Минимальная команда для работы выглядит так:

ngrok http 80

Сервис выделит временный поддомен, который будет резолвиться сразу же, выполнит все необходимые действия по созданию туннеля через собственный промежуточный сервер. Таким образом мы избавляемся от всех проблем, связанных с пробросом портов, файерволами и NAT. Бонусом станет контроль трафика и его просмотр без отдельной настройки сниффера. Дополнительные плюшки в виде SSO, OAuth и SSL/TLS-сертификатов присутствуют.

Единственный недостаток — цена. Для некоммерческих проектов сервис предоставляется бесплатно и с ограниченным функционалом. Независимым коммерческим разработчикам или командам придётся разово выложить от $8 до $65 за лицензию плюс от $10 до $75 ежемесячно за обслуживание.

Если же у вас есть арендованный сервер и вы хотите получить selfhosted ngrok, то можно обратить внимание на проект pgrok. Его ещё называли ngrok для бедных (poor man's ngrok). Автор создал бесплатный сервис ejemplo.me, которым, к сожалению, воспользовались злоумышленники для распространения вредоносного ПО. Итог был предсказуем: домен заблокировали, а репозиторий теперь в архиве, в статусе read-only. Тем не менее, серверную часть pgrokd можно запустить на своём сервере и использовать клиент pgrok для доступа.

Аналогичный подход можно использовать с помощью проекта frp (сокращение от fast reverse proxy). Его преимущество в том, что он продолжает активно развиваться. Файерволы и NAT ему не помеха, дополнительные фичи, вроде аутентификации через OIDC-провайдера есть. Отдельно отметим хорошую документацию с примерами конфигурации.

Модульный фреймворк Flamego

Ненадолго поставим в сторону бокалы с gin и martini и взглянем на альтернативные веб-фреймворки. Наше внимание привлек Flamego, впитавший в себя идеи модульного фреймворка makaron, но этот легче и проще. Разработчики пожертвовали расширяемостью и получили много полезных бонусов.

Основное, чем может похвастаться Flamego — мощный синтаксис маршрутизации, опережающий всех конкурентов по экосистеме. Этот фреймворк не накладывает ограничений на внедрение промежуточного программного обеспечения и обеспечивает достаточно простую интеграцию с существующими Go-приложениями.

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

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

Есть у Flamego и очевидные недостатки. Этот веб-фреймворк использует собственный формат middleware, что делает невозможным многие полезные вещи. В частности, нельзя использовать официальные прослойки от Prometeus / Grafana или любого стандартного роутера, такого как chi. Ещё один минус — активное использование reflect не лучший выбор с точки зрения производительности.

Uber Go стайлгайд

В нашем мартовском Python-дайджесте мы рассказывали, что крупные компании вроде Google всё активнее делятся с сообществом собственными наработками. В частности, своими best practices, основанными на опыте использования разных языков программирования. Это позволяет значительно экономить средства на переделывание кода, написанного независимыми программистами для OSS-сообщества.

Советуем обратить внимание на руководство, созданное двумя Go-разработчиками из Uber. Они хотели улучшить продуктивность коллег при работе с Golang. Этот документ неоднократно дополнялся и теперь содержит множество советов и рекомендаций. Каждый пункт основан на опыте решения проблем экспертами, имеющими многолетний опыт работы с Go.

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

Авторы выработали аргументированное мнение, что штатные механизмы паники и восстановления не являются верной стратегией обработки ошибок. С их точки зрения, любой код в продакшене должен избегать паники, поскольку та может быть источником каскадных отказов. Если возникла ошибка, то её надо вернуть и дать таким образом с ней справиться. Паника — признак непоправимой ситуации. Это справедливо всегда, за исключением паники во время инициализации приложения.

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

Экстремальное ускорение

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

Но если нам надо ускорить какую-то одну определённую функцию, чтобы та работала существенно быстрее? Тут на ум приходит воспользоваться языком ассемблера и попробовать говорить с процессором на его языке. Один из пользователей Хабра проделал такой трюк и описал свой опыт.

Здесь стоит начать с дисклеймера — это вряд ли пригодится в реальной разработке. Ни о какой надёжности речи не идёт. Рассматривайте это, как любопытный эксперимент, не более. (прим. автора)

В качестве подопытного кролика была выбрана модифицированная функция Copy для решения задачи по спортивному программированию:

func Copy(srcRGBA, dstPaletted []uint8) { srcPtr := unsafe.Add(unsafe.Pointer(&srcRGBA[0]), 2) dstPtr := unsafe.Pointer(&dstPaletted[0]) for range dstPaletted { *(*uint8)(dstPtr) = *(*uint8)(srcPtr) dstPtr = unsafe.Add(dstPtr, 1) srcPtr = unsafe.Add(srcPtr, 4) } }

У Go есть полезный флаг компиляции -gcflags "-S", выводящий программу в виде кода на языке ассемблера. Чтобы упростить вывод, автор статьи задействовал флаг -B, отключающий проверку границ (Bounds Check). Вот та же самая функция Copy:

0x0000 00000 TEXT round-3/fastcopy.Copy(SB), NOSPLIT|ABIInternal, $0-48 0x0000 00000 MOVQ AX, round-3/fastcopy.srcRGBA+8(FP) 0x0005 00005 MOVQ DI, round-3/fastcopy.dstPaletted+32(FP) 0x000a 00010 FUNCDATA $0, gclocals·cNGUyZq94N9QFR70tEjj5A==(SB) 0x000a 00010 FUNCDATA $1, gclocals·J5F+7Qw7O7ve2QcWC7DpeQ==(SB) 0x000a 00010 FUNCDATA $5, round-3/fastcopy.Copy.arginfo1(SB) 0x000a 00010 FUNCDATA $6, round-3/fastcopy.Copy.argliveinfo(SB) 0x000a 00010 PCDATA $3, $1 0x000a 00010 ADDQ $2, AX 0x000e 00014 XORL CX, CX 0x0010 00016 JMP 33 0x0012 00018 MOVBLZX (AX), DX 0x0015 00021 MOVB DL, (DI) 0x0017 00023 INCQ CX 0x001a 00026 INCQ DI 0x001d 00029 ADDQ $4, AX 0x0021 00033 CMPQ SI, CX 0x0024 00036 JGT 18 0x0026 00038 RET

Было выбрано несколько направлений оптимизации.

Уменьшить количество чтений из памяти.
Уменьшить количество записей в память.
Выполнять операции с большим количеством данных за счёт AVX-инструкций.

Первое направление было выполнено чтением сразу 8 байт за раз, в то время как в оригинальном коде читался только 1 байт в регистр размером 8 байт. Полученный код был оптимизирован за счёт развёртки цикла, выполнения XORQ на первом шаге цикла и сборке 8 байт в регистр перед записью. Ну а вишенкой на торте стало задействование векторных инструкций. Суммарно все эти оптимизации смогли ускорить функцию почти в 10 раз.

Само же встраивание ассемблерной функции в Go-приложение выполняется элементарно. В код добавляется функция без тела, вида:

func CopyAsm(srcRGBA, dstPaletted []uint8)

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

Видеоподкаст про Go

Подкаст снимают и развивают двое наших коллег из Evrone. Они обсуждают его преимущества и недостатки, сравнивают с другими языками.

Ну а если вам есть что сказать — добро пожаловать в комментарии!

Митапы

Онлайн

Go meetup

26 апреля 2023

Уже совсем скоро мы встретимся на Go Meetup. Программа мероприятия формируется, но регистрация уже открыта. Кстати, вы уже можете подать доклад прямо в режиме онлайн.

Регистрация

Вакансии

Удаленка / Офис

Evrone

Подробнее

Обновление языка и телеметрия

Evrone digest — Tue, 14 Feb 2023 13:02:01 +0000

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

Hurrah, Go 1.20 is released!

Версия 1.20, вышедшая 1 февраля 2023 года, принесла 4 ключевых изменения. Она расширила возможности конвертации из слайса в указатель массива. Так что, имея слайс x, конструкцию *(*[4]byte)(x) теперь можно записать значительно проще — [4]byte(x).

Встроенный в язык пакет unsafe, позволяющий выполнять низкоуровневые операции с памятью, пополнился тремя новыми функциями:

SliceData,
String,
StringData.

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

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

Не забыли разработчики языка и об улучшении процесса сравнения. До выхода 1.20 правила сравнения были достаточно жёсткими. Они требовали явного соответствия по типу для корректной работы. Возьмём пример кода:

package main import "fmt" type mymap[K comparable, V any] map[K]V func _[P any, Q comparable]() { var _ mymap[any, string] // не сработает в старых версиях до 1.20 } func main() { fmt.Println("Hello, gophers!") }

Если запустить его, например, в версии 1.19, то получим ошибку вида:

./prog.go:8:14: any does not implement comparable Go build failed.

А вот в новой версии 1.20 функция отработает без каких-либо проблем.

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

Дизайн прозрачной телеметрии

Практически любой разработчик знает этот замечательный момент. Работа над релизом завершена, софт отправился пользователям. Но как узнать, что всё работает как надо? Как понять, что не возникает каких-либо нежелательных эффектов? В этом случае простых отчётов об ошибках и пользовательских отзывов будет недостаточно.

Даже незначительная разница между пользовательским устройством и средой, в которой разработчики выполняли тестирование, может стать причиной, по которой баг не был вовремя обнаружен. При масштабировании различия будут лишь увеличиваться. Без сбора и анализа телеметрии некоторые проблемы приложений выявить практически нереально.

Выбор телеметрии может быть сложным. Проекты с открытым исходным кодом предпочитают не собирать следы активности. Это помогает избежать необоснованных обвинений в сборе пользовательских данных. К тому же, собранные данные должны быть обезличены и их нужно где-то хранить.

Конечно, можно предпочесть стратегию «do nothing», но это лишь приведёт к существенному недостатку знаний. Как результат — ошибочные решения, которые никак не соотносятся с реальными потребностями пользователей.

Но есть и примеры успешного внедрения традиционной телеметрии. Звуковой редактор Audacity, платформа GitLab и пакетный менеджер Homebrew для macOS не скрывают, что собирают телеметрию. Те, кто работает в Visual Studio Code также не слишком сильно переживают по этому поводу, если верить опросу 2022 года от StackOverflow. Возможно, это сыграло свою роль и сделало VSCode лучше.

Расс Кокс (Russ Cox) за свою 16-летнюю карьеру в Google сделал вывод, что телеметрия особенно важна для проектов с открытым исходным кодом. Это позволяет избежать ситуаций, при которых разработчик не знает, как используется его софт и насколько хорошо он работает. В то же время те, кто разрабатывает проприетарное программное обеспечение используют сбор телеметрии на полную катушку.

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

Никаких псевдослучайных идентификаторов, IP-адресов или MAC-адресов. Разработчик может составить список значимых для него событий, а приложение будет вести учёт количества таких событий. В процессе отправки данных отчёт может включать интересующие значения счётчиков, версию ОС и архитектуру. Опционально могут быть добавлены данные о других инструментах, например версии локального компилятора.

Плюшевый гофер

Если вы хоть раз имели дело с Ruby, то знаете, что существует такой язык разметки, как eRuby. Эталонная реализация этого языка называется ERB и включена в стандартную библиотеку. С помощью ERB появляется возможность встраивать код на Ruby непосредственно в HTML-документ. Чтобы определить границы встраивания используются пары разделителей <% и %>. Таким образом, можно вычислять и подставлять значения сразу в HTML-шаблон. Можно ли провернуть такой трюк в Golang?

Посмотрите на механизм шаблонов Plush, входящий в состав фреймворка Buffalo. Его можно использовать в Go-приложениях отдельно от экосистемы Buffalo. Устанавливается Plush одной командой:

$ go get -u github.com/gobuffalo/plush

Синтаксис здесь очень похож на ERB. В частности, для динамического отображения содержимого используются разделители <%= и %>.

<%= "plush is great" %>  plush is great

Чтобы исполнить код, но не отображать его в шаблоне можно видоизменить разделители до <% и %>.

<% "plush is great" %>

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

Видеоподкаст про Go

Ну а если вам есть что сказать — добро пожаловать в комментарии!

Митапы

Онлайн

Go meetup

15 марта 2023

Уже совсем скоро мы встретимся на Go Meetup. Программа мероприятия формируется, но регистрация уже открыта. Кстати, вы уже можете подать доклад прямо в режиме онлайн. Заявки на участие принимаются до 1 марта.

Регистрация

Вакансии

Удаленка / Офис

Evrone

Подробнее

Архитектура и управление

Evrone digest — Wed, 18 Jan 2023 13:07:00 +0000

С наступившим, гоферы! Поговорим про чистую архитектуру и хороший код, взглянем на экспериментальную фичу по управлению памятью и узнаем про альтернативу традиционному OpenSSH-серверу.

Чистая архитектура

Умение адаптироваться к внешним условиям — важное условие разработки для бизнеса. Как только бизнес требует внести изменение, а разработчик начинает сомневаться, не сломает ли это какую-то функциональность — это хороший повод задуматься о переходе на чистую архитектуру. Это даст возможность организовать код так, чтобы не зависеть от используемых фреймворков, UI или баз данных. Бонусом станет предсказуемое поведение всех компонентов построенной системы.

Минусов у чистой архитектуры тоже достаточно. Необходимо соблюдать правила обмена данными между условными «слоями» приложения. Так что решение даже простых задач потребует написания большего количества кода. Проектировать взаимодействие модулей сложно. Это дополнительный барьер для внедрения чистой архитектуры.

Удобно иметь наглядный пример такой архитектуры, вроде проекта go-backend-clean-architecture. Это такой шаблон с заранее подобранными слоями и проверенными временем инструментами. Общая схема взаимодействия выглядит следующим образом:

В качестве инструментов для реализации этой схемы автор выбрал достаточно популярные пакеты:

gin — веб-фреймворк;
mongo go driver — коннектор для MongoDB;
jwt — аутентификация на основе токенов;
viper — загрузчик конфигурации;
bcrypt — хэш-функция формирования ключа;
testify — тестирование правильности работы кода;
mockery — фиктивная реализация интерфейсов.

Существует два варианта развёртывания шаблона: в Docker-контейнере и локально (требуется наличие установленного go и MongoDB). Документация для каждого из вариантов есть в репозитории проекта.

Если вы серьёзно задумались, как спроектировать приложение на чистой архитектуре, обратите внимание на книгу «Чистая архитектура. Искусство разработки программного обеспечения» Роберта Мартина. В ней освещены вопросы архитектуры и дизайна приложений. Это универсальные знания, которые будут полезны разработчикам, системным архитекторам и аналитикам данных.

Экспериментальная arena

Остаётся совсем немного времени до февральского релиза Go 1.20. Есть в нём одна интересная экспериментальная фича — арены памяти. Давайте кратко разберёмся, что это такое и зачем нужно.

Не секрет, что в Golang существует специфический garbage collector (GC). Именно он следит, чтобы приложение не упало, обожравшись памяти. Задумка была такая, чтобы разработчику в целом не приходилось заботиться о ручном управлении памятью.

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

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

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

Таким образом, вдобавок к стандартному GC, которым нельзя управлять вручную, появляется выделенная область, где обычные правила не действуют. Это даёт больше контроля, но и порождает целый пласт вопросов и проблем. Самый популярный вопрос — а в каких сценариях реально будет необходимость задействовать такой механизм?

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

Ну а проблемами здесь могут стать контроль за утечкой памяти и попытка чтения/записи в структуру на освобождённой арене. Предполагается, что в первом случае будут хорошо работать штатные механизмы профилирования. А для второго Address sanitizer и Memory sanitizer через go run -asan и go run -msan соответственно.

Альтернатива OpenSSH

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

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

Впрочем, можете самостоятельно подключиться к SSH-серверу git.charm.sh и проверить работу платформы. Используя связку из небольшого TUI-фреймворка BubbleTea и Wish, можно создавать красивые приложения, предназначенные для работы в терминальном режиме.

Автор платформы не стал изобретать велосипед и воспользовался готовой реализацией протокола от GliderLabs. Её писали в сотрудничестве с разработчиком знаменитого ssh-chat.

Видеоподкаст про Go

Видеоподкаст "Немного IT" снимают и развивают двое наших коллег из Evrone. Они обсуждают его преимущества и недостатки, сравнивают с другими языками. Выпуски длятся 50-70 минут, а значит можно совместить какие-нибудь скучные занятия с обучением. Отличная возможность погрузится в нюансы Go, стоя в пробке или проезжая очередную станцию метро! Ну а если вам есть что сказать — добро пожаловать в комментарии! Сайт проекта.

Митапы

Онлайн

Go meetup

15 марта 2023

Год только начался, а у нас уже запланирован Go Meetup, который пройдёт 15 марта 2023. Программа мероприятия формируется, но регистрация уже открыта. Кстати, вы уже можете подать доклад прямо в режиме онлайн. Заявки на участие принимаются до 1 марта.

Регистрация

Вакансии

Удаленка / Офис

Evrone

Подробнее

13 лет совершенствования

Evrone digest — Fri, 18 Nov 2022 12:05:51 +0000

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

Гофер-тинейджер

Наш гофер отпраздновал в ноябре своё 13-летие. По человеческим меркам это уже подросток, отказавшийся от прошлых убеждений и активно ищущий возможности развития. Релиз 1.18 поставил жирную точку в спорах про дженерики, и это стало определяющим моментом выбора пути дальнейшего совершенствования. Остальные, не менее важные изменения, такие как рабочие области и фаззинг, можно считать приятным бонусом.

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

Стоит оглянуться на уже пройденный путь и увидеть, через что прошел язык за все эти годы. Идея отодвинуть C на второй план более не является драйвером развития. Причём путь Go — не только история успеха, но и провалов. Недавний эпизод с уязвимостью Log4shell заставил пересмотреть отношение к безопасности и привёл к созданию инструментов вроде govulncheck.

Впереди будет ещё множество «‎синяков» и «‎набитых шишек», но мы в Evrone склонны верить, что этап детства позади, а Go ждёт отличное будущее. Нам же остаётся продолжать наращивать свою экспертизу и делиться опытом с «‎коллегами по цеху».

Easy Go Containers

Песочница CNCF пополнилась ещё одним полезным инструментом, а именно проектом ko. История его создания началась в 2018 году в процессе разработки решения Knative. Нужно было создать удобный инструмент развёртывания Go-приложений в контейнеры Kubernetes. Разработчики блестяще справились с этой задачей и их детище теперь стало очередным вкладом в развитие open-source software.

Основным юзкейсом ko является упаковка Go-приложения в образ и его отправка в реестр для контейнеров (например, в Container Registry) без необходимости создания Dockerfile. Любопытно, что на хосте вообще может не быть установлен Docker. За основу ko берёт образ distroless вообще без оболочки и исполняемых файлов. Это делает его безопаснее и меньше по размеру.

В целом, ko можно рассматривать как простой и функциональный конструктор, экономящий время. Если локальный билдер Docker формирует образы через запуск контейнера и снятие снапшотов с файловой системы, то ko действует иначе. Он напрямую формирует образ и манифест вообще без запуска контейнера. Это и приводит к экономии времени.

Вновь о фаззинге

Наверняка у вас были такие ситуации, когда звучала фраза «‎я бы в жизни не догадался». И это именно та фраза, которая объясняет, что делает фаззинг. Он позволяет выявить такие баги, о которых невозможно догадаться. Как в знаменитой фразе из фильма ДМБ — «‎Суслика видишь? Вот и я не вижу. А он есть».

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

Получилось, что сработал сценарий, который нельзя было предугадать. Это стало поворотным моментом, который привёл к созданию первых фаззеров, отправляющих сгенерированный «‎мусор» на ввод Unix-систем. Но если с привычными командами всё достаточно просто, то где в коде следует искать баги таким способом?

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

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

The IDE Of The Future

Внешний вид Fleet

Разработчики много проводят времени в IDE — это факт. И вопрос удобства работы здесь вовсе не праздный. Среди гоферов наиболее часто используется Visual Studio Code от Microsoft и Goland от JetBrains. Последние, впрочем, не останавливаются на достигнутом и предлагают взглянуть на preview-версию их нового детища Fleet. Это интересная попытка заглянуть в будущее и создать универсальную IDE, в которой разработчикам будет удобно писать приложения на самых разных языках.

Первое, что бросается в глаза: если код находится за пределами локальной машины, то можно получить к нему доступ разными способами. Можно сразу склонировать код из репозитория на GitHub, подключиться к удалённому серверу по SSH, получить доступ к Docker-контейнеру или нативной для JetBrains платформы Space.

Окно поиска GOTO

Интерфейс очень похож на VSCode и интуитивно понятен. Есть типичный для продуктов IntelliJ экран поиска GOTO, позволяющий найти нужный текст в кодовой базе, а затем сразу открыть файл и перейти к нужному месту. Словно хороший официант, Fleet сам предложит создать модульный тест при написании функции. В процессе отладки он отобразит все горутины, что достаточно удобно для определения состояния каждого из запущенных процессов.

Это лишь малая часть интересных функций новой IDE. Более подробное описание вы найдёте в статье Previewing The IDE Of The Future и блоге разработчиков. Станет ли Fleet конкурентом VSCode? Посмотрим. Все задатки у него есть.

Интересно посмотреть

Go-митап

Пропустили наш предыдущий Go-митап? Не страшно — записи докладов в кинематографическом качестве выложены в сеть.

Антон Губарев из Авито рассказал про опыт реализации ролевой системы доступа с помощью Open Policy Agent:

Николай Тузов из Lamoda детально описал внутреннее устройство каналов в Go:

В завершение Андрей Беренда из Ozon Fintech поделился опытом взаимодействия с ошибками, которые нельзя обработать в Golang:

Немного IT

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

Ну а если вам есть что сказать — добро пожаловать в комментарии!

Впереди Рождество и Новый год — время, когда каждый хочет уделить время родным и близким. Поэтому это завершающий Go-дайджест 2022 года, а следующий выйдет в январе 2023, где мы соберём самые интересные новости, дискуссии и инструменты за 2 месяца сразу. Спасибо, что читаете нас!

Вакансии

Удаленка / Офис

Evrone

Подробнее

Испытание медными трубами

Evrone digest — Wed, 19 Oct 2022 11:52:58 +0000

Привет, гоферы! Сегодня взглянем на проблему обратной совместимости и кроссплатформенной разработки с помощью Go. Также расскажем про неоднозначный фреймворк Beego и корректный подход к завершению работы приложения.

Graceful Shutdown

О graceful shutdown и hard shutdown мы чаще всего слышим в контексте операционных систем. Первое можно назвать плавным завершением работы: все исполняемые приложения корректно закрываются и только после этого ОС завершает работу. Второе же можно назвать принудительным выключением: ОС прекращает работу вне зависимости от того, успели запущенные приложения завершиться штатно или нет.

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

Начать стоит с туториала How To Use Contexts in Go от DigitalOcean. Из него вы узнаете, какие функции и методы можно использовать для реализации плавного завершения задач. context.Background создаёт новый контекст на каждый новый процесс. А метод Done() интерфейса Context вместе с фунцией context.WithCancel помогает корректно завершить работу контекста.

Чтобы взаимодействовать с сигналами завершения от ОС, потребуется пакет os/signal. Он также входит в стандартную библиотеку языка и реализует доступ к входящим сигналам ОС. Стоит помнить, что поведение в UNIX-подобных ОС будет отличаться от поведения в Windows или Plan 9.

Кроссплатформенность с Fyne

В нашем дайджесте по Flutter мы не раз отмечали удобство кроссплатформенной разработки. Единая кодовая база для мобильного и десктопного приложения делают жизнь разработчика проще. Но не только Dart может этим похвастаться. У Golang припрятан козырь в рукаве — Fyne.

Это простая библиотека, позволяющая создавать программы с графическим интерфейсом на Go. Вместе с кросс-компилятором fyne-cross они позволяют собрать приложение почти под любую операционную систему и архитектуру. Обольщаться не стоит — там есть нюансы, которые не дают возможности работы сходу, «из коробки». Но и ничего сложного тоже нет, но без установленного докера адекватно не работает.

Вот так будет выглядеть Helloworld, написанный с помощью Fyne:

package main import ( "fyne.io/fyne/v2/app" "fyne.io/fyne/v2/container" "fyne.io/fyne/v2/widget" ) func main() { a := app.New() w := a.NewWindow("Hello") hello := widget.NewLabel("Hello Fyne!") w.SetContent(container.NewVBox( hello, widget.NewButton("Hi!", func() { hello.SetText("Welcome :)") }), )) w.ShowAndRun() }

Этот пример можно запустить как обычно через go run main.go или в режиме симуляции мобильного устройства go run -tags mobile main.go.

Заинтересовали? Тогда обязательно прочитайте статью на Хабре Golang fyne Куда нажать? :-(, где автор подробно описывает свой опыт создания приложений на Fyne. Отдельно отметим, что кроме статьи автор составил краткий гайд по кросс-компиляции.

Go и обратная совместимость

Какое профессиональное сообщество без холивара? Вот и о тему обратной совместимости было сломано немало копий в попытках доказать жизнеспособность той или иной идеи.

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

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

Развитие языка за последний год показало существенные преобразования в плане переделки архитектуры. Теперь в языке есть дженерики, появился фаззинг и в планах внедрение PGO (Profile-guided optimization). В сообществе закономерно начались обсуждения и таких важных вещей, как обратная совместимость.

Часть мейнтейнеров Golang указывают, что их цель — достижение полной обратной совместимости с первой версией языка. Это означает большую стабильность для конечных пользователей и задекларировано в документации. Исключения — исправления ошибок и ситуации с нарушением безопасности.

Есть и другая, альтернативная точка зрения. Мы видим немало примеров, когда выбор, сделанный в пользу прогресса, и отказ от обратной совместимости позволил добиться хороших результатов. Так Python 3 обзавёлся массой новых функций, код стало удобнее читать и воспринимать. Судя по рейтингам, языку это пошло на пользу.

Ждут ли нас глобальные изменения в Golang — покажет время. А пока можно спокойно обдумать всё вышесказанное, а возможно и поделиться своим мнением с коммьюнити.

Фреймворк Beego

В нашем дайджесте мы всегда стараемся рассказывать о самых разных инструментах разработки, даже о неоднозначных. Например, привычную для многих MVC-архитектуру попытались запихнуть в Go. Результатом стали такие фреймворки, как Revel и Beego. О последнем и расскажем чуть подробнее.

Tornado, Sinatra и Flask — именно они стали источником вдохновения для автора фреймворка. С помощью Beego можно создавать RESTful API, веб-приложения и серверные службы. Используется принцип «battery included» в отличие от того же Gingonic, то есть в фреймворке есть все необходимые инструменты.

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

Итого — можно писать full-stack приложения на Go, используя MVC-архитектуру. Но надо ли?

Подкасты

Немного IT

Выпуски длятся 50-70 минут, а значит можно совместить какие-нибудь скучные занятия с обучением. Включайте шумоподавление на наушниках, чтобы не слышать пылесос, и погружайтесь в нюансы Go! Ну а если вам есть что сказать — добро пожаловать в комментарии!

Митапы

Онлайн

Осенний Go Meetup

19 октября 2022

Рады сообщить, что уже сегодня вечером состоится Go Meetup. Нас ждут интереснейшие доклады спикеров:

Антон Губарев (Авито) — «Реализация ролевой системы доступа с помощью Open Policy Agent».
Николай Тузов (Lamoda) — «Внутреннее устройство каналов в Go».
Андрей Беренда (Ozon Fintech) — «Ошибки, которые нельзя обработать в Golang».

Ещё не поздно зарегистрироваться и принять участие в мероприятии.

Регистрация

Вакансии

Удаленка / Офис

Evrone

Подробнее