Golang вопросы собеседований
@notxxx1 - админ @Golang_google - Golang для разработчиков @itchannels_telegram - 🔥лучшие из ит @golangl - chat @golangtests - golang tests @golang_jobsgo - go chat jobs @ai_machinelearning_big_data - AI @data_analysis_ml РКН: clck.ru/3FmtKd
Show more📈 Analytical overview of Telegram channel Golang вопросы собеседований
Channel Golang вопросы собеседований (@golang_interview) in the Russian language segment is an active participant. Currently, the community unites 15 057 subscribers, ranking 8 285 in the Technologies & Applications category and 43 215 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 15 057 subscribers.
According to the latest data from 16 September, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by 53 over the last 30 days and by -2 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 23.93%. Within the first 24 hours after publication, content typically collects 8.22% reactions from the total number of subscribers.
- Post reach: On average, each post receives 3 603 views. Within the first day, a publication typically gains 1 238 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 16.
- Thematic interests: Content is focused on key topics such as git, docker, github, контейнер, sql.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“@notxxx1 - админ
@Golang_google - Golang для разработчиков
@itchannels_telegram - 🔥лучшие из ит
@golangl - chat
@golangtests - golang tests
@golang_jobsgo - go chat jobs
@ai_machinelearning_big_data - AI
@data_analysis_ml
РКН: clck.ru/3Fmt...”
Thanks to the high frequency of updates (latest data received on 17 September, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
context, редкие API - ошибки всё ещё легко выглядят «правдоподобно».
Например, AI может сгенерировать код, который:
- компилируется, но содержит race condition
- теряет context и продолжает работу после отмены запроса
- придумывает несуществующий метод библиотеки
- проходит часть тестов, но ломается под нагрузкой
Вывод отсюда не в том, что AI плохо пишет Go.
Куда важнее сам workflow:
repo context → change → compile → tests → static analysis → race detector → review → fix → PR
То есть модель не должна быть «источником истины». Источником истины должны быть кодовая база, документация и детерминированные проверки.
Для Go это особенно важно:
go test ./...
go test -race ./...
go vet ./...
staticcheck ./...
Плюс отдельные правила для context, concurrency, shutdown, retries и внутренних API.
Ещё сильнее схема становится, если один агент пишет код, а другой отдельно проверяет concurrency, архитектуру и edge cases.
Идея простая:
не нужно добиваться от AI идеального кода с первой попытки — нужно строить систему, в которой плохой код не проходит дальше без проверки.
Это уже не просто AI-assisted coding.
Это переход к agentic software engineering.bufio.Writer данные сначала попадают в буфер. Ошибка может возникнуть при Flush() или закрытии файла - уже после успешного Write().
Сохранить все ошибки можно через именованный результат и errors.Join:
func save(path string, data []byte) (err error) {
f, err := os.Create(path)
if err != nil {
return err
}
w := bufio.NewWriter(f)
defer func() {
flushErr := w.Flush()
closeErr := f.Close()
err = errors.Join(err, flushErr, closeErr)
}()
_, err = w.Write(data)
return err
}
Нужны пакеты bufio, errors и os.
Что здесь важно:
* сначала выполняется Flush(), затем Close()
* файл закрывается даже при ошибке сброса буфера
* именованный err позволяет изменить результат после return, пока выполняется defer
* errors.Join сохраняет все ошибки; errors.Is и errors.As умеют их проверять
* если ошибок нет, результат остаётся nil
Ловушка: defer errors.Join(err, f.Close()) закроет файл сразу - аргументы отложенного вызова вычисляются при регистрации defer.
Приём работает в актуальном Go и доступен с Go 1.20. Flush() передаёт данные нижележащему writer; для синхронизации файла с хранилищем нужен отдельный f.Sync().
errors.Join - https://pkg.go.dev/errors#Join
os.File - https://pkg.go.dev/os#File.SyncЗадача, под которую её делали, скучная, но дорогая. Долго работающий агент постоянно перечитывает свой контекст, и всё прочитанное приходится держать в KV-кэше. На длинных дистанциях он раздувается, забивает видеопамять и упирается в пропускную способность шин.В V4.1-Flash кэш сжат до 890 байт на токен, это вчетверо меньше, чем у V4-Flash, и в 437 раз, чем у первой версии DeepSeek. Каждому слою внимания заранее назначен один из трёх режимов: 🟢в полном слой считает свои ключи и значения сам; 🟢в режиме переиндексации берёт их у предыдущего слоя, но заново выбирает, на что смотреть; 🟢в режиме повторного использования не считает ничего - берёт и чужой кэш, и чужой выбор. Так хранить приходится в разы меньше. Сверху главный кэш держится в четырёхбитном формате FP4, и устойчивость к такой точности натренирована, а не добавлена после обучения. 🟡Causal Encoder-Decoder Метод вдохновлен майкрософтовской работой You Only Cache Once про переиспользование KV-кэша слоями. DeepSeek внесла в него структурные улучшения, чтобы поднять ёмкость кэша и глубину вычислений при его порождении. 40 слоёв разделены пополам: 20 на энкодер, 20 - декодер.
К и V для декодера не считаются в каждом его слое, а проецируются из последнего скрытого состояния энкодера.
Поэтому при разборе входа работает только первая половина сети - 8 млрд активных параметров на токен против 16 при генерации ответа.
Для агентов, у которых вход в разы длиннее вывода, это именно то, что нужно.🟡Бенчмарки
На DeepSWE v1.1 модель берёт 74,2% против 74,0 у Claude Opus 5 и 73,0 у GPT-5.6 Sol. На Terminal-Bench 2.1 - 90,6% (выше всех). На AutomationBench - 54,8% против 50,3 у Opus 5. А вот в Terminal-Bench 4.0, где нужны экспертные знания в науке, модель даёт 31,2% против 51,8 у Opus 5, то есть разрыв с топами на самых сложных задачах никуда не делся.Модель поддерживает настраиваемый уровень рассуждений от 1 до 100, в API это три пресета: low, high, max - они соответствуют значениям 50, 75 и 100. Шаблона чата в Jinja нет - вместо него советуют реализацию промптов на Python и отдельный набор Rust-библиотек. Сообщество на Hugging Face уже сделало квантованные версии практически под всё. 📌Лицензирование: MIT License 🟡Блогпост 🟡Веса 🟡Техотчет @ai_machinelearning_big_data #AI #ML #MMLM #MoE #Deepseek
wazero.
Что интересно:
- pure Go — без CGO
- без контейнеров и subprocess
- запуск sandbox меньше миллисекунды
- WASM-бинарник всего около 2,9 МБ
- можно ограничить память, время, число аллокаций и глубину рекурсии
- доступ к файлам и ОС идёт только через разрешённые Go-callbacks
- внешние функции работают через pause/resume
Главная идея — агент может написать один Python-скрипт, который вызывает ваши Go-инструменты, вместо длинной цепочки отдельных tool calls. Это уменьшает число обращений к модели и упрощает сложные agentic workflow.
MIT.
https://github.com/fugue-labs/monty-go
err := errors.New("oops")
err.Error()
error.Error(err)
дадут одинаковый результат.
А:
error.Error(errors.ErrUnsupported)
вернёт:
"unsupported operation"
Непривычный синтаксис, который легко принять за ошибку, хотя это обычная возможность языка.apiVersion + kind + name
- находить переименования ресурсов
- сравнивать директории
- подсвечивать изменения внутри строк
- работать как git external diff
- отдавать аннотации для GitHub, GitLab и Gitea CI
- маскировать чувствительные значения
- генерировать AI-summary изменений
Написан на Go и имеет всего одну внешнюю зависимость. На больших YAML-файлах авторы заявляют скорость до 1,5-1,9× выше ближайшего YAML-aware конкурента.
https://github.com/szhekpisov/diffymlДанил Руденко, 2ГИС — «Репозиторий здорового человека» Зачем нужен паттерн «Репозиторий», почему не стоит тащить в него бизнес-логику, с какими сложностями можно столкнуться при работе с транзакциями и как их решать. Никита Метелкин, Cloud.ru — «Как написать свой плагин для protoc-gen-go» Как устроен protoc и как с помощью Go и protogen генерировать собственный код из .proto-файлов. Александр Бухалко, MWS Cloud Platform — «Взросление OpenAPI-кодогенерации» Почему одной модели для запроса и ответа может быть мало, как внедрять частичное обновление данных, переходить на OpenAPI 3.1 и работать с полями в Go и Kotlin.Приходите на наши следующие мероприятия. У нас хорошо Другие инженерные инсайты от 2ГИС → в Telegram-канале RnD
go-linq показал новую версию библиотеки для Go 1.27, которая позволяет писать типобезопасные цепочки запросов в стиле LINQ:
From(users).
Where(...).
Join(...).
ToSlice()
Главная цель проекта - получить удобство LINQ без привычной цены в виде большого runtime-overhead.
По словам автора, производительность уже близка к вручную написанным циклам, а дальше её планируют ещё улучшать.
GitHub: https://github.com/ahmetb/go-linq
@Golang_google / Папка с полезными Go-ресурсамиJulius от Praetorian - open source-инструмент, который по IP:Port или URL определяет, какой AI-сервис работает на endpoint.
Он умеет распознавать больше 60 платформ:
— Ollama
— vLLM
— SGLang
— LiteLLM
— llama.cpp
— Hugging Face TGI
— NVIDIA NIM
— Open WebUI
— Dify
— AWS Bedrock и другие.
Пример:
julius probe 192.168.1.100:8080
Julius отправляет специальные HTTP-probes, анализирует ответы и пытается определить конкретный сервис, а не просто понять, что endpoint совместим с OpenAI API. Он также может показать доступные модели.
Написан на Go, работает локально и собирается в один бинарник.
https://github.com/praetorian-inc/julius goroutineleak в pprof, который помогает находить навсегда зависшие goroutine.
В стандартной библиотеке появился encoding/json/v2 с более строгими настройками и новым streaming API. Старый encoding/json теперь использует v2 внутри для более быстрого unmarshaling, сохраняя обратную совместимость.
Также добавили встроенный пакет uuid, поддержку постквантовых подписей ML-DSA и экспериментальный SIMD API.
Из приятного для повседневной работы: go doc теперь понимает package@version, go mod tidy сам приводит несколько require`-блоков в нормальный вид, а `go fix получил новые modernizer'ы.
https://go.dev/blog/go1.27
@Golang_google«Просто гарантируй, что в каждый момент времени пишет только одна машина».А на скрине как раз часть Go-кода LiteFS, которая продлевает этот lease и следит, чтобы узел не продолжал считать себя primary после истечения TTL.
