Всем доброе время суток. Я пишу всякое на Go в Ви.Tech (IT-дочка ВсеИнструменты.ру) и, честно говоря, обожаю этот язык. Когда говорят о проблемах Go, обычно вспоминают отсутствие наследования или своеобразную обработку ошибок. Гораздо реже речь заходит о том, что, на мой взгляд, действительно можно отнести к проблемам.

Я пишу всякое на Go в Ви.Tech (IT-дочка ВсеИнструменты.ру) и как и все, люблю подискутировать на технические темы.

У этой заметки сложная судьба, мне загорелось написать ее еще летом, но совершенно не хотел говорить об очевидных вещах и писать миллион первую статью со ссылкой на гугловский go code review comments. Тема уже разобрана всеми кому не лень, на русском языке вот у  Николая @JustSkiv Тузова, есть замечательное видео на его ютуб канале, раскладывающее по полочкам, для чего это нужно.

Последний дисклеймер и перейду к сути: тема на самом деле очень обширна и я сознательно сконцентрировался на одном аспекте (неуместные определения интерфейсов). Буду рад, если продолжим общение в комментариях, очень не хватает Хабра начала 10-х годов, с живыми, а иногда и крайне горячими, инженерными дискуссиями.

Я пишу всякое на Go в Ви.Tech (IT-дочка ВсеИнструменты.ру) и люблю периодически изучать предлагаемые нововведения. Недавно мы собирались внутренним комьюнити, обсуждали интересные пропозалы из гитхаба Go. Среди прочего — изящный и крайне перспективный Proposal #74609 Deadlock detection by using the garbage collector Собственно, о нём сегодня и пойдёт речь.

Мотивация

Горутины могут блокироваться — например, при попытке захватить уже занятую блокировку или отправить сообщение в канал, по которому ещё никто не читает. Если все горутины заблокированы, рантайм Go завершает выполнение с фатальной ошибкой о глобальной взаимной блокировке (deadlock).

Однако гораздо чаще встречаются частичные дедлоки (также известные как утечки горутин), когда часть, но не все горутины блокируются навсегда. В отличие от глобальных дедлоков, которые случаются редко, частичные дедлоки — частая проблема в реальных приложениях из-за непредсказуемых путей исполнения и планирования.

На текущий момент Go не предоставляет встроенного механизма для обнаружения или устранения частичных дедлоков. Поскольку стандартный сборщик мусора не распознаёт такие ситуации, он не может освободить ни память, занятую “мёртвыми” горутинами, ни ресурсы, достижимые только через их стеки.

Наиболее продвинутыми динамическими средствами обнаружения частичных дедлоков являются Goleak и LeakProf:

Меня зовут Дмитрий Солдатенко, я разработчик в Ви.Tech, IT-дочке ВсеИнструменты.ру. И теперь, когда формальное представление завершено, хочу поделиться своим, местами не очень формальным, батхертом по поводу слабых указателей.

Предполагается, что вы пишете на Go и хотя бы на уровне чтения релиз-ноутов знакомы с концепцией слабых указателей (weak pointers).

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

Если вы читаете эту статью, значит, меня держат в плену я всё-таки довёл её до публикации, и она не повторила судьбу многих других. Постараюсь кратко и тезисно, пока мне не стало лень писать. =)

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

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

Одной из ключевых особенностей Go является ориентация на читаемость и краткость кода. Это проявляется как в конструкциях языка, так и в стилевых рекомендациях, принятых сообществом и разработчиками языка.

Короткие имена переменных — важная часть этой философии. В отличие от языков, где длинные и описательные имена переменных могут быть нормой (например, PHP или Java), Go поощряет использование коротких имен, особенно в случаях, когда их смысл легко понять из контекста.