Go *

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

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

И практически с самого первого дня к нам начали обращаться крупные компании, не с просьбой добавить фичу, а с предложением заплатить. Потому что когда организация всерьёз рассматривает IDE для команды в несколько сотен человек, ей важно знать: есть договор, есть SLA, есть кто-то, кто несёт ответственность и завтра никуда не денется. Бесплатный open-source продукт эту уверенность не даёт сам по себе, как бы качественно он ни был сделан.

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

Так появилась OpenIDE Pro.

WebAssembly появился для браузерных задач как способ исполнять тяжелый код быстрее, чем это делает JavaScript. Но за последние годы он начал выходить далеко (иногда буквально далеко) за пределы вкладки браузера: серверы, edge-вычисления, плагины, песочницы. Появились рантаймы Wasmtime, WasmEdge, Wasmer, которые исполняют WASM-модули\компоненты прямо на ОС. Звучит красиво - собрал один бинарь, а запускаешь где угодно, да еще и в максимальной изоляции.

Но есть интересное наблюдение. Существуют проекты, которые строили свои виртуальные машины на WASM, но отказались от него. Самый заметный пример - это Polkadot. Они спроектировали собственную PolkaVM на базе набора инструкций RISC-V и переключили исполнительный слой смарт-контрактов на нее (при этом сам runtime Polkadot по-прежнему компилируется в WASM). Если WASM настолько хорош, как заявляется, то почему для нового движка выбрали не его, а регистровую машину?

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

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

Эта статья про один баг совместимости, который меня озадачил. Обе стороны честно объявляют версию протокола «dap-18», а байты на проводе не сходятся. Это не туториал по крипте и не показ репозитория - история про то, что строка версии - это не контракт совместимости, и про то, как это чинить, когда наткнулся.

Меня зовут Станислав Герасимов. Я программист С++/Qt, а также Go и выпускник магистратуры НИУ ВШЭ. С детства живу с тяжёлым неврологическим заболеванием — вторичной генерализованной дистонией с выраженными гиперкинезами. После многих лет лечения, нескольких нейрохирургических операций и многочисленных отказов в дальнейшем лечении в России я прошёл повторную операцию глубокой стимуляции мозга (DBS) в Турции у профессора Аттилы Йылмаза. На этом сайте я делюсь своей историей, рассказываю о лечении, программировании DBS, реабилитации, жизни с неврологическим заболеванием, а также о работе в сфере информационных технологий. Надеюсь, мой опыт окажется полезным и поддержит тех, кто также продолжает бороться за своё здоровье и качество жизни.

Привет, Хабр! Текущая статья будет полезна тем, кто уже знаком с основами языка программирования Golang и хочет более углублённо изучить его. Исходя из названия стати понятно, что речь пойдёт об аллокаторах, основных видах, плюсах и минусах, а также о том, какой аллокатор используется в Go. Я настоятельно рекомендую прочитать статью целиком, прежде, чем приступать к чтению части конкретно относящейся к аллокатору Go.

Привет! На связи Влад, разработчик product-facade — сердца витрины Ozon и одного из самых высоконагруженных сервисов, который выдерживает до 2,2 млн RPS. В прошлой моей статье я рассказывал об одном из архитектурных вызовов, с которым мы столкнулись в процессе работы. В этот раз продолжим тему микросервисной архитектуры и поговорим о том, что происходит, когда привычная строгость контрактов начинает мешать.

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

Я думаю, что все заметили, что в последнее время доступ к большинству зарубежным ресурсам и API оставляет желать лучшего. Для обычного человека потеря связи с любимыми или нужными ресурсами посреди рабочего дня — это очень неприятно. Полагаться на один зарубежный сервер стало неэффективно: узлы падают, скорость проседает. У меня у самого появилась это проблема, поэтому я захотел ее решить.

Что я решил сделать, рассказываю дальше

