Обновить
128K+

Go *

Компилируемый, многопоточный язык программирования

160,23
Рейтинг
Сначала показывать
Порог рейтинга

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

Мой бэкэнд реализует ряд REST API функций и начинает свою работу с ловли входящих соединений на порту. Для этого я использовал net.Listener, который как выяснилось испытывает сложности с повторным захватом порта, а SO_REUSEADDR, который прекрасно работает в С++ в Go работает, как-то, не очень. Автоматический запуск приводил к порождению бесконечного числа процессов, которые только писали в лог ошибки безо всякой полезной деятельности. И когда мне надоело заставлять это работать я решил использовать старый и проверенный метод: сделать так, чтобы бэкэнд запускался по каждому порту один раз. Оставим в стороне неинтересные подробности того как связывать процессы с конечными точками (endpoints).

И всё было прекрасно до тех пор, пока я не добрался до того, что os.FindProcess() всегда находит процесс. Даже если процесс уже завершился. В случае запуска на POSIX системе можно было бы использовать process.Kill(0), но на моём Windows 11 это не работает. И, в условно переносимом коде появилась ветка для Windows:

var perr *os.SyscallError if runtime.GOOS == "windows" && errors.As(errKill, &perr) && errors.Is(perr.Err, syscall.ERROR_ACCESS_DENIED) {
log.Warnf("unable to kill dead process: %d. Error: %v", pid, perr)
} else {
log.Warnf("unable to kill process: %d. Error: %v", pid, errKill)
return errors.New("previous process running")
}

А морали в данном посте не будет. Для меня это сильно похоже на Python, где я также делил код на Windows и POSIX. Вполне вероятно, что я просто не знаю простого и лёгкого способа добиться необходимого мне поведения.

Теги:
+4
Комментарии9

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

Чтобы эксперимент был чистым, взял стек, с которым не работаю каждый день: Node.js (Express 5) и Vanilla JS. На выходе получился хаб с утилитами: https://toolkitch.ru/

Главная идея проекта - простые инструменты средствами компьютера. Меня всегда раздражало, что популярные онлайн-сервисы гоняют данные на свои сервера, хотя по факту это может выполняться на компьютере. Здесь инструменты работают строго client-side, то есть в браузере пользователя. Ничего не устанавливал и не скачивал, но выполнил на компьютере.

По технической части:

  • Express 5 и Bootstrap 5.

  • Безопасность: настроил Helmet, прописал строгие CSP заголовки и CORS.

  • Деплой: GitHub Actions -> Docker Hub -> docker-compose -> Traefik с авто-SSL.

Писать код помогал ИИ-ассистент KodaCode. Впечатления положительные: нейронка полностью сняла с меня рутину вроде написания докер-файлов, конфигов Traefik и однотипной верстки под 7+ разных инструментов. Моя задача сводилась к контролю архитектуры и безопасности.

Сайт оптимизировал в том числе под ИИ-поисковики (GEO/AEO), чтобы тот же Яндекс Нейро или Perplexity могли индексировать страницы и предлагать эти утилиты пользователям по прямым запросам.

Посмотреть, что получилось, можно по ссылке выше. Будет интересно узнать, как вы используете ИИ в своей инженерной рутине, и какие специализированные плагины/инструменты можете порекомендовать. За критику по UI/UX сайта также буду благодарен.

Теги:
+6
Комментарии1

Язык, с которым у ИИ плохо

В подкасте Радио-Т 1018 был интересный момент, что у ИИ сейчас гораздо меньше опенсорсных репозиториев и датасетов на Swift, чем условно на Python или Go. И поэтому, как Claude Code, так и Codex хреново пишут нативные iOS приложения. А ведь API языка обновляется, имеющиеся данные в нейронках устаревают с каждым WWDC.

Я как бэкендер с этой темой не сталкиваюсь. Стало интересно, как в Apple вайбкодят разрабы и влияет ли это как-то на темпы разработки по сравнению с конкурентами. Apple Intelligence пока пытались запустить для обычных потребителей, или когда анонсировали переход на Gemini-бэкенд, это повлияло как-то на пайплайн разработчиков? Есть ли у их моделей какой-то секретный проприетарный датасет, чтобы повысить качество работы с их экосистемой?

Мне короткий гуглеж выдал, что анонсировался Swift Assist в 2024, но в 2025 году от него отказались в пользу доступа к любым моделям с помощью API-ключей. То есть сама компания не может предоставить продакшн тулинг за счет доступа к самому большому в мире закрытому репозиторию Swift-кода. Получается, Apple со своей закрытой инфраструктурой не может оставаться верной своей концепции. В эпоху агентской разработки у компании не получается замыкать на своем решении инженеров, чтобы не уступать конкурентам.

