Go *

Здравствуйте,

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

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

Одна из моих программ, ipp-usb, написанная на Go, входит во все дистрибутивы Linux и *BSD и делает возможным использование принтеров и сканеров, которые подключаются к USB и поддерживают IPP over USB протокол - т.е., примерно всех современных.

А еще я член OpenPrinting - небольшой, но очень плодотворной группы людей, которая ответственна за печать и, отчасти, сканирование на всех UNIX-like OS и за формирование индустриальных стандартов в этой области.

Это всё начиналось для меня, как хобби, но сейчас это - часть моей оплачиваемой работы.

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

Об одной из таких штук и пойдёт речь в этой статье.

Понадобился мне для одного проекта на Go встроенный скриптинг. Ну т.е., чтобы программа могла всосать в себя скрипт, который определяет некоторые аспекты её поведения.

Размышляя о том, на каком языке программа должна скриптоваться, в выбирал между JS, Lua и Python.

Однако, JS и Lua - слишком нишевые языки. JS ассоциируется у всех с вебом а Lua - с разработкой игр. Таким образом, выбор естественным образом пал на Python. Этот язык знают все, а я испытываю некоторую надежду, что скрипты для моей программы буду писать не только я. Хотя сам я, должен признаться, Python не знаю и не люблю :)

Таким образом, осталось только придумать, как встроить интерпретатор Python-а в программу на Go.

Всем привет! Эта статья посвящена всеми любимому "разбору под капотом". На этот раз мы взглянем на работу HTTP сервера в Go и разберем некоторые нюансы и ключевые механизмы. Статья будет полезна как новичкам, так и опытным разработичкам!

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

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

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

Привет, Хабр! Меня зовут Кирилл Шваков. В Kinescope мы разрабатываем B2B-решение для хранения, обработки, защиты и доставки видео через CDN. Среди наших клиентов — как небольшие стартапы, так и крупные компании. Помимо CDN, у нас, само собой, есть и собственный DNS. А главное, множество инфраструктурных самописных компонентов на Go, которые мы развиваем и поддерживаем внутри команды.

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

Всем привет!

В последнее время мои знакомые стали меня часто спрашивать, как вкатиться в разработку на Go, и каждому я отвечал +- одно и то же, скидывал +- одни и те же материалы, которыми пользовался когда-то сам. И чтобы постоянно не повторяться, я решил составить простой и понятный алгоритм действий: «Учишь это шаг за шагом и становишься Go-разработчиком».

Здравствуйте, коллеги!

Хочу поделиться опытом проектирования и реализации production-ready Telegram-бота, который автоматически собирает и публикует свежий видеоконтент из паблика ВКонтакте — и делает это без дублей, с гарантией доставки и мемными подписями на базе OpenAI. В статье я покажу архитектуру, приведу примеры кода и расскажу о фишках, таких как очередь ссылок на видео (NutsDB), проверка на уникальность (deduplication), скачивание через yt-dlp и интеграция с OpenAI для генерации описаний.

Обработка ошибок — это один из самых важных аспектов написания надёжного кода. В Go к этому вопросу подошли нестандартно: вместо традиционного механизма try/catch, как в Java или Python, ошибки просто возвращаются как значения. Изначально это может показаться странным, но на практике этот подход делает обработку ошибок более явной и честной.

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

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

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

Я считаю, что при работе с Go в контексте нашей отрасли внедрение зависимостей (dependency injection, DI) часто имеет плохую репутацию из-за DI-фреймворков. Но сама по себе DI как техника довольно полезна. Просто её объясняют слишком большим количеством ОО-жаргона, что приводит к ПТСР у тех, кто перешёл на Go, чтобы сбежать из культа банды четырёх.

Знаю, что тема уже изъезжана вдоль и поперек, но я хотел бы поделиться своим видением Open/Close Principle из всеми любимым SOLID подходу к построении архитектуры софта. Ведь дядюшка Боб херни не посоветует, все таки опыта ему не занимать, поскольку он с 70х годов в разработке и знает базу, что нам и нужно. Да современный софт ушел далеко от того какой он был в 70-х, когда писали логические цепочек на перфокартах, делая дырки в картоне и компиляция занимала прямо прапорционально количеству этих самы карточек, где скорость выполнения считалась количеством символов в минуту. За все это время Дядюшка Боб собирал лучшие практики из которых и получились эти 5 принципов, которые помогут построить софт, который будет не так сильно с течением времени влиять на стоимость одной строки кода. (О чем он и пишет в своей книги «Чистая архитектура»).

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

