Создание игр на Go для абсолютных новичков

Статья призывает разработчиков вернуть интерес к кодингу, создавая простые игры на Go с библиотекой Ebitengine, и объясняет базовые принципы геймдева на практике 😏

https://threedots.tech/post/making-games-in-go/

👉 @GolangPortal

Лучший совет, который я когда-либо использовал, чтобы разобраться в кодовой базе, — это попросить Mermaid-диаграмму в Cursor

👉 @GolangPortal

Два новых расширения для SQLite от Walter Wanderley

- HTTP-запросы
- MQTT publish/subscribe

https://sqlpkg.org/?q=litesql

👉 @GolangPortal

Это должно быть обязательным к прочтению гайдом по проектированию RESTful API:
https://opensource.zalando.com/restful-api-guidelines/

👉 @GolangPortal

Generics in Go — From Basics to Advanced for Senior Developers

Гид для опытных разработчиков по освоению дженериков в Go, от базовых концепций до практического применения

https://medium.com/@sogol.hedayatmanesh/generics-in-go-from-basics-to-advanced-for-senior-developers-887790b018d0

👉 @GolangPortal

В Go 1.25 на Linux по умолчанию включён Container-aware GOMAXPROCS

Если вы не в курсе, в чём именно проблема с GOMAXPROCS, почитайте вот это: https://victoriametrics.com/blog/kubernetes-cpu-go-gomaxprocs/

Что важно знать:

1. Фича активируется только тогда, когда Go-программа запущена внутри cgroup с выставленными CPU-лимитами.

Если вы запускаете Go напрямую на Linux-машине (не в контейнере) или если у контейнера не заданы CPU-лимиты, рантайм не увидит никаких ограничений от cgroup и будет вести себя по-старому — использовать все доступные CPU-ядра.

2. Рантайм Go не выставляет GOMAXPROCS только на старте

В Go есть специальная горутина — system monitor (sysmon), которая работает в фоне и выполняет разные служебные задачи. Этот system monitor периодически вызывает логику container-aware GOMAXPROCS, чтобы проверить, не изменились ли CPU-лимиты.

Если вы явно задали GOMAXPROCS, такие обновления полностью прекращаются.

3. Формула: GOMAXPROCS = min(affinity_count, max(2, ceil(quota/period)))

Минимальное значение GOMAXPROCS всегда равно 2, независимо от того, насколько низко выставлен CPU-лимит контейнера (за исключением случая, когда affinity_count < 2). Любой дробный CPU-лимит округляется вверх до ближайшего целого числа

Например: если задать лимит контейнера 0.5 ядра, то всё равно получится GOMAXPROCS=2; если задать 2.3 ядра — получится GOMAXPROCS=3; если задать 8 ядер на машине с 4 ядрами — получится GOMAXPROCS=4.

Обратите внимание, что CPU affinity отличается от CPU limits:

- CPU affinity говорит: «ты можешь выполняться только на этих конкретных ядрах» (например, ядра 2, 4, 6, 8).

- CPU limits говорят: «ты можешь использовать вот столько процессорного времени» (например, эквивалент 2.5 ядер по времени выполнения).

В большинстве обычных случаев affinity_count равен общему числу CPU-ядер на ноде.

👉 @GolangPortal

Нашел годный ресурс, где автор пишет статьи по System Design. Внутри очень много схем и все они похоже отрисованы автором вручную для каждой статьи. Контент качественный, излагается почти в том порядке как на реальном интервью.

https://systemdesign.one/real-time-presence-platform-system-design/

👉 @GolangPortal

Механика работы sync.Pool отлично описана здесь: https://victoriametrics.com/blog/go-sync-pool/index.html

- Почему в New() у sync.Pool следует возвращать указатель?
- Как sync.Pool связан с планировщиком или GMP-моделью?
- Что такое проблема false sharing?
- Как устроен sync.Pool внутри?
- Как работает механизм stealing в sync.Pool?
- Почему в Go прямо указано: «Любой объект, положенный в Pool, может быть удалён автоматически в любой момент без уведомления»?

Кто ещё не читал, рекомендую ✌️

👉 @GolangPortal

Круто, а вот и команда Go выпустила статью на эту тему

https://go.dev/blog/container-aware-gomaxprocs

👉 @GolangPortal

Anubis

Опенсорсный проект на Go, использующий Proof-of-Work для защиты от AI-скрейперов. Стартовал в январе, уже собрал 200k+ скачиваний и стоит в продакшене у GNOME, FFmpeg, FreeBSD, lore.kernel.org и других крупных ресурсов

https://github.com/TecharoHQ/anubis

👉 @GolangPortal

Нашёл классную 3D-визуализацию fan-in паттерна конкурентности в Go: https://divan.dev/demos/fanin/

В полной статье есть и другие паттерны: https://divan.dev/posts/go_concurrency_visualize/

👉 @GolangPortal

Go-драйвер для SQL, который позволяет выполнять запросы к CSV, TSV и LTSV-файлам, используя синтаксис SQL из SQLite3. Запрашивайте данные напрямую из файлов без каких-либо импортов или преобразований

https://github.com/nao1215/filesql

👉 @GolangPortal

Как работает Protobuf

