Go *

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

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

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

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

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

Golang Top 15 ошибок

Go – язык простой, но из-за кажущейся простоты многие разработчики совершают одни и те же ошибки, которые приводят к серьёзным последствиям в production. Ниже собраны 20 самых распространённых ошибок при разработке на Golang и рекомендации по их исправлению.

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

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

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

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

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

В предыдущей статье я попросил — «Расскажите, зачем вам DI‑контейнер в golang». Большое спасибо всем, кто оставил коммент и проголосовал. Общий вывод такой: используем контейнер, потому что с ним удобно писать тесты. Тесты — весомый аргумент, особенно в контексте того, что тест — это часть кода. Получается, мы все таки «тащим» Di‑контейнер в проект. Ну, хорошо....

Вероятно, это будет uber‑fx, ведь у него хорошая документация, самое простое и понятное API по сравнению с другими..., или нет — не «тащим»?

Мой ответ — нет, uber‑fx не «тащим», потому что можно еще проще и понятнее.

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

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

Modelfile позволяет упаковывать модели и формировать готовых агентов. В нем оказалось много реально неожиданного поведения, и одновременно с этим есть сложности и странности. Однако с его помощью можно взять множество разных моделей из того же Hugging Face и запустить под Ollama, а самое важное, удобства в тюнинге (или же наоборот отупливании модели :D ).

Привет, Хабр! Меня зовут Дмитрий Гурьянов, я руковожу командой Manuls в VK HR Tek (система ведения кадрового электронного документооборота). Сегодня расскажу о нюансах оптимизации на разных уровнях исполнения кода на Go.

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

Предлагаю разделить все возможные действия по оптимизации на группы по двум критериям: что мы оптимизируем и каким образом оптимизируем.

Свою первую работу программистом на языке PHP я нашёл в далёком 2011 году, имел опыт с разными версиями языка от 5.0 до 8.1 в коммерческих разработках. C тех пор иногда приходилось выходить в смежные области: Python, NodeJS, 1С, VBA и вот наконец Go. Для любого опытного профессионала не станет откровением, что одну и ту же вещь можно сделать разными средствами, и что для каждой задачи есть свой наиболее подходящий инструмент. В середине 2010-х особое распространение начинают получать такие направления, как High Load, микросервисная архитектура, и конечно модное тогда распиливание монолитов. Многие из проектов-монолитов были написаны на языке PHP, и из тех, кто стал делать первые шаги в Go в то время стали в том числе те самые программисты, которые с блеском в глазах могли, как мантру повторять «распилить монолит» и мечтать написать микросервис на Go под каждую задачу, требующей всего того, на что привычный PHP был не способен: неэффективный расход памяти, отсутствие асинхронности.

И в принципе, до выхода версии 7.4 с ее возможностью FFI (Foreign Function Interface) решить озвученные выше проблемы мог совсем не каждый программист, занимающийся разработкой "коробочной" CMS (WordPress, Drupal, Joomla! или Битрикс). В конце концов, мало кому хотелось, вспоминать полузабытый после университета язык C, браться за разработку собственного расширения для PHP (pecl).

Сказанное выше является моим субъективным мнением, единственным выводом из которых хотелось выделить одну простую мысль - есть некая аудитория программистов, которые знают и Go, и PHP. Если вы набрели на эту статью, вбив в поисковике слова "PHP FFI Go", то эта статья для вас, тех кто ищет нетривиальные пути, тех кто пытается взять лучшее от каждой из технологий.

В данной статье представлен пошаговый процесс разработки легковесного веб-фреймворка на языке программирования Go. Основываясь на стандартной библиотеке net/http, мы исследуем ключевые концепции, лежащие в основе современных Go-фреймворков, таких как Gin, Echo и тд.

Всем привет! Меня зовут Иван, я программирую на Python и недавно решил освоить новый ЯП. Долго думал, какой выбрать. В итоге решил довериться утверждению, что Python во многом похож на Go — на нем и остановился.

