#prog #art

#prog #python #meme

Ну спасибо

Наконец-то смержили мой MR, который висел уже два месяца. И он даже попадёт в ближайший релиз.

#трудовыебудни

Я часто ругаюсь с людьми, причём делаю больно не преднамеренно. Совсем недавно я сделал это ещё раз. Более того, я подвёл человека, который от меня зависит. И уделяю мало внимания тем, кто в моём внимании нуждается.

Я делаю недостаточно. На работе я большую часть времени пинаю балду, вне работы тоже. Мои каналы простаивают без авторского контента. Своим родственникам я помогаю (в той или иной мере) мало и неохотно. По дому от меня помощи не дождаться.

Я не занимаюсь собой. Список "на почитать" лишь растёт, но почти не убывает. Своим телом я тоже не занимаюсь, не смотря на весомые стимулы. Не занимаюсь физической нагрузкой и забиваю на медицинский уход.

Я ничтожен. Все мои постоянные обязанности мелочны и не обременительны. Мир постоянно напоминает мне о том, какой я не взрослый и не самостоятельный, причём романтических отношений это тоже касается. Самое страшное, что меня это в какой-то мере устраивает.

Хочется просто ничего не делать и оставаться лежать в кровати, прижимая к себе плюшевую акулу — единственное существо, которое я могу себе позволить обнять.

#article

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

media-xyz.com/ru/articles/1098-otkuda-berutsia-toksichnye-igroki-i-kak-s-nim

О, а нас тут уже 900, клёво! Приятно сознавать, что стольким людям нравится мой канал. Интересно, удастся ли набрать тысячу к юбилею?

Советую посмотреть ещё раз, благо там тоже праздник: первая сотня подписчиков

#prog

Немного опыта работы с #go

Первое же, чем я отстрелил себе ногу в го - отсутствие каких-либо компайл-тайм гарантий относительно гонок. Всё как в старом добром си - что-то меняешь конкурентно, будь добр взять мьютекс. Забыл - сам себе злобный буратино. Отсутствие константности в го усугубляет проблему.

Второе, чем я себе отстрелил ногу уже три раза - это утечки. В го нет raii, так что забыл позвать defer close(), например, на grpc клиент - опять сам себе буратино. Парадоксально, что GC не спасает от утечек :)

Третье, на что я напарывался уже пару раз в проде - это дурацкий захват переменной в цикле. Типа хочешь создать 1000 каких-то объектов через grpc, пишешь без задней мысли Name: &obj.name (где obj - переменная цикла), и получаешь запрос на создание 1000 объектов с одинаковым именем. Можно сказать, что сам дурак, но вне цикла & это по сути аллокация объекта на куче, так что само напрашивается. Здесь borrow checker без GC сработал бы намного лучше - у меня бы не скомпилился код, где я вместо аллокации на куче случайно захватил локальную переменную. GC же тут только мешает, делая не то, что я ожидаю.

В-четвёртых, кмк парадигма "любой объект можно инициализировать нуллом" неудачная. Например, хочу написать тип

type Foo struct {
inner SomeIface
}

Мне в этом типе надо во всех методах проверять, что inner не nil (ведь клиент может написать просто var Foo foo), чтобы хотя бы внятную ошибку дать (типа "используйте NewFoo для конструирования"). Или забить, тогда будет паника с nil dereference, причина которой может быть клиенту неочевидна.

Это основное, по мелочи ещё тоже есть. Например, по типу не понятно, это struct или interface (от этого зависит nullability). Про nullability ещё на нравится, что очень много типов могут быть null (указатели, интерфейсы, мапы, слайсы). Намного лучше кмк, когда типы не nullable, но есть option. Банально не понятно, если функция возвращает nullable тип - стоит ли проверить на null или нет? Я обычно стараюсь проверять, так что возникает много бойлерплейта

Го мне всё равно нравится больше плюсов, но расту на мой вкус он сильно проигрывает по многим фронтам. Мне язык кажется эдаким осовремененным си со сборкой мусора и горутинами, чего-то принципиально нового в нём вроде бы нет, кажется by design :)

Ещё вспомнил общий бич всех языков с GC - отсутствие внятной семантики владения. Здесь го даже переплюнул конкурентов тем, что даёт возможность неявно сделать shallow copy объекта - когда веохнеуровневый объект скопировался, а все содержащиеся в нём интерфейсы/указатели/мапы/слайсы остались ссылками на старые объекты) Даже в Питоне кмк получше, там обычно все объекты передаются по ссылке, пока ты явно не сделаешь иного

Про многопоточность, кажется best practice это просто строить код на каналах: нет общего стейта - нет проблем. Но есть сценарии, когда общий стейт всё-таки нужен, и тут мне не известно никакого решения настолько же системного, как Send/Copy и семантика владения в Rust.

Про raii, один гофер мне сказал, что вместо в go 2.0 обещают дженерики с With<T>(func() error), это должно смягчить проблему, но зато появляется лапша из коллбеков) Плюс при работе с объектом мне всё равно надо самому напрягаться и смотреть, надо ли с ним использовать этот With или нет. В теории, линтеры могли бы ловить проблемы типа отсутствия defer obj.Close(), но сейчас они этого не делают и вроде даже понятно, почему: сложно сформулировать какое-то правило, которое бы не страдало от высокого рейта false positive/false negative. Но вообще, на мой вкус, это перекладывание ответственности на линтер не есть хорошо - лучше пусть будет деструктор на уровне языка)

Про захват переменных, линтер иногда что-то такое отлавливает, иногда нет, по-разному бывает)

Про nullability, кажется, можно любо включить режим паранойи и проверять везде и всё, либо положить болт, либо выбрать какой-то вариант посередине. Если код мой собственный для моего же пользования, я предпочитаю делать вид, что null initialization не бывает, и везде инстанциирую через функции а-ля NewFoo(...). Пару раз меня такое подводило кстати :(