Go *

Новая эра межъязыкового взаимодействия

До 2024 года интеграция Go и Rust была либо через хрупкий CGO, либо через сетевые вызовы с накладными расходами. Выход Go 1.24 с директивой //go:wasmexport и дальнейшие оптимизации в Go 1.25 изменили правила игры благодаря WebAssembly Component Model (WCM).

Компонентная модель - это стандартизированная система типов (WIT) и ABI, позволяющая компонентам на разных языках взаимодействовать напрямую, без сериализации. Сегодня мы создадим Go-компонент и запустим его из Rust.

Почти каждый день в ленте я вижу новости про очередного "революционного" 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 и интерфейсы для построения составных конвейеров ответов. Вот как мы реализовали каждую из них в нашем производственном стеке.

Меня зовут Екатерина Рычкова, я CEO HR-агентства и рекрутёр с 15-летним опытом.

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

Самое приятное, что в IT-сфере оформление резюме — не самое ключевое. Главное, на что смотрит рекрутер:

Команда Go for Devs подготовила перевод статьи о том, как построить Heavy-Read API на Go, способный обрабатывать более 1 млн запросов в секунду. Автор делится продакшен-архитектурой распределённого In-Memory Cache, показывает, как убрать БД и Redis из критического пути чтения, и объясняет, за счёт каких оптимизаций удаётся добиться субмиллисекундных задержек. Практика, цифры и реальные уроки из продакшена.

Axiom — это недостающий тестовый runtime для Go, который добавляет фикстуры, шаги, хуки, retry, плагины, метаданные и структурированное выполнение поверх стандартного testing, оставаясь полностью совместимым с ним. Минимум магии, максимум инфраструктуры.

TL;DR

Переписал Composer на Go, получил 3-5x ускорение благодаря параллельной загрузке пакетов и отсутствию PHP runtime overhead. Проект полностью совместим с экосистемой Composer/Packagist (почти, об этом будет подробнее внизу).

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