Привет, Хабр! Когда я был мелкий и трава зеленее, провайдеры всегда выдавали не белый, а «серый» адрес. Да, он менялся при каждом подключении, но всегда можно было открыть порт и поиграть с корешами в ту же CS 1.6 или Minecraft. Время прошло, и сейчас чтобы получить белый IP, нужно пройти три круга ада. И то не факт, что дадут. Или: «Купите наш тариф за миллион денег, тогда дадим».

Предыстория: от идеи к прототипу

Всё началось с того, что мы с коллегами по работе решили собраться и поиграть в CS 1.6. Желающих много, а вот чтобы все были в одном месте — уже не получается. И тогда меня посетила мысль: а что если сделать приложение, чтобы, потягивая пивко, можно было открыть игровой сервер для друзей? А не качать какие‑то Hamachi, ngrok и прочее, а потом ещё 15 минут настраивать порты, пока пиво остывает.

Я не начинал с идеи написать «убийцу JavaScript». Честно говоря, такие заявления обычно только мешают думать.

Сначала была гораздо более скромная мысль: мне нравится Go, мне нравится его простота, типизация и ощущение предсказуемого инструмента. Но когда дело доходит до интерактивного веб‑интерфейса, почти неизбежно оказываешься в другой вселенной: JavaScript, Node.js, сборщики, плагины, отдельная модель компонентов, отдельная экосистема.

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

Так появился мой небольшой экспериментальный проект GoFrame. Сейчас это не готовый фреймворк для продакшена, а исследование в сторону Go‑first подхода для браузера через WebAssembly: маленький рантайм, JSX‑подобная разметка .gox, компиляция этой разметки в обычный Go‑код и утилита goxc, которая способна сгенерировать, собрать и упаковать приложение. В README проекта это прямо описано как экспериментальный Go‑first фреймворк и набор инструментов для интерактивных браузерных приложений на WebAssembly; там же честно указано, что проект не заявляет готовность к продакшену, стабильный API 1.0, SSR, гидратацию, серверные API, форматтер или LSP.

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

Привет!

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

Я не новичок в разработке - повседневно пишу на Python и TypeScript, знаком с базовым devops. Но вот на территорию Go осознанно захожу впервые.

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

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

Поэтому если вы опытный Go-разработчик и видите в тексте неточность или косяк - буду искренне рад конструктивным подсказкам в комментариях.

Полгода назад я начал писать in-memory базу с векторным поиском на Go: RESP-протокол, HNSW-индекс, WAL, многопоточность. Рассказываю, что из этого вышло: как я мерил производительность и на каких граблях стоял, что реально ускоряет векторный поиск, а что нет. Все цифры воспроизводимы, код открыт.

Всем привет!
Эта статья является выжимкой моего опыта. Возможно для кого-то это очевидные вещи, тем не менее, считаю, что она может мыть полезна начинающим и не только.