Тут у меня котелок начал накидывать вопросы.

Apple ладно, а какое будущее у новых языков программирования? Будут ли авторы новых языков задаваться вопросом «как мой язык будут поддерживать нейросети?» Их популяризация будет целиком и полностью за счет опен-сорс коммьюнити теперь, пока остальные языки будут писать агенты? Сообщества сами генерят синтетические данные для языков программирования, чтобы локальные модели лучше умели в определенный скилл? Или может для языков будут сразу разрабатываться скиллы или MCP? Какую роль в адаптации к агентсткой разработке будут играть компилируемые языки со строгой типизацией по сравнению с нестрогими, скриптовыми языками? А поддержка нового языка агентами на сносном уровне, - это повод для флекса в презентации у компании?

В интересное время живем.

Теги:
+5
Комментарии8

Представлен открытый проект Navidrome Music Server, который позволяет слушать музыку с ПК где угодно. Работает очень просто: пользовательский ПК превращается в сервер, к которому можно получить доступ с любого устройства. Есть демо-версия проекта, чтобы понять принцип работы.

Теги:
+3
Комментарии0

На Go непривычно после Python

На работе переводим сервисы на Go. Делюсь ощущениями от Go, как FastAPI-питонист:

  • В Go классов нет, есть struct с полями.

  • Внутри структур нет методов. Перечислили поля и все. Дальше функцию связываем отдельно со структурой сигнатурой вида funс (s *SomeStruct) Greet () string {}. С аргументами читается еще тяжелее.

  • ООП нет, наследования нет. Связь между структурами через композицию.

  • Ошибки нужно обрабатывать руками без try ... except с помощью if err != nil {...}.

  • nil вместо None

  • Эксепшнов нет. Функции возвращают ошибку как обычное значение: val, err := SomeFunc(). Хотя в Python я ответ из кортежей прям не люблю и избегаю, тут это база.

  • Зато есть panic, которые по сути – необработанные эксепшны.

  • Но на паники есть recover, который лечит последствия паники :)

  • Комментарии через два слеша // comment

  • Докстринги над сигнатурами, а не под.

  • OpenaAPI для Swagger надо собирать самому без FastAPI. Напрочь забытый навык. Даже с либами вроде swaggo/swag делать это надо руками, с ошибками.

  • Валидации полей нужно писать руками. Нет аналога Pydantic с батарейками.

  • Строка в двойных кавычках "w" – строка. В одинарных 'w' – руна, другой тип данных, который принимает в себя только один символ. Писать слово или фразу в руну нельзя.

  • А есть еще backtick ` ` для тегов структур. В них как раз могут задаваться правила валидаций в go-playground/validator:
    type User struct {
    Name string `validate:"required,min=2"`
    }

  • len у строк в байтах. Символ в кириллице = 2 байта. len строки на кириллице ~х2, непривычно. Нужно считать длину рунами в строках.

  • Иинтерполяция делается через fmt.Printf(). В отличие от f-строк в Python требует в конце явного перевода строки с \n, иначе строки слипаются. 

  • Вместо snake_case – lowerCamelCase для приватных идентификаторов пакета, а UpperCamelCase для экспортируемых.

  • Первым аргументом в запускаемом приложении командой go run some-script.go неявно выступает путь до файла. Из-за этого появляются идиомы в циклах типо «начни со 2-го аргумента».

  • Моржовый оператор a := "some" в Go это инициализация переменной с присваиванием. В Python это оператор в if ... else блоках, который инициализирует переменную только если сработало условие.

  • Аргументы у методов – позиционные. DoSomething(first, second, last) против do_something(action=first, modifier=second, final_action=last) у Python. Python умеет в лаконичность, но тут Go в нее заставляет. У методов со сложными контрактами надо сигнатуру подсматривать.

Что в Go нравится:

