defer panic

Мои друзья разрабатывают инструмент для удобного и быстрого поиска работы. Чтобы сделать этот инструмент лучше, им нужна статистика о том, как люди разных IT-профессий в разных локациях подходят к этому вопросу. Информация, которой вы поделитесь, очень им поможет. А если сможете поделиться ссылкой на форму со своими друзьями и коллегами, поможете стократно. Даже если прямо сейчас не ищете работу, будет круто, если поделитесь прошлым опытом. Заполнение формы не займёт больше 5-10 минут. Ссылка на форму 👉 https://airtable.com/appq2bpZuurGX5TwL/pagNtE1vZJtRILBpd/form Форма анонимная, но при желании вы можете оставить свои контактные данные.

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

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

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

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

#include <iostream>

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. Изначально я хотел сделать что-то похожее на Лисп, поэтому нашел созвучный топоним, соответствующий одному из озёр в Тбилиси. Как вы понимаете, название потеряло былой смысл, но я решил ничего не менять.

Расскажу, как у меня сейчас обстоят дела. Во-первых, не так давно мы с вами пробили 5000 подписчиков на ютубе — спасибо вам большое! Во-вторых, я недавно спрашивал у вас, про что вам было бы интересно посмотреть видос. Вы предложили много разных тем. По большинству из них уже есть вполне неплохие ролики и записи докладов с конференций. Поэтому такие темы я отодвинул в бэклог. Но были и топики, про которые никто толком еще не говорил. Среди них — реализация своего интерпретатора для (скриптового?) языка. И я решил заняться роликом именно на эту тему. Да, это не пригодится вам на собеседовании напрямую. Да, это вообще ни разу не хайповая тема. Но реализация подобного проекта — это в любом случае неплохое упражнение для мозгов, да и вообще просто весело и интересно. Начал я пилить свой маленький язык за здравие, но пока что сильно замедлился из-за переезда. Надеюсь поскорее разобраться со всеми делами и снова взяться за ролик! ❤ • ютуб • бусти • патреон • платный канал

Вопросы? Периодически к постам приходят люди в комменты и задают там вопросы, которые не относятся к теме поста, но в целом в тему канала. Я подумал и решил: а почему бы не сделать рубрику с ответами на вопросы? Не в виде AMA-треда, а скорее еженедельного формата, где я отвечаю на один или несколько присланных вопросов. Такой формат вы могли видеть у Фёдора Борщева или Senior Software Vlogger. Давайте так: вы отправляете любой интересующий вас вопрос через форму, а я каждую среду на какой-то (или какие-то?) из них отвечаю. На вопросы, не получившие ответа в этот раз, возможно отвечу в следующий. Ссылка на форму: dfrp.cc/questions

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

Потихоньку возвращаюсь с перерыва с хорошими новостями. На следующей неделе стартует Podlodka Go Crew 3, в которой я снова принимаю участие как член программного комитета. Podlodka Crew — это формат онлайн-конференций, который проходят в течение недели (одна сессия утром, еще одна вечером). Тема этого сезона — «Работа с базами данных». Что будет в сезоне: ⭐️ Научимся сравнивать библиотеки и ORM вместе с Арсеном Абдусаламовым из Авито. Познакомимся с решениями как можно подключаться к базам данных и узнаем про «Go way» способ. ⭐️ Попрактикуемся обращаться с распределённым MySQL с помощью Vitess вместе с Ильёй Ушаковым. Ведь одного инстанса MySQL в какой-то момент может начать не хватать. Что же делать, если переходить на NoSQL совсем неохота? Vitess — ответ на этот вопрос, золотая середина между NoSQL distributed базами данных и проверенным опытом MySQL. ⭐️ Узнаем всё о продвинутых структурах данных в Redis вместе с Олегом Арутюновым из Контура. Углубимся в преимущества и недостатки подхода, разберёмся с миграциями данных и оптимизацией базы. ⭐️ Мокать или предзаполнять базы данных? На этот вопрос ответят спикеры из Ozon Fintech. И это будет не просто доклад, а баттл: не на жизнь, а на смерть. Разберёмся, когда какой подход выбрать и стоит ли ограничиваться только одним. 🎁Бонус: публичный собес по работе с PostgreSQL. И это, естественно, не все сессии сезона. Залетай за билетом, чтобы не пропустить специализированную конференцию для Golang-разработчиков Для моих подписчиков есть промокод на скидку 500 ₽ — go_crew_3_deferpanic #партнерскийпост

