Go *

Приветствую тебя, дорогой Разработчик! Хочу поделиться своим опытом о том, как реализовать вход с помощью кошелька Metamask (расширение для браузера) в твой проект. В этой статье я пропускаю весь код архитектуры приложения и покажу тебе только сервисный код (нижний уровень кода. Взгляни на DDD архитектуру, также известную как «Чистый код»). Я использую GO с распространенными библиотеками для веб‑разработки, такими как Gin, jwt, sqlc и другие.

Для начала давай представим, как должен работать наш процесс входа. Как мы все знаем, стратегия «разделяй и властвуй» очень эффективна для чего угодно. Поэтому здесь мы можем разделить наш процесс на 2 логических шага. Назовем их «Начало» и «Завершение». Теперь давай посмотрим на схему нашего процесса, потому что мы, как инженеры, должны максимально упростить свою работу. Итак, схема — отличный способ достичь этого.

Golang — приключение не на 20 минут, а игра вдолгую. Подтвердили это, собрав в офисе Lamoda спикеров Lamoda Tech, а также 2ГИС и МТС. Помимо новых докладов, разблокировали экспериментальный формат факап-разгонов, где наши друзья из ВИ.Tech, Orion soft и Cloud.ru вместе со зрителями делились историями провалов. Публикуем материалы с этой встречи.

Решил перейти на Go. Причина простая — видел вакансии с зарплатой выше 100 тысяч, и почти везде Go. Я до этого писал в основном на Python. Немного Django, немного микросервисов, WordPress. Закончил онлайн-школу, работаю уже третий год. Решил, что пора прокачиваться и становиться программистом-полиглотом.

Вот мой опыт и небольшие замечания по языку:

Этот пост — погружение в кроличью нору. Разработчик Монсеф Аббад задумался о изображениях — вероятно, после недавнего изучения им некоторых схем компрессии. Общеизвестно, что изображения бывают либо полутоновыми, либо RGB, когда новые цвета создаются на основе смешения красного, зелёного и синего. Но для хранения изображения требуется нечто большее, чем просто выравнивание трехбайтовых значений RGB.

Что-то в этой идее пробудило любопытство автора, поэтому в статье он попытался удовлетворить его и ответить на вопрос: как на самом деле хранятся изображения?

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

^{Руководитель: Хочешь техлидить новый проект?}

^{Я: Да, конечно. А что за проект?}

^{Руководитель: Распределённые бэкенды на Go.}

^{Я: Go? Но я же скалист-функциональщик…}

^{Чуть позже}

^{Коллега: Слышал, что ты будешь техлидить другой проект — вы там тоже Scala завозить будете?}

^{Я: Нет, будем писать на Go.}

^{Коллега: Ты что, бросаешь Scala и нашу тусовку?!}

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

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

В процессе реализации своего VPN-бота, мне очень захотелось добавить оплату звездочками, потому что это сильно удобно. Подписку можно оплатить буквально в два клика.

TG Stars в целом сейчас обретают все большую популярность, учитывая, что Telegram уже не то что просто рекомендует, а заставляет всех продавцов цифровых переходить на оплату звездами.

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

Эта заметка будет очень короткой. Но надеюсь, она кому-то спасёт несколько часов жизни.

У меня был код. К счастью, это было в тесте, а не в боевом коде, поэтому никто не пострадал.

Код создавал http.Server, запускал две гороутинки для обслуживания входящих соединений:

go func() {srvr.Serve(p)}()

go func() {srvr.ServeTLS(e, "", "")}()

Ну и дальше создавал клиента, делал к серверу обращения (HTTP GET) попеременно используя http и https ну и чего-то там проверял.

Всё прекрасно работало. До обновления с go1.23.8 до go1.24.2, пришедшего с 42-й Федорой.

А потом перестало. Стало время от времени (но отнюдь не всегда) вываливать разнообразные ошибки. Например, вот такие: Get "https://127.0.0.1:46167/": unexpected EOF. Или такие: Get "https://127.0.0.1:34757/": write tcp 127.0.0.1:54770->127.0.0.1:34757: write: connection reset by peer. Или даже вот такие, совсем загадочные: Get "https://127.0.0.1:42447/": http2: client conn could not be establish. HTTP/2 там, разумеется никто не включал и не собирался. А иногда всё работало и тест проходил правильно.

Самое поганое, что ошибка была плавающей.

