Помню когда впервые увидел проект CSS Zen Garden я был поражен тому как, используя только CSS, можно преобразить сайт (суть проекта в том, что при неизменной html верстке вы можете направить свой CSS который полностью преобразит сайт).

Сейчас есть еще более крутой ресурс - https://cssbattle.dev/

Мне кажется проекты по типу CodeWars, CssBattle - это офигенные тренажеры для прокачки навыков разработки, плюсом идет фан от того что ты делаешь.

Почему в 2022 году все еще задают этот дурацкий вопрос "Стоит ли учить Golang?". Да, я понимаю, что есть ощущение, что важно сделать правильный выбор при выборе языка, что это каким-то образом облегчит или усложнит вашу дальнейшую карьеру.
Но почему язык, который из года в год болтается во второй десятке ЯП, вызывает столько вопросов? Потому что его сделал Google? Потому что он маленький и быстрый? Или потому что все еще есть надежда что он "выстрелит"?

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

Язык Go должен был учесть многолетний опыт создания ЯП. И вроде как учел - минималистичный синтаксис, простое управление зависимостями, горутины, отличная сборка мусора и т.д. Но вот чего ему так и не удалось создать - имидж.

Именно имидж делает язык популярным. Все знают, что Javanoscript - язык для школьников, Haskell - для ботанов, PHP - для душнил, С - для хакеров. А для кого создан Go? Для тех кто мечтал, но так и не попал в Google?

Мое мнение, если что-то в АйТи не выстрелило за 10 лет, то ждать успеха уже не стоит. Go держится на имидже и деньгах компании, которая его создала, но у него нет своей "аудитории" и "месседжа". А без этого популярности быть не может.

Так что учите лучше Rust, а не Go! Но это все равно не спасет от боли, потому что разрабатывать софт больно на любом языке программирования.

https://docs.microsoft.com/ru-ru/azure/architecture/guide/architecture-styles/

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

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

Утиная типизация - прекрасна для небольших приложений, прототипов и демонстраций. Но в серьезном проекте она рано или поздно приведет к ситуации "да что за хрень у нас тут получилась?".

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

Мне по кайфу писать на typenoscript, не потому что это лучший язык на планете, а потому что я могу сам принимать решение о том насколько жесткая система типов мне нужна.

Хорошим дополнением к строгой типизации является "вывод типов", например, алгоритм Хиндли-Милнере, когда мы не указываем явно типы, а они "магическим" образом выводятся из наших "утверждений" или "действий". И этот вариант тоже приятно использовать, но все же в этом случае тратится чуть больше мозготоплива.

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

Есть очень распространенная ошибка про "утиную типизацию", что она такая же "мощная" как строгие типы. Но это не так! Строгие типы показывают не только "наличие" нужных свойств, но так же и "отсутствие" лишних свойств.
Утиная типизация показывает только наличие "нужных" свойств, но эффективно проверить, что других "ненужных" свойств у объекта нет - невозможно (потому что множество "других" свойств бесконечно).
Строгая типипзция - exactly -> exactly car
Утиная типизация - like -> like car