Тут много наивного по неопытности :)

  • Горутины – топ. Не нужно в голове держать асинхронный код, потоки, процессы, футуры, CPU-задачи, IO-задачи – на все горутины. А для передачи данных – каналы. Горутины весят 2-4 КБ против ОС-потока в 2-4 МБ памяти. Нет танцев с GIL. go func и начинаешь в конкурентность.

  • Статическая типизация при сборке находит много ошибок без линтеров и mypy. Еще она заставляет явно писать типы данных в аргументах и ответах от функций. Код нагляднее.

  • Вместо двоеточий  и отступов фигурные скобки. Я еще с NodeJS любил не капризное авто-форматирование.

  • Go-скрипты собираются в бинарники. Для них не нужен установленный Python или JVM. Просто запускаем как обычный баш-скрипт через ./script

  • Импортировать пакеты нужно целиком. Как в Python только метод импортировать нельзя. Обязательная лаконичность тут нравится. Импорты аккуратные, а в коде вызов их функций более явный.

  • Код модулей удобно читать сверху вниз. Python – интерпретируемый. Все, что не объединено в класс, должно быть объявлено перед вызовом. Код приходится нередко читать снизу вверх. Go – компилируется, порядок кода неважен. Читать код по ходу пьесы проще.

  • Стандартный пакет для тестирования go test все умеет из коробки. Аналог pytest как внешняя зависимость не нужен.

  • Ради чего все это: перевод сервиса с Python на Go даже тупо с ИИ-агентом, по метрикам Prometheus (АБ 50/50 трафик) снизил время ответа и потребление CPU и IO-ресурсов в десятки раз.

Из-за последнего вас и спрашивают на Python-собесе «готов перейти на Go»? Бабки, с-ка, бабки.

Теги:
+9
Комментарии5

Сегодня Go востребован для промышленной разработки бэкенда и микросервисов. Переход на него с Java или Python часто замедляется не из-за синтаксиса, а из-за незнания встроенных возможностей Go. Увидеть разницу можно на живых примерах одного и того же кода, который мы подробно обсудим 8 июня на бесплатном вебинаре «Go за час: почему вы перестанете писать на Java/Python».

За 60 минут разберём живое сравнение «как то же самое пишется на Python/Java и на Go», типичные ошибки перехода и встроенные инструменты из коробки — от автоформатирования и бенчмарков до кросс-компиляции одной командой. Все участники получат готовый план освоения языка до уровня Middle+ за четыре недели и поймут, как повысить свою рыночную стоимость с помощью современного инструмента для микросервисов и высоконагруженных систем.

На вебинаре:

✍️ Почему Go? Стоит ли в 2026 учить еще один язык?

✍️ Простота и ясность без классов и наследования.

✍️ Встроенная конкурентность. Горутины, каналы и мьютексы.

✍️ Инструменты из коробки. Разработка без тонны фреймворков.

✍️ Сборка и кросс-компиляция.

✍️Типичные проблемы. Игнорирование ошибок, гонки и при чем тут указатели?

📆 Когда: 8 июня, 17:00 — 18:00 (Мск)

👨‍🎓 Спикер: Власов Евгений — эксперт в области Backend-разработки, Golang, Python, архитектуры ПО.

👉 Записаться на вебинар👈

На вебинаре расскажем про ключевые отличия Go от привычных языков, а чтобы системно освоить промышленные инструменты рекомендуем курс «Golang-разработчик». Программа ориентирована на формирование навыков, необходимых для промышленной разработки на Go: асинхронная коммуникация через очереди сообщений, тестирование, профилирование (pprof) и трейсинг (OpenTelemetry/Jaeger). Старт: 16 июня. Места ещё есть.

👉Записаться на курс👈

Теги:
Всего голосов 2: ↑1 и ↓1+2
Комментарии0

🚀 Golang Roadmap 2026 — полная карта обучения на русском языке

Это бесплатный open-source roadmap на русском языке. Внутри — 19 модулей, каждый со своей теорией, практикой, бесплатными ресурсами и финальным проектом. Программа собрана так, чтобы провести вас от полного нуля до уровня Senior/Staff Go Engineer за 12–18 месяцев при темпе 10–15 часов в неделю.

Главный принцип обучения - практика > видосы. Каждую тему вы закрываете кодом: пишете, ломаете, чините, рефакторите. Любой модуль завершается мини-проектом, который можно положить в портфолио.

🎯 Кому подойдёт

🐹 Новичкам в Go — даже если до этого писали только на Python/JS/PHP

🛠 Backend-разработчикам с другого стека — хотите перейти на Go

📈 Junior Go-разработчикам — нужен путь до Middle/Senior

🚀 Middle-инженерам — закрыть пробелы в архитектуре, observability, distributed

🤖 Тем, кто хочет писать AI-инфраструктуру — модуль 18 специально про это

https://github.com/Develp10/golangroadmap2026

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии0

