Бюро статистики труда США прогнозирует рост вакансий software developers и QA на 15% до 2034 года. И это несмотря на все ИИ, массовые сокращения и прочие экономические закидоны.

Любопытно

Говорят, что ИИ - это финансовый пузырь, который лопнет, и мы все заживём по-старому.

Чё думаете?

Имхо, финансовый пузырь - скорее да, чем нет. Компании вкладывают столько денег, что это может окупиться наверно только с AGI, до которого еще далеко.

Но и по-старому не заживём никогда, ЛЛМки уже никуда не денутся. Будут, наверно, в 2-3 раза дороже, но на этом всё.

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

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

Но я не настоящий сварщик, интересно ваше мнение. Может, были какие-то исследования или типа того

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

Во-первых, ИИ мощно убивает работу для джунов, а во-вторых, и до ИИ рынок войти-в-айти уже стал перенасыщенным. Толпы прям уже туда пёрлись.

Так что перспективы очень сомнительны.

Разве что для общего развития изучать. Логическое мышление и всё такое.

Обалдеть, чего только не бывает в природе. Наткнулся тут на pglite - Postgres, скомпилированный под wasm, который можно запускать в браузере (или на nodejs).

Для сложного фронтенда, который делает хитрожопые джойны и оконные функции. Поддерживает даже пгшные расширения, типа pgvector.

Может персиститься в IndexedDB и другие штуки.

import { PGlite } from "@electric-sql/pglite";

const db = new PGlite();

await db.exec(`
  CREATE TABLE IF NOT EXISTS notes (
    id SERIAL PRIMARY KEY,
    title TEXT NOT NULL,
    content TEXT,
    created_at TIMESTAMP DEFAULT NOW()
  );
`);

https://github.com/electric-sql/pglite

Все знают, что ошибки в Go (всё время писать if err !=nil) - это путь страдания. Ладно, не все страдают, многим это нравится.

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

Дело в том, что тип error в Go - это на самом деле интерфейс. Под такой интерфейс подойдёт любой тип, в котором есть метод Error(), возвращающий string. Утиная типизация.

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

type CustomError struct {
 When time.Time
 What string
}

func (e *CustomError) Error() string {
 return fmt.Sprintf("at %v, %s", e.When, e.What)
}

Однако есть нюанс. Функции обычно возвращают не конкретный тип, а интерфейс error. И для переменных, которые имеют тип интерфейс, Go в рантайме хранит там два значеня: тип и value.

Вот функция вернула интерфейс `error`, который внутри функции был *CustomError, тогда она вернула

1) тип (например, *CustomError)
2) value (собственно сам указатель)

В случае с неинициализированным указателем это будет

1) тип *CustomError
2) nil

И в этом случае if err != nil не пройдёт, потому что Go чувствует, что это не простой nil, а хитрожопый: там внутре задан какой-то тип. В итоге имеем такой прикол:

package main

import (
 "fmt"
 "time"
)

type CustomError struct {
 When time.Time
 What string
}

func (e *CustomError) Error() string {
 return fmt.Sprintf("at %v, %s", e.When, e.What)
}

func DoSomething() error {
 // неинициализированный указатель - это nil
 var err *CustomError

 if 2+2 == 5 {
  return &CustomError{When: time.Now()}
 }

 return err // казалось бы, возвращаем nil
}

func main() {
 err := DoSomething()
 
 if err == nil {
  fmt.Println("Нет ошибки")
 } else {
  fmt.Println("Есть ошибка")
 }
}

получаем "Есть ошибка", хотя ошибки не было

В данном случае лучше возвращать простой nil, не типизированный, т.е. вместо return err написать return nil

И всё будет хорошо )

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

Забавно получается. Если весь код будет писать cursor/claude, то выходит, что эйджизм должен замениться на антиэйджизм :). Я очень на это надеюсь:)).

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

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

Хотел написать пост, но вылилось в статью

https://habr.com/ru/articles/994056/

Будни кодинга в курсоре

Вот вы всё жалуетесь, что митов в IT слишком много. А посмотрите, как у людей бывает.

Целая структура с начальником и замом исключительно для организации совещаний, капец

Вышел Go 1.26. Все написали, а я туплю

Если коротко: релиз не про синтаксический сахар, а про производительность, рантайм и инструменты для продакшена. Новый сверхбыстрый json так и не вышел из стадии experimental (там есть проблемы с памятью и обратной совместимостью)


Новый сборщик мусора Green Tea

В Go 1.26 по умолчанию включён новый сборщик мусора Green Tea. Он сканирует память пачками (по span’ам), лучше использует кэш CPU и умеет в векторизацию на amd64.

Ожидания команды - минус 10-40% накладных расходов GC в реальных приложениях. Особенно полезно для сервисов с высокой нагрузкой и большим количеством мелких объектов.


Быстрее cgo и syscalls

до 30% быстрее cgo-вызовы

около 9% ускорения системных вызовов


Быстрее мелкие аллокации

Для объектов размером 1-512 байт добавлены специализированные пути аллокации. В синтетических тестах до ~30% быстрее для маленьких объектов.

В реальных сервисах команда ожидает ~1% общего выигрыша.


new(expr)

Теперь new можно вызывать не только с типом, но и с выражением:

p := new(42)

Удобно для optional-полей со ссылками (JSON, protobuf), когда нужно быстро создать *bool, *int и т.д. Без лишних временных переменных.


errors.AsType

Появилась type-safe альтернатива errors.As: errors.AsType.

без лишних переменных, быстрее, меньше аллокаций, + некоторые ошибки ловятся на этапе компиляции


bytes.Buffer.Peek

Метод Peek(n) позволяет посмотреть следующие N байт без сдвига буфера. Удобно для протоколов и парсеров.


Профилирование утечек горутин

Экспериментальный goroutineleak в runtime/pprof.

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

+ добавлены новые метрики по горутинам


В log/slog появился MultiHandler.

Теперь можно из коробки писать логи сразу в stdout и файл (или в несколько систем), без кастомных обёрток.


Reader-less crypto

Большинство функций в crypto-пакетах теперь игнорируют переданный io.Reader и используют системный источник случайности.

Это убирает зависимость от конкретной реализации и делает поведение стабильнее между версиями Go.


fmt.Errorf

Для строк без форматирования fmt.Errorf("x") теперь почти не отличается по аллокациям от errors.New("x").

Можно перестать думать над тем, какую функцию выбрать.


io.ReadAll

Переписан алгоритм роста буфера:

• примерно в 2 раза быстрее
• в 2 раза меньше памяти

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

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

Нет, не буду.

Написал статью на хабр про cross join lateral, плюсаните плиз )
https://habr.com/ru/articles/1005138/

Вообще, надо разделять использование ИИ-агентов в стиле "чистый вайб-кодинг" и в стиле "проверяю код и отвечаю за него".

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

Вообще, с трудом могу представить условную домохозяйку, которая будет чинить баги на проде из серии "сообщения из NATS не успевают разгребаться" или "postgres иногда подтормаживает по утрам". Или балансы неправильно посчитались, и надо разобраться, пофиксить и доначислить. "Эй, claude, разберись с багом и доначисли балансы, кому надо".

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

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

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

Господи свят, теперь даже в консольный докер впилили AI

Пишешь docker ai, и потом просто русским текстом пишешь, что тебе нужно, например "удали старые имиджи, которые не используются". И он делает там какие-то свои докерные команды, типа docker image prune с нужными параметрами