👀 Мои друзья из DevCrowd снова проводят исследование о Go-разработчиках. Несколько тем этого исследования:

- Что входит в обязанности и каких навыков не хватает
- Сколько в среднем зарабатывают в профессии в зависимости от грейда
- Какие инструменты, сервисы наиболее популярны
- Что читают, слушают и смотрят для профессионального развития.

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

Пройти опрос

В этот понедельник, 28 октября, стартует новый сезон Podlodka Go Crew. И я как член программного комитета приглашаю вас. В этом сезоне будем много говорить про архитектуру: 📎 покажем, как с помощью Temporal организовать понятную архитектуру, отражающую бизнес…

В этот понедельник, 28 октября, стартует новый сезон Podlodka Go Crew. И я как член программного комитета приглашаю вас. В этом сезоне будем много говорить про архитектуру:

📎 покажем, как с помощью Temporal организовать понятную архитектуру, отражающую бизнес-процессы;
📎 посмотрим, как оптимально реализовать DI на своем проекте;
📎 обсудим на примерах подходы к генерации кода из спецификации;
📎 разберемся, как упростить написание кода и тестов с помощью различных фреймворков и инструментов.

Как и в прошлые разы, разыгрываю две проходки. Условия простые: напишите в комментариях свой самый большой архитектурный факап — т.е. когда принятое давно архитектурное решение выстрелило вам в колено сегодня и очень больно. Среди поделившихся своей историей методом великого рандома будут выбраны два победителя примерно через сутки.

Если вам не удалось выиграть, вы всегда можете приобрести билет со скидкой, если при покупке назовете мой промокод на 500 ₽: go_crew_4_WROKD0

Купить билет 👉 тык

Подписываюсь под каждым словом Николая.

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

Можно возразить, что рекламодатели сейчас придут, и всё станет супер. Но не станет.

Во-первых, рынок «Россия» и рынок «весь мир» сравнивать просто глупо. За пределами России живёт ещё огромное количество людей, которые говорят по-русски (даже до 24 февраля 2022) — это десятки миллионов людей. Кто-то не говорит по-русски, но готов смотреть контент на русском с субтитрами (как минимум на моём канале такое бывает). И многие из них смотрят контент, сделанный в России. Станут ли они ради этого переходить на российские видеохостинги, когда весь остальной контент для них живёт на Ютубе? Не факт.

Т.е. с точки зрения аудитории мы имеем дело с меньшим рынком, на котором меньше конкуренции среди рекламодателей. Можно было бы дублировать контент с Ютуба на рутубы с вк видео, как это делают уже давно многие. Но я этого делать принципиально не хочу — это лишняя работа в пользу площадок, которые противоречат моим принципам.

Во-вторых, если мы посмотрим на соседнюю индустрию — музыкальные стриминговые площадки — то увидим, что та же ВК Музыка платит какие-то совсем смешные крохи даже по сравнению с копейками, которые платят остальные. Будет ли другая ситуация с ВК Видео? Я что-то сомневаюсь.

А если говорить даже не про деньги, то ВК Видео и Рутуб — просто говно. Попробуйте залить хоть что-то на Рутуб. И да, мы почему-то вообще свыклись с тем, что блокировка ключевых ресурсов — это ок. Это не ок нигде и никогда.

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

Я недолюбливаю Гугл, но как минимум две классные штуки он сделал — это Ютуб и Голанг.

Telegram

Николай Тузов

Я надеюсь, уж мне то не нужно переживать о блокировке ютуба, разберётесь с VPN, не маленькие? ***💪*** В любом случае, я никуда с этой плащадки не уйду. Как и у большинства русскоязычных блогеров, у меня примерно 60% зрителей из РФ, и вот для оставшихся 40% я в…

Неделя с Zed

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

Сразу скажу, что поиграться с главной фичей я так пока и не смог. Речь про возможность подключиться к коллеге/другу и работать над одной кодовой базой вместе так, как если бы это был гугл-док. Попробую обязательно эту штуку на каком-нибудь пет-проекте. Кроме этой фичи в остальном у Zed все те же плюсы и минусы, что у других «простых» редакторов типа Саблайма и Вима.