Вы попали в следующую ситуацию: граница, проверка, оператор просит разблокировать телефон. Отказаться нельзя или невыгодно. Что можно?

Стандартные ответы у мессенджеров слабые. Обычный app-lock PIN открывает то же приложение, под принуждением бесполезен. «Удалить аккаунт по PIN» лучше, но видно что что-то стёрто. Облачные TTL текущий запрос не закрывают.

В RCQ сделали по-другому. Локальная история шифруется AES-256-GCM, ключ выводится из PIN’а через PBKDF2-HMAC-SHA256 на 400к раундов с per-install salt в keychain. Разные PIN’ы открывают разные хранилища.

400к раундов это около секунды CPU на iPhone, достаточно медленно чтобы offline-bruteforce был дорогой. Но реальная защита это длина PIN’а: 4-значный перебирается за десятки минут на M-чипе, 8-значный за месяцы. Default 6-8 символов.

Четыре режима

  1. Real PIN - открывает реальный аккаунт.

  2. Decoy PIN - открывает отдельный аккаунт с собственным UIN и SQLite. Не пустой экран (пустой это сигнал), а правдоподобно освоенный: пара контактов, несколько сообщений.

  3. Wipe PIN - тихо стирает оба SQLite, чистит keychain, дёргает DELETE /auth/account. Без подтверждений и прогресс-баров. Через 3 секунды приложение перезапускается как свежеустановленное.

  4. Biometric - опциональная вторая дверь к real. Не совмещается с decoy/wipe (скорее для удобства).

Честно про границы

Защищает от: казуального осмотра, принуждённой разблокировки, ситуации «5 секунд до того как заберут».

Не защищает от: forensic-лаб с offline-bruteforce’ом короткого PIN’а, jailbroken устройства с активным debugger’ом, человека рядом который видел как вы вводите PIN (разумеется).

Threat model правильный: «есть несколько секунд до того как кто-то откроет приложение, дальше я не контролирую устройство». Для «forensic с неограниченным временем» нужны другие инструменты. Главное из них: не пользоваться телефоном для чувствительных переписок вообще.

Стек живёт в RCQ, открытая бета на iOS. Код открытый: github.com/rcq-messenger/rcq-ios. Про маскировку самого факта установки приложения будет отдельно.

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии11

Открытый проект Go Interview Practice содержит обширный репозиторий для подготовки к собеседованиям на Go:

  • внутри — целая интерактивная платформа с задачами всех уровней. Могут готовиться как новички, так и профи.

  • ИИ‑интервьюер проверяет решения и сразу дает подсказки.

  • есть таблица лидеров, чтобы соревноваться с топами и видеть свой прогресс.

  • можно задать вопросы коммьюнити, если задача оказалась слишком трудной.

Теги:
Всего голосов 5: ↑5 и ↓0+5
Комментарии0

Как можно ошибиться при обработке ошибок в Go

Tе, кто до Go писал на языках с конструкциями try/catch, таких как Java и C#, наверняка испытывают легкое замешательство. Руки так и тянутся к try/catch заменителю — использованию recover в связке с defer — как к самому очевидному аналогу. Но это плохая практика и так делать не стоит. Давайте разберёмся, почему и как можно ошибиться при обработке ошибок в Go.

Теги:
Всего голосов 4: ↑4 и ↓0+5
Комментарии1

Сбалансированные Claude Code Safety Hooks с минимум false positive благодаря AST-парсингу Bash

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

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

Соответственно, когда хуков нет совсем или их мало, безопасность хромает - агент может уронить базу, сделать rm rf и тд, а если хуков слишком много , то... вы привыкаете клацать Enter на Allow, уже даже не читая о чем вообще сыр-бор. Поэтому, нужен тонкий баланс и хуками важно закрывать только действительно деструктивные, необратимые или критические действия.

Ну, и сразу второй нюанс - для блоков я предпочитаю использовать ask хуки вместо блокирующих, т. к. агенты нынче слишком умные и получив блокирующий хук, наверняка найдет способ обойти ограничение (особенно если прилетел какой-нибудь prompt-injection), тк хуки обычно весьма примитивны.

Короче-говоря, с учетом всех этих нюансов я написал свои opiniated-хуки, которые сам использую, они максимально сбалансированны по allow/ask с практически нулевым false positive - благодаря парсингу AST, а не regex'ам, которые обычно в хуках. Частично в основе лежит claude-code-safety-net весьма сильно переработанный и дополненный.

