Крошка джун к лиду пришел, и спросила кроха
что такое хорошо, и что такое плохо

Лид ответил, не тая
Всё айти - одна херня

Джава память всю сожрёт,
Еле-еле стартанёт

Го придуман для тупых
Скала, Хаскель - для больных

Асм пойдёт задроту-гику
Rust - отрада контрол фрика

PHP оставим деду,
Пусть там выпьет за победу,
Типа сайтов громадьё
(но на деле всё старьё)

Скрам говно, фронтенд говно,
Уведут проект на дно

Чтоб понять Апаче Кафку,
Почитайте Франца Кафку

Только клод - моя подмога,
Жаль, что ёбнутый немного.

Лид - давно не разработчик
Жалкий таскообработчик:
Претворяется спецом,
Сделав умное лицо

Все владельцы самодуры
А эйчары часто дуры

Каждый долбаный админ
В мыслях тёмный властелин

Проджект менеджер к чему
Непонятно никому

Остальным одна забота:
Делать видимость работы

А хорошего в айти
Адеквату не найти

(С) 🫥 Cross Join
⠀

В последнее время всё чаще слышу "как вы живёте в Go без фреймворков, это же неэффективно"

Ну блин, а зачем он нужен? Если пишешь типичный микросервис, REST + кафка, например:

http-сервер встроен прям в стандартную либу, он работает просто отлично.

Роутинг http-запросов есть в стандартной либе, если надо какие-то расширенные возможности, полезные мидлвары и т.д - юзаешь либу chi или аналог

Логгер прекрасный встроен из коробки (json, уровни логирования и т.д).

Ну кафка да, подключаешь либу.

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

Валидация данных делается с помощью либы.

ORM в мире Go редко используется, но если прям надо, ну подключи gorm

Всякие там dependency injection системы в микросервисах вообще не нужны, но если код сервиса разрастётся, то можно потом прикрутить либу (uber-go/fx, например)

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

Профайлер в Go приделывается парой строк кода

Подход "convention over configuration", которые так любят фреймворки, считаю ошибкой. Когда тебе создаётся 100500 папок, в которые надо что-то сунуть в нужные места (которые надо знать наизусть), всё вокруг отнаследовано от неведомых классов, которые тоже надо знать. А прикрутить что-то стороннее/нестандартное внутрь этого монстра - задача со звёздочкой.

Мне, короче, больше нравится парадигма "Явное лучше неявного".

Фреймворки лучше подходят для задач "сделай сайт целиком", с авторизацией, сессиями, шаблонами и т.д, но это не является типичным юзкейсом языка Go

🫥 Cross Join
⠀

Компания Wiz Research обнаружила критические уязвимости в Ingress NGINX Controller для Kubernetes, названные #IngressNightmare. Эксплуатация этих уязвимостей позволяет злоумышленникам получить неавторизованный доступ ко всем секретам в кластере Kubernetes, что может привести к полному захвату кластера. Около 43% облачных сред уязвимы к этим атакам.

https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities

🫥 Cross Join
⠀

Начиная с Chrome 135 появилась возможность кастомизировать <SELECT> элементы. Туда можно пихать иконки, применять различные стили и т.д.

https://developer.chrome.com/blog/a-customizable-select


🫥 Cross Join
⠀

Go планирует улучшить производительность в контейнерах (proposal)

GOMAXPROCS - это настройка в Go, которая определяет максимальное количество CPU-ядер, используемых для выполнения горутин параллельно.

В Go 1.25 разработчики предлагают встроить умный GOMAXPROCS, который будет учитывать ограничения контейнера (cgroup).

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

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

Сейчас разработчики решают эту проблему ручной настройкой через переменные окружения или используя библиотеку от убера. Новое предложение добавляет в сам Go автоматическое определение ограничений CPU из cgroups и динамическое обновление GOMAXPROCS при изменении этих ограничений.

🫥 Cross Join
⠀
#golang #performance #kubernetes #docker

Самое большое зло на свете - это неявное приведение типов.

Вот мои любимые приколы:

$str1 = "240610708";
$str2 = "QNKCDZO";

echo md5($str1) . "\n"; // 0e462097431906509019562988736854
echo md5($str2) . "\n"; // 0e830400451993494058024219903391

if (md5($str1) == md5($str2)) {
    echo "MD5 хеши равны!\n";
} 

md5 хэши равны, потому что php думает, что 0e... - это экспоненциальная нотация числа.