Ниже поделюсь личным опытом изучения языка — и да, я еще продолжаю его осваивать. Расскажу, какие встретил различия между Python и Go в типах данных, преобразовании типов данных, подходах к обработке ошибок. А еще обсудим, какой ЯП быстрее и можно ли импортировать и выполнить код Go в Python. Надеюсь, этот пост будет интересен тем, кто тоже собирается освоить второй ЯП. Ну, let’s Go!

Я старый фуллстек-разработчик и не знаю слов любви, но около полугода назад при очередной итерации сервера почувствовал себя утомленным путником, который узрел нежную красоту wr-обработчика нативного net/http! Вот раньше всё было ужасно - а теперь красиво, приятно читать и интересно показать! За несколько месяцев я переделал свои сотни обработчиков на новый стиль - и всё еще доволен! Почистил авгиевы конюшни слоев логики - теперь там царит запах фиалок! Также у меня была возможность посмотреть как пилят http профессионалы бэкенда - далеко не как фуллстеки, о чем тоже хочется рассказать!
Для ленивых читать - пора вернуть логику в обработчики! Но я расскажу подробно о той красоте, которая скрывается за этими многими восклицательными знаками, и о том, как её можно испортить. Структура такова:
- сначала чем фуллстек отличается от нативного бэкенда,
- потом пройдемся по API-стилю а-ля РЕСТ,
- прочтем оду нативному http-модулю, расковыряем пару болячек фреймворков,
- почитаем мои слова, почему wr-обработчик хорош сразу из коробки,
- и посмотрим пример того, как превратить обработчик в простой вид "задача-дано-решение-ответ".

Внимание, это мнение. В статье поднимаю холиварные темы, при этом я могу быть не прав, но буду настаивать! И фотка из личного фотоархива на тему "Люблю лето!", потому что уже надоели сгенерированные картинки.

Пару дней назад я опубликовал статью про ХрюХрюКар - телегам-бот для борьбы со стоянкой автомобилей на зелёных зонах. Проект с открытым исходным кодом.

За два дня ко мне обратилось несколько сторонников с просьбой добавить их города. Но вот незадача: у меня была возможность через админ-панель Django править данные в базе, но об этом кеш сервера не узнает (основной бекэнд на Go). В результате приходилось добавлять данные и перезагружать контейнеры с go-бекэндом вручную.

Основные серверы ХХК уже имели сторы, которые получают и обрабатывают апдейты, прилетающие через redis.

По сути, оставалось внести правки в часть django-бэкенда, чтобы обрабатывать сигналы pre_save и pre_delete, сериализовать данные и отправлять их в нужный канал редиса.

Решил поручить эту задачу Codex CLI, которую вчера OpenAI представили нам с вами. 

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

Сегодня я хочу поговорить о том, как мы все иногда очарованы показателями тестового покрытия в Go — и как же часто эти проценты лукаво нам подмигивают. Казалось бы, влепили go test -cover, получили любимые цифры, приближающиеся к 100%, и можно выдохнуть. Но, увы, не всё так радужно, как хочется. На самом деле заветная сотка покрытия далеко не всегда означает, что ваш код действительно покрыт тестами.

Привет, Хабр. Меня зовут Иван Добряев, я разработчик программного обеспечения в Центре технологий VK. Сегодня хочу поделиться опытом по одной достаточно прикладной, но весьма увлекательной теме — разработке командной строки (CLI) на Go.

Платформа для инференса ML-моделей (inference platform) у нас молодая, ей всего лишь полгода, и мы активно расширяем команду. Так что, если вы хотите писать сервисы на Go с нуля, то приходите к нам, у нас найдутся задачи на любой вкус.

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

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

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

В этой статье рассмотрим //go:linkname — неофициальной, но невероятно мощной фиче Go, которая позволяет вызывать приватные функции и обращаться к закрытым переменным других пакетов.