Protobuf (Protocol Buffers) — это способ сериализовать данные в компактный бинарный формат. За счёт этого они занимают меньше места и быстрее гоняются по сети, но становятся менее читаемыми для человека

Размер данных - одно из преимуществ Protobuf. Изучите его техники кодирования, они широко применяются во многих высоко оптимизированных системах:
https://victoriametrics.com/blog/go-protobuf/

👉 @GolangPortal

Пакет для синхронизации и асинхронных вычислений в Go

https://github.com/reugn/async

👉 @GolangPortal

Интерактивное и пошаговое руководство по изучению Git. Команды можно выполнять прямо в статье.

https://antonz.org/git-by-example/

👉 @GolangPortal

12 лучших ресурсов по Go. Забирайте ссылки:

1. Go Concurrency Rocks: https://concurrency.rocks

2. Go Cookbook: https://go-cookbook.com

3. 100 ошибок в Go и как их избежать: https://100go.co

4. Практические уроки Go: https://practical-go-lessons.com

5. Распространённые паттерны производительности: https://goperf.dev/01-common-patterns/

6. Практические сетевые паттерны: https://goperf.dev/02-networking/

7. Изучение Go с помощью тестов: https://quii.gitbook.io/learn-go-with-tests

8. Гайд по профилированию, трейсингу и наблюдаемости в Go: https://github.com/DataDog/go-profiler-notes/blob/main/guide/README.md

9. Go Class: https://youtube.com/playlist?list=PLoILbKo9rG3skRCj37Kn5Zj803hhiuRK6

10. Дорожная карта по Go: https://roadmap.sh/golang

11. Серия «Go в VictoriaMetrics»: https://victoriametrics.com/blog/categories/go-@-victoriametrics/

12. Практические советы по Go: https://github.com/func25/go-practical-tips/blob/main/tips.md

👉 @GolangPortal

Кэш на Go, CAS-безопасный, с одиночными элементами, валидируемыми при чтении, валидацией пакетного Set, подключаемыми провайдерами/кодеками и опциональными общими поколениями

https://github.com/unkn0wn-root/cascache

👉 @GolangPortal

Основные команды Docker-контейнера (шпаргалка)

Запуск контейнеров, подключение к ним и выполнение команд внутри контейнеров — это ключевые операции по управлению контейнерами

Максимально наглядное объяснение их на одной диаграмме

👉 @GolangPortal

Вертикальное масштабирование пода без перезапуска стало возможным начиная с Kubernetes v1.33.

Обычно, если вы хотели выдать приложению (Pod в Kubernetes) больше памяти или CPU, его приходилось перезапускать.

Это ок, если приложение спокойно относится к перезапускам, но есть такие, которым остановки/старты противопоказаны: базы данных, тяжёлые batch-задачи или штуки, которым нужна ровная непрерывная работа.

Бета

Новая фича «in-place Pod resize» позволяет менять объём памяти и CPU у Pod, пока он продолжает работать. Начиная с версии 1.33 она считается достаточно зрелой для обычного использования и включена по умолчанию. До этого нужно было включать фича-гейт InPlacePodVerticalScaling.

Как

Вместо обычного kubectl edit по Pod используется специальный подресурс /resize. Например, можно сделать patch так:

kubectl patch pod mypod --subresource=resize ....

Это похоже на то, как устроены другие возможности Kubernetes. Например:

🔹/status — подресурс, которым можно обновлять только поле status объекта, не трогая его spec.

🔹/scale — подресурс у Deployment или StatefulSet, позволяющий менять количество реплик без редактирования всего манифеста.

Аналогично, /resize — подресурс у Pod, который позволяет менять ресурсы на месте.

Важно: это применяется к отдельным Pod. Если запустить kubectl set resources на Deployment, StatefulSet или Job, это всё равно поменяет шаблон и породит новые Pod, а не сделает in-place изменение.

Увеличивать CPU просто, увеличение памяти обычно проходит, если на узле есть свободная ёмкость. Уменьшать CPU тоже легко, а вот уменьшение памяти — самый сложный кейс и может провалиться, быть отложено или потребовать перезапуск в зависимости от политики. Чтобы понимать, как идёт процесс, следите за полями status и conditions у Pod.

Политика ресайза

Каждый контейнер в спецификации Pod может задать resizePolicy. Внутри этого поля CPU и память перечисляются отдельно, и для каждого выбирается политика перезапуска. Доступны два значения:

🔹NotRequired: Kubernetes попытается изменить значения ресурсов на месте, пока контейнер работает. Это значение по умолчанию. Это best-effort: если рантайм не может безопасно применить изменение (особенно при уменьшении памяти), операция завершится ошибкой вместо принудительного перезапуска.

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

Пример:

resizePolicy:
  - resourceName: cpu
    restartPolicy: NotRequired
  - resourceName: memory
    restartPolicy: RestartContainer

Источник

👉 @GolangPortal

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

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

👉 @GolangPortal

Кроссплатформенный SQL-редактор, доступный прямо из браузера и работающий как HTTP-сервер на Go. Предоставляет удобный интерфейс для лёгких ETL-задач, позволяя копировать данные между базами данных, таблицами, JSON и CSV-файлами

https://github.com/a-le/db-portal

👉 @GolangPortal