Язык Go сейчас очень популярен, и на него переходит много разработчиков с Java, C#, PHP и Python.

У многих возникают проблемы с Go по одной любопытной причине: все кажется слишком простым. «Где наш фабричный метод?», «Где наследование?», «Где привычные паттерны?».

Больше 30 лет назад «банда четырех», она же GoF, выпустила книгу Design Patterns, где впервые описала 23 паттерна, которые сейчас считаются классическими. Это была революция: раньше приходилось долго объяснять, что ты делаешь в коде, а теперь можно просто сказать: «Я пишу адаптер».

Пару раз я встречала в описаниях вакансий на позицию Go‑разработчика требования знать ООП‑паттерны. Или слышала мнение, что Go частично реализует ООП, или что это вообще недо‑ООП язык. При этом сами разработчики языка на вопрос «Является ли Go ООП языком?» отвечают уклончиво: и да, и нет.

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

Статья про то, как я связал Obsidian с Claude и Codex через домашний сервер, CouchDB и MCP, а по дороге поймал баг, который тихо съедал куски заметок.

🔧 Это не про «как всё стало умным», а про нормальную историю с self-hosted, авторизацией, странностями LiveSync, мобильными клиентами, CORS, OAuth 2.1.

Внутри выводы о том, как давать AI доступ к базе знаний и не потерять эти самые данные.

Заходите, читайте и делитесь своим опытом ❤️