В общем, не буду грузить подробностями, как я эту ошибку ловил. Но итог такой. Хотя это нигде и не документировано, но одновременно использовать http.Server.Serve и http.Server.ServeTLS на одном и том же экземпляре сервера нельзя. Тот из них, кто успеет прокрутиться первым, чего-то там инициализирует внутри сервера, прежде, чем уйти в accept loop, и второй после этого ломается. Ломается всегда ServeTLS, не-TLS-овскому Serve вроде как пофигу.

Так что будьте осторожны, и надеюсь, что эта заметка сохранила вам несколько часов жизни :)

Привет! Я ex. Разработчик из VK, сейчас принял оффер от Ozon'a, и за последний месяц я прошел собеседования в 4х бигтех компаниях: Ozon, Avito, Wildberries и T-Bank и везде дошел до финалов/офферов. Пообщавшись во многих группах, посвященных Go-разработке, я понял, что много умных ребят готовясь к собесам не имеют четкой системы подготовки, и из-за этого заваливают технические собесы в компании. Не претендуя на истину в последней инстанции, предлагаю свою методику подготовки к собесам, которая помогла мне и моим знакомым подготовиться к техническим собесам во все популярные ру-бигтехи.

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

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

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

Статья-практикум показывает, как устроены HTTP/2, HTTP/3 (QUIC) и gRPC на самом низком уровне. Вместо толстых библиотек мы пишем минимальный учебный фреймворк «Mini-Transport» на Rust (~600 строк): реализуем кодек HTTP/2-фреймов, упрощённый gRPC-протокол и базовую обёртку над QUIC. В результате получаем рабочий echo-клиент и сервер, которые пересылают «hello ↔ world» через собственноручно собранные фреймы. Разбор сопровождается поясняющими схемами, ссылками на RFC, вариантами дальнейшего развития (HPACK, flow-control, TLS/ALPN) и готовым репозиторием для самостоятельных экспериментов. Материал рассчитан на разработчиков, желающих понять «как всё крутится под капотом» и прокачать навыки низкоуровневой сетевой работы в Rust.

Мне всегда хотелось творить какую-нибудь дичь с консолями. Не знаю почему, но меня всегда привлекала идея реализовывать на устройствах неожиданные возможности. Это относится и к PlayStation 2, выпущенной Sony в 2000 году.

Sony, пожалуйста, не подавайте в суд на меня за этот пост.

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

Поискав онлайн, я не нашёл простого решения, поэтому взялся за эту задачу самостоятельно.

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

Меня зовут Максим Коновалов, я архитектор Tarantool в VK Tech. В этой статье я расскажу, зачем и как мы уходили от Lua и что получили в итоге.

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

Я прочитал статью Migrating away from Rust и хочу поделиться с вами своими мыслями, заодно переведя оригинал. Я буду вести повествование от своего лица, поскольку это скорее реакция и размышления, а не традиционный перевод.

Для меня тема весьма актуальна, так как я сам нахожусь в этом странном лагере разработки игр на нишевых движках. Я использую не Rust+Bevy, а Go+Ebitengine, но многие плюсы и минусы этих комбинаций интересно рассматривать как дополняющие друг друга.

Когда-нибудь, я обязательно напишу статью о своём опыте серьёзной разработки игр на Go, но пока я слишком сильно завертелся в рабочем процессе, чтобы успеть доделать демку своей игры до Steam Next Fest. Будет ли эта статья положительная, или это будет миграция на Godot? Кто знает!

Ну а пока, погнали разбирать статью.

Я знаю, что на эту тему уже было сказано много, но настал мой черед. На JS я пишу больше 10 лет, так что терпел я достаточно. Мы называем это “джаваскрипт”, но под капотом скрываются три разные сущности: EcmaScript, среда исполнения и экосистема. Иногда о них стоит говорить отдельно, но сегодня я хочу обсудить всё сразу и объяснить, почему джаваскрипт — это плохой язык. Не в смысле “не работает”, а в смысле “заставляет страдать”.

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

Сегодня хочу поговорить о проблеме, которую многие недооценивают в своих Go-проектах. Речь пойдет о бессрочном select {}, который легко может привести к блокировке, утечке ресурсов и деградации производительности.

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

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

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

Когда вы открываете файл через os.Open() или os.Create(), Go выделяет ресурс операционной системы — дескриптор файла.

Go предлагает уникальный и прямолинейный подход к обработке ошибок, отличающийся от try-catch в других языках. Он основан на явной проверке возвращаемых значений, что требует больших проверок, но ведет к более надежному коду. Рассмотрим основы, современные инструменты пакета errors и лучшие практики.