Внутри:
1. rmrm/unlink/shred вне cwd, по /etc, $HOME; через sudo, xargs, find -delete, pipe-to-shell.
2. infrakubectl, docker, terraform, helm, gcp.
3. dbDROP/TRUNCATE/DELETE через psql/mysql; redis-cli FLUSHALL/SHUTDOWN, supabase.
4. paas — Railway, Fly, Heroku, Vercel, Netlify с destructive-глаголами (PocketOS-класс).
5. gitreset --hard, clean -fd, checkout . / restore ., branch -D, stash drop/clear, push -f, push --delete.

Ссылка на репо: https://github.com/CodeAlive-AI/ai-driven-development/tree/main/hooks/balanced-safety-hooks

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

Кстати, для простого и корректного управления своими хуками у меня есть отдельный скилл hooks-management, который теперь поддерживает Claude Code, Codex и OpenCode.

Если вам нравится такой контент, то не премините заглянуть в мой Telegram канал, в котором я регулярно делюсь всякими полезностями про AI-Driven Development: https://t.me/+A-CrVovS0lczMDVi

Теги:
Всего голосов 3: ↑2 и ↓1+1
Комментарии0

Сделал необычную RTS на Ludum Dare 59 за пару дней

Выглядит примерно так
Выглядит примерно так

Игра написана на Go (Ebitengine), исходники на есть гитхабе.

Поиграть можно в браузере, ведь Ebitengine имеет неплохой экспорт в wasm. Она мало весит, быстро работает, и экспорт не требовал лишних усилий - это вам не шуточный игровой движок.

Я накидал небольшой шаблон для игр на стеке своих геймдев-библиотек. Его можно посмотреть тут: https://github.com/quasilyte/gscene-game-template.

С этим шаблоном старт начала работы над игровой логикой и "мясом" игры становится ближе. Это позволяет +/- выйти на удобство какого-нибудь Godot, где не нужно первые несколько часов настраивать как у нас обрабатывается input, звук и сцены. Я этот шаблон буду дорабатывать по мере участия в джемах, за каждую мини-игру у меня копится TODO на то, что еще там можно было бы улучшить.

Если тема разработки игр на Go вам интересна, заходите в наше русскоязычное сообщество в телеграме. Мы там обсуждаем всякие библиотеки для геймдева, свои игры, и всё такое.

Кстати, ребята из чатика тоже сделали свои игры на Ebitengine, вот они:

Теги:
Всего голосов 7: ↑7 и ↓0+8
Комментарии15

lazy-tmux — быстрый и «ленивый» менеджер сессий tmux

Весь мой рабочий процесс происходит внутри сессий tmux. Долгое время я использовал tmux-resurrect + tmux-continuum. Они работали… но с нюансами. Иногда терялись все сохранённые сессии, а при множестве активных сессий всё оставалось загружено в память, в частности, запущенные nvim процессы, которые поднимаю lsp, что со временем отъедало все больше и больше ОЗУ.

Я мне нужен был инструмент, который показывает все сессии в виде дерева, но загружает их только когда я впервые перейдёте в одну из них.

Так родился lazy-tmux, написанный на Go. Ключевые фичи:

  • Сохраняет текущую сессию, конкретную сессию или все сессии целиком. Снимки сохраняют окна, панели, layout, команды (например, npm, docker-compose, редакторы) и опционально scrollback историю шела.

  • Ленивое восстановление: поднимается только выбранная сессия. RAM не расходуется на всё сразу.

  • Интерактивный TUI браузер с деревом сессий, окон и панелей, таблицей с активными командами, временем последнего снимка, количеством окон/панелей и статусом сессии. Поддержка fuzzy search для быстрого поиска.

  • Навигация и полное управление сессиями и окнами с клавиатуры в TUI браузере сессий.

  • Гибкая сортировка сессий и окон через флаги --session-sort и --window-sort

  • Можно заменить встроенный TUI на fzf, использую облегчённый бинарник.

  • Автосейв через фоновый демон, периодически снимающий все сессии на диск.

  • Восстановление при старте tmux для автоматизации workflow.

Проект ещё молодой, но буду рад любой помощи и идеям по улучшению: GitHub issues

За моими новостями можно следить в Telegram-канале

Теги:
Всего голосов 3: ↑3 и ↓0+3
Комментарии0

Ближайшие события

SIP-exporter: eBPF-мониторинг SIP-трафика для Prometheus

Хочу поделиться своим open-source проектом для мониторинга SIP-трафика — SIP-exporter. Это сервис, который использует eBPF для захвата пакетов прямо в ядре Linux и экспортирует метрики в Prometheus.