Дальше необъяснимое, прибавлять единицу можно по-разному, получая совершенно разный результат:
`

$x = "0abc";
$x = $x+1;
echo $x; // получится 1

$x = "0abc";
$x++;
echo $x; // получится строка 0abd

Не только в php проблемы, конечно.

На картинке выше, если кто не понял, Excel приводит 1/2 к 1 февраля.

Ну и классика js

name = 2;
console.log(name+2); // 22

потому что window.name хоть и получило число, но это заголовок окна, т.е. костылём прибито, что это строка.


Или такое

[1, 2, 3] + [4, 5, 6]  // -> '1,2,34,5,6'

Because fuck you, that's why.

Короче, не говорите мне, что неявная типизация - это удобно. Это говно

🫥 Cross Join
⠀
P.S. В коментах пишут про ===, strict types. Но ребят, это как раз попытка языков уйти от неявного приведения типов, потому что это говно.

Ох уж этот вайб кодинг. Https или api 🤦

🫥 Cross Join
⠀

encoding/json/v2 будет внедрен в go1.25 под экспериментальным флагом: https://github.com/golang/go/issues/71845

Анмаршалинг будет работать намного быстрее, кроме того, в новый json добавили 100500 фичей. nil-слайсы будут маршалиться как [], можно задать формат для времени, указать case-sensitive или нет и много других штук.

Соответственно, v1 и v2 несовместимы, очевидно не получится просто добавить везде v2 и катить в прод. Старый json обещают поддерживать вечно

🫥 Cross Join
⠀

Кирилл написал пост, что ИИ не заменит программистов.

Да, блин, точно заменит. Не нынешними технологиями, а чуть позже.

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

Машина не сразу, но победила, перебором ходов и заучиванием дебютов.

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

Не сразу, но машина победила, и стала намного быстрее и точнее, чем живые существа.

Потом говорили, что в игру Го машина не может победить, потому что там подсчет ходов вообще не имеет смысла, только на интуиции. А человек - гений интуиции.

Результат немного предсказуем, в Го машина тоже побеждает. И алгоритм приспособили под любую вообще подобную игру.

Говорили, что все эти системы узко натренированы на что-то, но... вот щас оказывается, что машина, натренированная на тексты, может прям очень много дохуя.

Говорили, что не может программировать, рисовать и т.д, это невозможно, человеческий гений бла бла бла

Машина начала программировать, рисовать, писать тексты и стихи. Да, местами фигово, но, как говорится, "мы находимся здесь"

Самое интересное, что GPT задумывался как T9 на максималках, и никто не ожидал, что она сможет программировать и переводить с французского на китайский, учитывая контекст.

Кстати, раньше смеялись над автоматическими переводами ("охлади траханье, углепластик"). Сейчас запускаются международные стартапы вообще без присутствия человеческого переводчика, всё переводится чатом гпт. Ну, максимум, кто-то вычитывает в особо важных ситуациях. Переводчиков заменили на 99%.

Еще там что-то говорили про то, что мозг человека содержит 100 млрд нейронов. Но современный комп, например, Macbook M4 содержит 30 млрд транзисторов. Конечно, сложно сравнивать нейроны и транзисторы, но блин.

И рост продолжается, становится больше ядер, компьютеры объединяются в облака и т.д.

Тупо оценивать будущее, опираясь на сегодняшние возможности. Copilot 1.5-2 года назад был скорее анекдотом, сейчас для большинства разработчиков - это незаменимый инструмент. Да, надо перепроверять, да он не может поговорить с коллегами и уточнить задачу, но блин.

И каждый раз одно и то же, "компьютер никогда не сможет...".

Единственная надежда на то, что тупо не хватит энергии на все задачи. Уже сейчас это заметная доля потребления человечества, при том, что многие даже не начали толком пользоваться.

🫥 Cross Join
⠀

Мне что-то сегодня не остановиться.

Все эти примеры, которые я привёл (про шахматы, компьютерное зрение и т.д.) показывают, что человек - не какое-то абсолютно уникальное создание, а скорее всего это просто нейросеть. Т.е. заменить человека в его задачах - это чисто инженерная проблема, надо лишь приделать к модели больше параметров и притащить побольше обучающей выборки. Ну, подтюнить где-то алгосики, чтобы это обучалось подешевле. Но это всё не что-то невообразимое, прорыва тут не нужно, это просто решение каких-то очередных частных проблем.

Еще слышал такой аргумент, что, мол, программист ставит компьютеру задачу очень конкретно, а потом еще и проверяет решение. А когда ставишь задачу через chatGPT, то это какой-то черный ящик: что он там понял, не понял, а не глюканул ли в ответе.

А вы задумывались о том, как владелец бизнеса, который не шарит в техничке, ставит задачу программистам? Абсолютно ли чётко? Всегда ли правильно программисты его понимают и выдают четкую программу без багов? Люди вообще, часто говорят или делают хоть что-то абсолютно точно? Не бывает ли так что они бредят и несут чушь?

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

В итоге получается, что система, состоящая из нечётких глючных вещей, как-то функционирует. Да, с проблемами и т.д., ну и что. Ну упадёт прод, туповатый SRE это заметит и сообщит кому-надо, там починят костылём (сделав еще пару других багов). А ведь это делал венец творения - человек!

🫥 Cross Join
⠀

В работе лида очень важно слушать свою интуицию.

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

Например:

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

Короче, в идеале код должен писаться легко и непринуждённо, как пет-проект дома. Если есть какой-то раздражитель, надо его ослаблять (в идеале убирать).

То же самое и с положительными эмоциями:

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

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

🫥 Cross Join
⠀

Чем горутины отличаются от async/await функций в других языках?

Логически это примерно то же самое, но:

1. В Go не надо помечать асинхронные функции специальным ключевым словом async, они все там такие. Т.е. асинхронный код выглядит как синхронный, по сигнатуре не отличишь, только по тому что они делают (есть ли блокировки, сисколы и тд).

2. Стек: в горутинах при блокировке (саспенде) просто сохраняется указатель на стек, сам стек остаётся как был (в куче). Когда функция должна заработать снова, в регистр SP записывается указатель на стек

При async/await стекфрейм не сохраняется, а конкретные переменные сохраняются в специальном месте. Когда нужно продолжить работу функции, стек создаётся заново на основе сохраненных значений, что намного дольше. Тут конечно от реализации зависит, но в целом так

🫥 Cross Join
⠀