Zed не отвлекает по пустякам. Когда я открываю редактор, скорее всего я это делаю, чтобы что-то редактировать. Вместо этого почти все редакторы начинают меня засыпать хламом в стиле «Смотри, что у нас нового — куча фичей, которые ты никогда не будешь использовать» и «У плагина X появилась новая версия». Я никогда не понимал, почему я должен принудительно видеть все эти уведомления. Хуже только, когда их показывают не при старте, а просто внезапно поверх кода, когда я на нём сфокусирован. Это одна часть. А вторая часть — нагромождение тулбаров и иконок, каждая из которых мне пригождается в лучшем случае один раз за день. При том, что есть Command Palette, через который я всегда могу найти всё то же самое. Более того, обычно я так и делаю, даже если иконка у меня перед лицом. Так вот, в Zed этого всего слава богу пока нет, по крайней мере в таких масштабах.

Zed очень быстрый. Я имею в виду, очень быстрый. Это может быть не так заметно, когда пользуешься им непосредственно. Но когда возвращаешься в VS Code или IDEA, сразу чувствуешь, что потерял.

Но за скорость приходится платить: у Zed нет внутри продвинутого анализа кода, как у IDEA — по крайней мере для Go. Поэтому уровень понимания кода будет, как у любого другого редактора, который поддерживает LSP и интегрируется с Go через gopls. Мне такого уровня в большинстве случаев хватает, но как и в Виме с VS Code, gopls иногда сходит с ума и засыпает меня ошибками, которые не имеют никакого отношения к реальности. Обычно помогает принудительный рестарт gopls. Возможно, с другими языками всё получше. Но опять же, это скорее проблема gopls, а не Zed.

Я запускал Goland только когда мне нужно было запрыгнуть в дебаггер или сделать какой-то нетривиальный рефакторинг. Для этих задач лучше Goland ничего пока нет.

В общем, поживу в Zed ещё неделю, пока скорее нравится.

❤ • ютуб • бусти • патреон • платный канал

Что за язык будем реализовывать в ролике?

Можно было бы взять существующие простые языки типа Луа или вообще пойти в сторону языков не для программирования, а для данных типа JSON/TOML/YAML и т.д. Разница, к слову, только в объёме работы. Но в качестве примера для ролика я посчитал даже Луа слишком большим языком, а парсить форматы данных не так интересно. Поэтому будем пилить свой собственный скриптовый язык программирования (однажды программист не изобрёл велосипед, и больше его никто не видел). Сразу скажу, что то, что я сейчас буду рассказывать — моё видение в данный момент. К моменту выхода ролика всё может поменяться ещё 100 раз.

Язык будет предельно минималистичный. Простой настолько, насколько это возможно. Это относится как к синтаксису, так и к фичам. Давайте сначала разберёмся с синтаксисом. Например, есть языки со значимыми отступами типа Питона:

```

def greet(name):
print("Hello,", name)

```

Решение сделать синтаксис именно таким понятно — такой код кажется менее шумным по сравнению с классическим си-лайк синтаксисом:

```

#include

void main(string name) {
std::cout << "Hello, " << name << std::endl;
}

```

Я же хочу пойти в сторону ещё большей лаконичности:

```

fun greet name
print "Hello, " name

```

Тут сразу две идеи. Первая — использовать значимые отступы вместо фигурных скобок или иных способов обозначения границ блока кода. Вторая — там, где можно однозначно распарсить выражение без скобок и прочих символов, позволять не использовать эти символы. Естественно, тут сразу всплывает множество эдж-кейсов. Например, что если я захочу передать в вызов функции вызов другой функции? Тогда такое выражение заключается в скобки для избежания неоднозначности прочтения:

```

print "Hello, " (getNameByUserID 42)

```

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

Всякие операторы логических выражений тоже пишутся словами:

```

&& → and
|| → or
! → not

```

Единственное исключение — знаки равенства и неравенства:

```

!= == < > <= >=

```

