Go *

Black-White Array (BWA) — это упорядоченная структура данных с амортизированным временем операций вставки/поиска/удаления и используемых участков памяти. Преимущества:

• Амортизированное время вставки/удаления/поиска сравнимое с реализацией BTree от Google;
• Низкое количество аллокаций памяти при операциях вставки - меньше давления на сборщик мусора, ниже фрагментация памяти;
• Массивы под капотом: данные лежат рядом, что улучшает кэшируемость процессором и скорость обхода/доступа к данным;
• Позволяет хранить элементы с одинаковыми ключами - не нужно использовать дополнительные структуры для группировки таких элементов;
• Низкий оверхед на хранение служебной информации - экономия памяти по сравнению с другими структурами данных;
• Удобен для вставки батчами;
• Простая сериализация и десериализация;

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

Когда мы говорим о сборщике мусора, то сразу думаем о куче. Зачем он нужен в стеке? Переменная попала на стек, функция завершила исполнение — стек вжух! — и очистился. 

А что, если я вам скажу, что на стеке Go тоже свой сборщик мусора? Звучит неожиданно? Давайте разберемся по порядку.

Привет! Эта статья - текстовая версия моего стрима с разбором задачи на бесконечную ленту по System Design из https://t.me/siliconchannel/141 этого поста.

Рассмотрим классическую задачу из System Design интервью - персональная лента подписок. По сути, мы проектируем упрощённый клон Instagram. Сама задача звучит следующим образом:

Команда Go for Devs подготовила перевод обзора языка Go от практикующего разработчика. Автор без прикрас разбирает сильные стороны Go — конкурентность, простоту и эргономику, — а затем подробно объясняет, почему его разочаровывают enum’ы, неизменяемость и модель ошибок.

Все уже слышали, что в Go 1.25 завезли новый экспериментальный сборщик мусора - Green Tea GC. Теории о том, как он работает, много (и в том числе на Хабре).

Но когда мы с коллегой попытались просто включить GOEXPERIMENT=greenteagc на наших обычных бенчмарках, нас ждало разочарование: результаты были то чуть лучше, то чуть хуже, то вообще одинаковые. Сплошная лотерея.

Мы задались целью: найти условия, в которых Green Tea GC побеждает безоговорочно. Не на 1-2% в пределах погрешности, а так, чтобы график "пробил потолок". И у нас получилось добиться стабильного ускорения пауз GC на 40-50%.

Почти каждый день в ленте я вижу новости про очередного "революционного" AI-агента. AutoGPT, BabyAGI, Devin, Cursor, Perplexity, Atlas.... мол они заменят программистов, копирайтеров а в итоге....

Я, как хотел бы инструмент, который просто работает, мол "Зайди в гугл, найди доку, скажи мне ответ" ради интереса - я решил написать свой AI-тул....

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

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

И когда до Нового года остаётся совсем немного времени, а сил на сложные технические материалы почти не остаётся, мы решили немного сменить ритм. Вместо глубоких разборов — лёгкое, тёплое и предпраздничное чтение. Так появилась идея серии интервью с участниками нашего комьюнити — людьми, которые создают плагины для OpenIDE.

Задумывались ли вы о том, зачем компьютерам нужна оперативная память (ОП, RAM), когда у них уже есть дисковое хранилище (диск)? Ответ кроется в скорости доступа. Хотя диск является постоянным, он намного медленнее, чем ОП. ОП жертвует изменчивостью ради скорости - данные исчезают при выключении питания, но время доступа гораздо меньше. Как следствие, центральный процессор (ЦП, CPU) имеет доступ только к ОП, а не к диску.

ЦП имеют встроенные регистры, которые еще быстрее, чем ОП. Тогда зачем нам вообще ОП? Затем, что количество и размер регистров ограничены. Представьте функцию, которой нужно работать с тысячью переменных - все они не поместятся в регистры. Что если нам нужно хранить большие структуры данных, такие как массивы или объекты? У регистров нет емкости (capacity). Вот где в игру вступает ОП - она предоставляет пространство, необходимое для обработки больших и сложных данных.

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

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

Первая часть цикла «Разбираем net/http на практике»: создаём с нуля сервис DeadDrop — аналог Privnote для безопасной передачи самоуничтожающихся сообщений и файлов.

На чистой стандартной библиотеке net/http разбираем основы:

• запуск HTTP-сервера

• маршрутизация в ServeMux

• написание middleware (логирование и recovery от panic)

• работа с HTML-шаблонами и layout’ами

• подключение статики через http.FileServer и embed.FS

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

Идеально для начинающих и тех, кто хочет глубоко понять внутренности популярных фреймворков вроде Gin и Echo. Пишем код вместе!

В этой статье мы рассмотрим, как использовать нейросети для описания кода через VS Code и как вносить изменения в описание в репозитории с помощью MCP-сервера GitHub.

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

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

В конце 2021 года, уже сильно после начала локдауна, моя одержимость кроссвордом газеты The New York Times превратилась в хобби-проект. Я хотел написать приложение с кроссвордами, понял, что мне нужны сами кроссворды, попробовал сочинять их вручную, осознал унылость этого процесса и задался вопросом: можно ли генерировать их алгоритмически? В этом году я наконец-то выпустил Crosswarped для iOS и Android — игру в кроссворды, созданную на основе генератора, описываемого в этой статье.

Всем привет!

Хочу рассказать об очередном своем пет-проекте, который может быть кому-то тоже полезен. А еще поделиться хорошим предновогодним настроением. Поэтому рассказывать буду в слегка позитивном и шуточном стиле :-)

Итак, перед вами — нейроучитель! Хех... Сразу говорю — к нейросетям он не имеет отношения (или опосредованное). Да и не учитель, собственно. Это моя собственная методика интервальных повторений, то есть зубрежки, увеличения словарного состава... Но обо всем по порядку — в статье я расскажу, почему это все же «нейро», зачем и каким образом.

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

Я Владислав Доронин — Go-разработчик в команде S3 облачной платформы Cloud.ru Evolition. Хочу рассказать про подход к управлению отказами реплик, который мы кристаллизовали опытом выхода из строя разных частей системы. Практика показала, что массовые и не очень отказы приводят к взлету задержки ответов и увеличению количества client-side повторов, которые тоже висят. Пускай на уровне записи из-за требований репликации и гарантии мы много поделать с ситуацией не можем (хотя и там не все безнадежно), то вот чтение гораздо более гибкое. У нас получилось сделать retry на чтении красивыми, об этом сегодня и поговорим.

Команда Go for Devs подготовила перевод статьи о том, как упростить сборку Go-проектов с cgo, используя Docker. Авторы на реальном примере показывают, как избавиться от платформенной боли, сложных зависимостей и ручной настройки окружения, при этом сохранив воспроизводимость продакшен-сборок. Практичный разбор для тех, кто сталкивался с cgo и кроссплатформенной сборкой.

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

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

Хотя экосистема LLM в основном ориентирована на Python, мы нашли Go исключительно подходящим для производственных развертываний. Наша инфраструктура на базе Go обрабатывает миллионы ежемесячных запросов LLM с минимальной настройкой производительности. Помимо хорошо документированных преимуществ Go (см. отличное изложение Роба Пайка о преимуществах Go), три возможности оказались особенно ценными для нагрузок LLM: статическая проверка типов для обработки выходных данных модели, горутины для управления параллельными вызовами API и интерфейсы для построения составных конвейеров ответов. Вот как мы реализовали каждую из них в нашем производственном стеке.