Для работы с базами данных в го есть несколько подходов от стандартного "ручного", до удобных, таких как sqlx, GORM, sqlc... Список можно продолжать дальше.
При разработке очередного ПО я познакомился с sqlc (https://sqlc.dev/) и его подход мне понравился: на основе sql запросов создается полноценная обертка над бд - чем не песня, но как ее грамотно использовать в соответствии с принципами SOLID и Го подходом?

Чтобы измерять нагрузку, ошибки, задержки и потребление ресурсов, осознанно поддерживать SLO и настраивать алерты, не обойтись без Prometheus. Он принимает текстовый формат на HTTP-эндпоинте. Только вот Kafka, PostgreSQL, сетевое железо и Redis метрики по HTTP не отдают, либо понимают только JMX, SNMP и собственный REST API. Так что без переводчика не обойтись.

Всем привет! Я DevOps-разработчик из MTC Web Services. Этим материалом я открываю цикл из пяти постов, благодаря которому вы шаг за шагом напишете собственный Prometheus exporter с нуля на языке Go. Но просто написать код может и ИИ. Моя же цель — дать не только практическую, но и теоретическую основу, чтобы в будущем вы могли легко разработать свой exporter под любую задачу. 

Если вдруг вам уже знакома теория и важнее практика — заглядывайте за ней в оглавление. В качестве примера я выбрал kafka_exporter: он покрывает несколько типов источников, позволяет реализовать паттерн Custom Collector и его легко тестировать локально. А еще есть много популярных kafka_exporter, с которыми мы сможем сравнить наш результат. Код буду коммитить в репозиторий.

Когда компания растёт из одного продуктового направления в несколько, технический долг начинает выглядеть иначе. Проблема уже не в «старом коде», устаревших зависимостях или сложной поддержке legacy-системы. Долг начинает накапливаться в расхождении инженерных решений между сервисами.

Для нас в QIC digital hub это особенно заметно на фоне миграции на новый Go-бэкенд. Исторически платформа развивалась на разнородном стеке: разные части системы были написаны на разных технологиях. Сейчас мы постепенно переезжаем на Go. Часть сервисов уже в проде, часть ещё на пути. Именно в такой момент легко создать новый слой техдолга поверх старого: переписать поведение на новом языке, но оставить команды один на один с десятками одинаковых инфраструктурных задач, которые каждая решает по-своему.

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

- go-kit — общая библиотека с переиспользуемыми инженерными решениями;

- go-service-template — шаблон, который делает эти решения стандартным способом запуска нового сервиса;

- shared-renovate-config — общий Renovate-конфиг с единой политикой обновления зависимостей для всех репозиториев.

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

Представьте себе высоконагруженный сервис, который решает, с какого из множества складов нужно отправить товар покупателю. В пике через него проходит около 600 000 RPS, а строгий SLA требует ответа в пределах 50 мс. Для расчёта нужно за минимальное время выбрать оптимальный склад с учётом остатков, доступности и других данных, которые хранятся в разных микросервисах и их базах данных.

Первое, что приходит на ум, — обратиться к этим сервисам по API во время запроса и получить всё необходимое для расчёта. Но один запрос может затрагивать сотни и даже тысячи складов, не считая связанных сущностей. Такое число сетевых вызовов быстро превысит SLA и приведёт к клиентским таймаутам. Сетевые запросы к мастер-системам в нашем случае — непозволительная роскошь, поэтому мы вынуждены держать слепок данных прямо в памяти подов. А значит, появляется новая проблема: как быстро и надёжно доставлять постоянно меняющиеся данные из мастер-систем в оперативную память сотен подов.

Я давно хотел убрать из backend‑разработки одну особенно липкую рутину: когда для каждой новой сущности снова и снова приходится собирать одни и те же слои REST API — repository, service, handlers, request/response модели, OpenAPI, auth, тесты, curl‑примеры, Docker и прочую инфраструктуру.

В этой статье рассказываю про query‑first подход и open‑source Go CLI rest, который позволяет реализовать эту идею. Смысл простой: если SQL‑запросы или MongoDB‑контракты уже описывают, какие операции нужны приложению, то из них можно сгенерировать согласованный каркас REST‑сервиса.

В статье показано, как это работает для PostgreSQL и MongoDB, что именно генерируется, что такоеrest doctor и почему цель инструмента — не заменить бизнес‑логику, а снять первые 80–90% повторяющейся ручной работы.

Я хотел использовать Claude прямо в мессенджере MAX — без браузера, без переключения контекста. Готового решения не было. Нашёл на GitHub китайский проект cc-connect — Go-фреймворк с plugin-архитектурой для подключения AI-агентов к мессенджерам. Telegram, Feishu, Discord там были. MAX — нет.

Написал адаптер, открыл PR. Приняли. Теперь поддержка MAX — часть основного репозитория.

Что такое cc-connect

cc-connect — Go-фреймворк с чёткой трёхслойной архитектурой:

Эта статья прежде всего будет полезна студентам и начинающим специалистам.

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

С момента написания первой статьи о B4 прошло полгода. Казалось бы, не очень много времени, но софтина получила ну очень большое количество фич, о которых хочется рассказать подробно. Не буду скрывать: хабраэффект сделал своё дело, и благодаря большому интересу после первой статьи очень многие не разочаровались в отсутствии какого-то функционала, а активно помогали - коммуникацией, запросами, тестированием, - благодаря чему все эти фичи в B4 и появились.

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