А, да, ещё оператора else не будет. Вообще. Я тут посмотрел, и понял, что я не использовал этот оператор прям очень давно. Обычно когда руки почему-то на автомате набирают else, я сразу выношу блок с условиями в отдельную функцию, а там уже всё решается ретёрнами. Для кейса, когда нужно рассмотреть много разных вариантов скорее всего сделаем что-то типа switch\-case.

Фич в языке тоже по-минимуму:
- Типы
-- Простые типы данных: числа, целые числа, строки и логический тип
-- Составные типы данных: список, мапа
-- Сущности (entities) — как структуры, только поля могут быть уложены в памяти разреженно
-- Енамы (такого даже в Go нет!)
- Функции
- Конструкции для управления логикой
-- Условия (только if)
-- switch-case
-- Циклы
--- со счётчиком
--- с условием
--- по коллекции

Типы динамические, указывать их явно не нужно (и не факт, что можно будет). Для полей сущностей типы определяются через значения по умолчанию:

```

entity Player
name = ""
x = 0.0
y = 0.0
hp = 100

```

Импортов и вообще системы управления модулями не будет — всё-таки язык встраиваемый. По этой же причине стандартная библиотека предельно аскетичная — немного математики и хэлперы для работы со встроенными типами.

Рабочее название — Lisi. Изначально я хотел сделать что-то похожее на Лисп, поэтому нашел созвучный топоним, соответствующий одному из озёр в Тбилиси. Как вы понимаете, название потеряло былой смысл, но я решил ничего не менять.

У меня есть несколько сценариев для роликов разной степени готовности. Но хотелось бы узнать у вас, на какую тему вы бы хотели увидеть ролик от меня? С одной стороны не очень хочется записывать видео, которое просто пересказывает документацию. С другой стороны я вижу, что скринкасты с написанием какого-то сервиса/программы за 1.5-2 часа неплохо зашли. Хоть скринкасты сильно проще монтировать (буквально запустить auto-editor и пройтись да поправить автоматику), предварительной работы там всё ещё много. Возможно, вам интересен не только Go, но и какие-то другие языки/технологии/дисциплины?

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

P.S. Ролик о планировщике Go не предлагать — на эту тему Николай Тузов уже готовит нетленку.

?➡️? Наконец-то решил свитчнуться на Rust. Go окончательно мне надоел. В чём же дело?

Во-первых, в Go мне не хватает выразительности. Это очень бедный на синтаксис язык, и каким бы гениальным разработчиком вы не были, вся красота и глубина вашей мысли будет утоплена в абсолютно дубовом и прямолинейном синтаксисе Go. Когда же я пишу на Расте, а потом читаю получившийся код, мои глаза отдыхают.

Во-вторых, Rust в отличие от Go ⚡️ молниеносно быстрый ?. Если бы мне надо было написать прошивку для аппарата, который запускают на Луну, я бы написал её на ? Расте. Если мне нужно будет написать самый быстрый и эффективный сервис на свете, какой бы сложной внутри логика не была, я напишу его на ⚡️ Расте. Если мне нужно будет написать движок для своего блога, я напишу его на ⚡️ Расте ?. Если мне нужен будет скрипт для CI/CD-пайплайна, я напишу его на ? Расте ?.

В-третьих, сборщик мусора — это прошлый век. Я не могу придумать более уродливую и неказистую конструкцию в программировании, чем сборщик мусора. Это не просто костыль, это король костылей. Тратить впустую cpu time, создавать лишнюю задержку в ответах бэкенд-сервисов, сжигать драгоценную энергию... Извините, но это не про меня.

В-четвертых, как же я устал от механизма обработки ошибок в Go! После каждого чиха разворачивать результат функции и проверять наличие ошибки — это какая-то дичь. Хорошо, что в Расте по-другому!

Я могу назвать ещё много причин для перехода с Go на Rust — хватило бы на объём всей трилогии Лю Цысиня «Память о прошлом Земли». Но идею, думаю, вы поняли. С этого момента все посты и ролики на ютуб-канале будут посвящены либо только Расту, либо сравнениям Go с Rust в синтетических тестах.

⚡️? Viva La Rust!