В GoLand и другие IDE от JetBrains завезли две важные (или просто интересные) фичи. 1. Data Flow Analysis (DFA). Статический анализ кода, позволяющий вычислять возможные значения переменных и обнаруживать потенциальные ошибки, такие как nil pointer dereference, бесконечные циклы и прочее. По сути IDE прикидывает данные, на которых программа поведёт себя некорректно. 2. Full Line Code Completion. Теперь GoLand может дополнять ваш код не «точка за точкой», а сразу всю строку. Это делается с помощью AI, но полностью локально. По сути JetBrains вытащили часть функциональности своего AI-ассистента и поместили прямо в IDE. ❤ • ютуб • бусти • патреон • платный канал

Как научиться решать самый главный конфликт между бизнесом и разработкой? Бизнес нанимает команду разработки, которая стоит кучу денег. Сначала все идет хорошо, задачи пилятся, деньги делаются. Но чем больше процессов, людей и задач, тем быстрее вещи начинают ломаться, а разработка — становиться черным ящиком. Закинул туда задачу и не знаешь, что с ней, будет/не будет, когда и можно ли вообще запускать рекламную кампанию. Разработка в это время воет от количества костылей и наколеночных решений, которые нагородили в спешке. Ресурса на починку ей не дают — просят новые фичи. Но как выдавать фичи, если ты стоишь на зыбком песке и любое движение все ломает? Ты говоришь, а тебя не слышат. Тупик. Конфликт возникает из-за разности мышления двух разных миров: бизнесу сложно понимать программистов, а программистам — бизнес. «Стать Тимлидом 2.0» — курс, в котором эту разницу проясняют и подробно разбирают: Федя Борщев — со стороны разработки, а Марьяна Онысько — со стороны бизнеса. А попутно курс помогает разобраться с ролью тимлида, научиться вести переговоры, понимать собеседника, строить команду (нанимать, увольнять, выстраивать доверительные отношения), работать с ответственностью. И много всего другого. Старт 11 апреля, учеба длится 5 недель. Будет домашка с обратной связью и ланчи с крутыми спикерами. Промокод на скидку 10% – deferpanic10. Смотреть программу → #партнерскийпост

👣➡️👣 Наконец-то решил свитчнуться на Rust. Go окончательно мне надоел. В чём же дело? Во-первых, в Go мне не хватает выразительности. Это очень бедный на синтаксис язык, и каким бы гениальным разработчиком вы не были, вся красота и глубина вашей мысли будет утоплена в абсолютно дубовом и прямолинейном синтаксисе Go. Когда же я пишу на Расте, а потом читаю получившийся код, мои глаза отдыхают. Во-вторых, Rust в отличие от Go ⚡️ молниеносно быстрый 🚀. Если бы мне надо было написать прошивку для аппарата, который запускают на Луну, я бы написал её на 🚀 Расте. Если мне нужно будет написать самый быстрый и эффективный сервис на свете, какой бы сложной внутри логика не была, я напишу его на ⚡️ Расте. Если мне нужно будет написать движок для своего блога, я напишу его на ⚡️ Расте 🚀. Если мне нужен будет скрипт для CI/CD-пайплайна, я напишу его на 💻 Расте 💀. В-третьих, сборщик мусора — это прошлый век. Я не могу придумать более уродливую и неказистую конструкцию в программировании, чем сборщик мусора. Это не просто костыль, это король костылей. Тратить впустую cpu time, создавать лишнюю задержку в ответах бэкенд-сервисов, сжигать драгоценную энергию... Извините, но это не про меня. В-четвертых, как же я устал от механизма обработки ошибок в Go! После каждого чиха разворачивать результат функции и проверять наличие ошибки — это какая-то дичь. Хорошо, что в Расте по-другому! Я могу назвать ещё много причин для перехода с Go на Rust — хватило бы на объём всей трилогии Лю Цысиня «Память о прошлом Земли». Но идею, думаю, вы поняли. С этого момента все посты и ролики на ютуб-канале будут посвящены либо только Расту, либо сравнениям Go с Rust в синтетических тестах. ⚡️🚀 Viva La Rust!