А еще, есть очень красивый SDK для github на Go от гугла.
Тут круто всё структурировано и хорошо расписаны примеры использования.
Именно отсюда узнал про кастинг типов(а не type assertion) в Go.

Ссылка на пример кода с кастингом типов.
https://github.com/google/go-github/blob/94d2fbbfba4de5018c7b19da5bc99aa1e9769f2c/github/github.go#L266

Неочевидный stack overflow.
Кто понял - молодец. Пишите в комменты свои варианты :)

https://play.golang.org/p/Iriey5njCch

Захотелось странного. Купить/собрать Intel NUC или подобное. Игровой пк не собрать из-за майнеров и отсутствия денег отсутствия времени играть и пускать слюни. Жить на ноутах все скучнее и скучнее (вот на днях соусом MBP16 утопил, я не шучу).

Пролистываю 1к сохраненный новостей заметил пост, где автор собирает Intel NUC https://dimamoroz.com/2021/03/09/intel-nuc-for-development/

Возможно у кого-то похожая железка и/или такое мелкий ПК в ящике стола. Расскажите, зачем используете и что он вам в итоге даёт. И когда его не стоит покупать)

Noice !
https://www.instana.com/blog/practical-golang-benchmarks/

https://dave.cheney.net/2016/03/19/should-methods-be-declared-on-t-or-t

Вот пост от Dave Cheney. Тут он объясняет, почему лучше создавать методы с ресивером *T, а не T.
Если вкратце, то так нужно делать всегда, кроме случаев, когда нужно копировать значение T.
Но меня интересует скорее апендикс в конце поста:

If the method does not mutate its receiver, does it need to be a method?

Если я хочу писать на го что-то похожее на ООП. И например, создаю тип какого-то юзкейса, который инициализируется при помощи фабрики, в которую передаются какие-то аргументы, а потом использую данные, которые у меня есть в этом юзкейсе. Делаю я это по двум причинам:

1. Удобнее читается, аргументов меньше.
2. Можно создать абстракцию этого типа.

Вопрос, стоит ли так вообще делать тогда, если я никак не мутирую значения в этом типе? Интересно ваше мнение.

Решил нарисовать гофера в плаще. Вот.

https://youtu.be/7EmboKQH8lM

Походу много кто это видел, но это очень кайфовое выступление о культуре хорошего кода.

Одна из главных, но не единственная, цитата, которая мне очень понравилась:

Intermediate working state.

То есть, «промежуточное рабочее состояние». Отсылка к тому, что работа программиста - не просто писать код, который работает, но и код, который будет чистым, легко поддерживаемым и понятным для человека, который будет его читать в будущем (в том числе, и сам автор).

Это очень вдохновляюще, если честно. Техническая ценность этого спича - огромна, но в нем есть и видимая, но не очень очевидная, моральная и этическая пасхалочка, которая действительно может мотивировать тебя/меня писать хороший код и углубляться в детали.

В компании в которой я работаю есть много классных вакансий.

https://djinni.co/jobs/company-bitmedia-labs-bfdbb/
Будет классно, если при общении с рекрутером упомянете, что вы от меня.

Fullstack Middle
Компания: Bitmedia Labs
Стэк: Node, React
Денег: $1200-2300
Kiev, Ukrain

Команда Bitmedia Labs ищет FullStack-разработчика для проекта на React/Node.js.

Backend Junior
Компания: Bitmedia Labs
Стэк: Go
Денег: $1200-1800
Киев, Украина

Команда Bitmedia Labs готова взять в команду разработчика на должность Golang Developer.

Ох и класс конечно.

https://twitter.com/inancgumus/status/1397168068955021312

У этого же чувака нашел страницу с Go Proverbs, оказывается, она есть.

https://go-proverbs.github.io/

Новый цензурный способ сказать о том, что ничего хорошего не произойдет.

Я собираюсь пожаловаться, боже мой, в мире так много людей.