В go 1.26 расширяют оператор new, теперь туда можно будет передать число, и получить ссылку. Как по мне, очень странное решение.

age := new(42)

Для начала, для чего вообще это нужно?

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

type User struct {
    name string
    age *int
}

А надо передать в него 42. И вот сделали для этого new(42).

user := User{
    name: "vasya",
    age: new(42),
}

Но зачем, блин, для этого использовать new?

Оператор new и в предыдущих версиях максимально странный. Всё что он может - это делать ссылку на zero value типа, который в него передали. Если написать

 go
a := new(int)

это всё равно, что

var x int = 0
a = &x

Для структур тоже самое. Но довольно редко кому то нужна ссылка на 0. А на пустую структуру все обычно делают ссылку явно &User{} (для единообразия), а не new(User). Есть некоторые очень редкие кейсы с дженериками, где нужен именно new, но это прям надо постараться.

И вот они взяли и разрешили делать new(42), чтобы получить ссылку на 42.

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

Лучше бы просто в стандартной библиотеке сделали какую-нибудь функцию ptr(). Она пишется за минуту, и есть в каждом, наверно, проекте:

func Ptr[T any](v T) *T {
 return &v
}

А еще лучше бы не занимались такими мелочами, а улучшили бы синтаксис обработки ошибок 🙂

🫥 Cross Join - канал о разработке
⠀

В новой версии git дефолтной веткой станет main (вместо master). Вообще, если отбросить политические аспекты, main ведь гораздо логичнее. Что еще нафиг за master (хозяин)? Хозяин веток? Лесовик что ли

Но еще круче было бы вернуть старый добрый trunk, как деды называли. Раз у нас есть ветки, то должен быть и ствол. Суперлогично, как мне кажется.

Тем более, что второе значение trunk - это сундук. Сундук, короче, со всяким ненужным хламом. Вообще было бы супер в тему

🫥 Cross Join - канал о разработке
⠀

Говорят, на собеседованиях стали просить закрывать глаза при ответах на сложные вопросы, чтобы исключить подсказки chatGPT.

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

Думаю, что на алгоритмической секции прогерского собеса тоже можно так читить. Так что надо еще просить показать ж, чего уж мелочиться.

Вообще, если серьёзно, то собесы превращаются в какой-то цирк. Имхо если чел быстро и правильно отвечает, то какая разница, что он там использует фоном, хоть ии, хоть вибратор.

Такой хитрожопый (во всех смыслах) чел уж как-нибудь кнопку покрасит и json в базу пихнёт

🫥 Cross Join - канал о разработке
⠀

https://about.gitlab.com/blog/gitlab-discovers-widespread-npm-supply-chain-attack/

🚨 Масштабная атака на npm-экосистему

GitLab обнаружил крупную атаку на цепочки поставок через npm-пакеты. Вредоносная программа распространяется как червь, автоматически заражая новые пакеты через украденные токены разработчиков. Малварь крадёт credentials от GitHub, npm, AWS, GCP и Azure, а затем использует их для дальнейшего распространения через легитимные пакеты.

Самое опасное — встроенный механизм «мёртвой руки». Если малварь теряет доступ к своей инфраструктуре (например, при массовом удалении заражённых репозиториев), она начинает уничтожать данные пользователя. На Windows удаляет файлы и перезаписывает сектора диска, на Unix использует shred для безвозвратного уничтожения.

Что делать:

Проверьте node_modules на наличие файла bun_environment.js, папки ~/.truffler-cache/ и др (см статью)

Также в статье указаны подозрительные процессы, которые стоит поискать.

Просканируйте package.json на подозрительные preinstall скрипты

Ротируйте все токены GitHub, npm и облачных сервисов

Расследование продолжается, список заражённых пакетов уточняется.

🫥 Cross Join - канал о разработке
⠀

В Go 1.26 появится еще немного сахара

Как известно, тип error - это просто интерфейс, под которым может скрываться любой тип, который этот интерфейс реализует.

И для проверки и распаковки ошибки в переменную нужного типа применяется errors.As, но этот метод неудобен: надо сначала создавать переменную, а потом туда загонять значение

var appErr AppError
if errors.As(err, &appErr) {
    fmt.Println("Got an AppError:", appErr)
}

Особенно это напрягает если есть цепочка if, else if ..., перед этой цепочкой надо создать все переменные.

Ну так вот, приняли proposal, который позволяет это сделать попроще. "type-safe, faster, and easier"

if appErr, ok := errors.AsType[AppError](err); ok {
    fmt.Println("Got an AppError:", appErr)
}

Наличие дженериков в Go снова помогло улучшить стандартную библиотеку.

🫥 Cross Join - канал о разработке
⠀

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

Когда в большой организации вводят правило "вторники без митингов", я смотрю на это со скепсисом.

С вероятностью 99% это означает лечение поноса затыканием жопы. Вместо того, чтобы искать корень проблемы, почему же все, собственно, задолбаны митами.

Обычно перегрузка митами происходит, когда:

1. слишком много контроля (микроменеджмент), приходится постоянно отчитываться о том, как именно ты что-то делаешь

2. слишком много согласований с другими отделами, нет независимости команды в принятии решений ( как Tight coupling в программировании). Или например, фронтенд одна команда, а бекенд другая, со своими планами и приоритетами.

3. есть какие-то наслоения сбоку типа структур "Engineering excellence", "отдел корпоративного обучения" и прочие активности, оторванные от реальных дел бизнеса, и находящиееся в абстрактном вакууме. Поймите меня правильно, можно много всего классного полезного придумать и сделать, но запрос должен идти от команды, а не насильно в команду.

4. обязательное на всю организацию внедрение скрама и прочих штук, которые нужны так-то далеко не всем. Я, например, как-то работал в команде из 2(!) разработчиков, куда насильно навязали скрам. А скрам - это много странных приседаний (планирование, демо, ретро, хуетро и т.д.)

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

Кстати, в маленьких стартапах никогда не бывает таких дней, потому что все встречи, в общем-то, по делу, и их мало.

🫥 Cross Join - канал о разработке
⠀

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

Но это, конечно, не так. За свою 20-летнюю карьеру видел пяток увольнений самых-пресамых незаменимых.

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

Во-вторых, даже если человек реально приносит огромную пользу и по-своему незаменим, то порой руководство просто поступает нелогично и увольняет всё равно. Иногда последствия бывают совсем неочевидны и отложены во времени (медленнее пилятся фичи, вылезают непонятные критические баги на проде), их никто никогда с Васей уже и не свяжет. Даже если объективное расследование бы показало, что денег в итоге потрачено больше. Короче, это или неправильная системная оценка или просто банальная глупость/лень менеджмента.

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

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

🫥 Cross Join - канал о разработке
⠀