Если вы читали книгу «Чистая архитектуры» и дошли до Open/Close principle (SOLID) и из примера ничего не поняли, тогда вы пришли по адресу, поскольку я буду рассматривать именно этот пример. Для меня лично OCP это один из принципов, который заставляет продумывать архитектуру приложения, что очень важно.

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

Привет, Хабр! Меня зовут Александр Белышев. Хочу поделиться своим недавним опытом работы над RAG‑сервисом и думаю, что эта тема может быть интересна другим коллегам.

У меня на работе возникла задача по реализации RAG (Retrieval‑Augmented Generation) сервиса. Хотя без моего участия эту задачу успешно решили на Python, изучая их код я задумался: а как можно сделать что‑то подобное на Go?
Результатом этого исследования и моей работы стало следующее решение...

Чтобы понять, что решает synctest, мы должны сначала рассмотреть основную проблему: недетерминизм в конкурентных тестах.

func TestSharedValue(t *testing.T) {
    var shared atomic.Int64
    go func() {
        shared.Store(1)
        time.Sleep(1 * time.Microsecond)
        shared.Store(2)
    }()

    // Проверяем общее значение через 5 микросекунд
    time.Sleep(5 * time.Microsecond)
    if shared.Load() != 2 {
        t.Errorf("shared = %d, want 2", shared.Load())
    }
}

Этот тест запускает горутину, которая изменяет общую переменную. Она устанавливает shared в 1, спит 1 микросекунду, а затем устанавливает её в 2.

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

Однако...

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

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

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

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

Привет, Хабр!

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

Привет, Хабр! Меня зовут Владимир Марунин, я ведущий разработчик в команде Clatch. Сегодня расскажу о новых мапах в Go 1.24: разберем изменения, посмотрим, что было и что стало. О мапах часто спрашивают на собеседованиях, а еще без них нельзя просто так взять и написать программу на Go — так что, надеюсь, тема будет полезной и интересной.

Этот текст — расширенная версия моего доклада с митапа МТС True Tech Go. Если больше нравится слушать, а не читать, можно сразу переходить по ссылке. Поехали!

Wails - это легковесный фреймворк, предназначенный для создания кросс-платформенных GUI приложений рабочего стола на golang и стандартных веб технологиях (Svelte, React, Preact, Vue, Lit, Vanilla JS). Ближайшие аналоги это естественно Electron (JS), Tauri (Rust), хочется добавить Qt (С++), но это уже другой уровень. Сразу скажу, что Wails не идеален, имеет множество ограничений и в целом не подойдёт для чего-то крупного, Tauri к примеру более зрелый проект, больше функций, быстрее развивается, больше и живее сообщество, но это уже на rust, а это не наш стэк.

Программисты на Go уже давно и долго жалуются на слишком многословную обработку ошибок. Все мы близко (а иногда и болезненно) знакомы со следующим шаблоном кода:

x, err := call()
if err != nil {
// обработка err}

Проверка if err != nil встречается настолько часто, что может становиться объёмнее остального кода. Обычно это происходит в программах, выполняющих много вызовов API, в которых обработка ошибок рудиментарна и они просто возвращаются. Некоторые программы в итоге выглядят примерно так:

func printSum(a, b string) error {
x, err := strconv.Atoi(a)
if err != nil {
return err
}
y, err := strconv.Atoi(b)
if err != nil {
return err
}
fmt.Println("result:", x + y)
return nil }

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

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

Привет! Я Михаил Абраш — старший Go-разработчик, работаю в команде Evolution AI Factory в Cloud.ru. Недавно мы начали активно внедрять новые сервисы, переходя с Python на Go, и заметили, что нагрузка между репликами распределяется неравномерно. У нас в команде не было единого подхода к тому, как правильно делать балансировку, поэтому решили провести небольшое R&D-исследование. Что из этого вышло, к чему мы в итоге пришли и как работает балансировка gRPC в целом, рассказал в статье. 

С 1 июля 2025 года хранить персональные данные россиян в иностранных сервисах больше нельзя. Назрел вопрос, что же делать, например, с регистрациями на мероприятия, которые так удобно складывались из формочек Tilda напрямую в Google Sheets без СМС и регистрации. В статье расскажу, как я эту задачу решил с помощью бесплатного open-source сервиса Grist, платного, но копеечного Яндекс Облака и сомнительного Go кода.