SIP-exporter — сервис, который захватывает SIP-пакеты (UDP/5060-5061) через eBPF socket filter, использует ringbuf для zero-copy передачи в userspace, парсит SIP в Go и экспортирует 40+ метрик в Prometheus, включает готовый дашборд для Grafana.

Архитектура: SIP Traffic → NIC → eBPF socket filter → ringbuf → Go poller → SIP parser → Prometheus

SIP-exporter экспортирует: активные SIP сессии (диалоги), SIP запросы по методам: INVITE, BYE, REGISTER, OPTIONS... SIP ответы по кодам: 1xx, 2xx, 4xx, 5xx, 6xx-, сессии.

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

^ != <<

Знаете ли вы, что некоторые используют оператор '^' для возведения в степень? Хотя в ряде языков он действительно отвечает за возведение в степень, во многих популярных стеках разработки этот оператор выполняет операцию исключающего ИЛИ (XOR). Мы разберём, к каким последствиям приводит подобная путаница, и покажем реальный пример этой ошибки в механизме работы очереди внутри популярной библиотеки.

Теги:
Всего голосов 5: ↑5 и ↓0+6
Комментарии0

Китайские разработчики выпустили свой аналог OpenClaw, которому нужно всего 10 МБ ОЗУ. Легковесный проект PicoClaw:

  • полный контроль мессенджеров: ваш личный секретарь в Telegram и Discord, который реально разгребает завалы.

  • Deep Web Search: cёрфит по коду сайтов и выжимает только нужные данные без лишнего мусора.

  • поддерживает любые нейронки: GPT, Gemini, Claude.

  • манипуляция файлами: пишет, читает и правит конфиги на вашем диске прямо через консоль.

  • умеет мониторить новости, цены на товары и курсы валют по расписанию.

PicoClaw не требует огромных мощностей — ему нужно всего 10 МБ, а запускается он всего за 1 секунду.

Теги:
Всего голосов 4: ↑4 и ↓0+7
Комментарии1

Всем привет! Сделал Тетрис, в который можно играть в терминале. Получилось вполне залипательно)

Tetris
Tetris

Что умеет:

  • Все 7 фигур с wall kick при повороте

  • Превью следующей фигуры

  • Очки, линии, уровень

  • Скорость растёт с уровнем

  • Рекорд за сессию

  • Пауза, рестарт на ходу, экран game over

  • Центрируется в окне терминала

Видео геймплея
GitHub

Установка:

curl -sSL https://raw.githubusercontent.com/oakulikov/tetris/main/install.sh | bash

На Windows: открыть WSL/Ubuntu терминал и выполнить ту же команду.
Потом просто tetris.

Теги:
Всего голосов 9: ↑8 и ↓1+7
Комментарии5

Go vet не поможет! Статический анализ Golang проектов с помощью PVS-Studio

На нем написан Docker, Kubernetes, Gitea и многие другие проекты самых разных масштабов. Наверное, вы догадались, что речь идёт о Go. Мы никогда не писали об ошибках на Golang проектах, но настало время это исправить, ведь скоро выйдет анализатор PVS-Studio для Go!

Статические анализаторы являются довольно распространёнными инструментами в разработке. В Golang есть встроенный механизм статического анализа — go vet. Однако стандартные линтеры не всегда справляются. Для тех, кто с нами не знаком, мы — компания PVS-Studio, занимаемся разработкой одноименного статического анализатора для C, C++, C# и Java. В последнее время мы активно занимаемся разработкой анализатора для Go и уже скоро планируем выпустить открытую бета-версию.

В новом материале расскажем, какие нашли ошибки в популярных Golang проектах.

Теги:
Всего голосов 3: ↑3 и ↓0+4
Комментарии0

Открытый проект Go Katas поможет освоить язык программирования прямо Go. В репозитории решения есть сборник сотен ежедневных упражнений, чтобы довести навыки кодинга на Go до автоматизма, изучить конкурентность и Context, отработать Graceful Shutdown, а также защиту от утечек воркеров и правильный Fan-Out. Есть множество упражнений на Zero-Allocation парсинг, работу в sync.Pool и шардированные мапы.

Теги:
Рейтинг0
Комментарии0

Открытый мультиплатформенный проект Deletor умеет удалять ненужные и вредоносные файлы, кэш после рабочей сессии, улучшает производительность вашего SSD. Решение написано на Go.

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0