Cross Join - канал о разработке
3.8K subscribers
99 photos
10 videos
3 files
306 links
Канал о разработке Антона Околелова. Разрабочик/ex-тимлид Go, живу в Чехии. Мысли, новости, вопросы.

По вопросам рекламы @antonokolelov
Download Telegram
Все знают, что ошибки в 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 - канал о разработке
18😱8👍3👻2😨1
Забавно получается. Если весь код будет писать cursor/claude, то выходит, что эйджизм должен замениться на антиэйджизм :). Я очень на это надеюсь:)).

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

Это, впрочем, всегда было в какой-то степени так, но было не так наглядно. Прикол, а ведь кто-то когда-то даже пытался работу строчками кода измерять (вроде бы Майкрософт много лет назад).
1💯34👍8
Будни кодинга в курсоре
😁70👍12👎2🤡2🤝21🤣1
Вот вы всё жалуетесь, что митов в IT слишком много. А посмотрите, как у людей бывает.

Целая структура с начальником и замом исключительно для организации совещаний, капец
😁13
Вышел 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 - канал о разработке
🔥15👍71
Пара человек меня спросили, буду ли я делать аналогичный канал на Max.

Нет, не буду.
2👏92😁2313🤡10👍4😭3👎2🖕2🥰1😢1
Forwarded from Tuzov AI Lab
😩 Go Team vs вайбкодеры

https://groups.google.com/g/golang-dev/c/4Li4Ovd_ehE

Кто-то залил CL (changelist, аналог Pull Request в системе Gerrit) в Go с тегом Co-Authored-By: Claude Opus 4.5 в описании коммита. Ian Lance Taylor это заметил и поднял вопрос в рассылке golang-dev: а вообще есть ли политика по поводу AI-написанного кода? Авторские права, CLA — всё это висит в воздухе.

Ответ Rob Pike:

> Это очень скользкая дорожка. Осторожнее с первым шагом. Рекомендую просто сказать: нет.

Через несколько дней Russ Cox написал огромный взвешенный ответ. И это, пожалуй, лучший текст о месте AI в разработке, что я читал за последнее время. Рекомендую вам ознакомиться с ним целиком лично.

Самый сочный кусок — про "танцующих слонов":

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

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

Его позиция: фундаментальные вещи software engineering не изменились. AI — это инструмент, как редактор или профайлер. Можно писать качественный код с помощью AI, но только если не отключать мозг. Контрибьютор всё так же обязан присылать код, который он сам проревьюил и обдумал — AI не снимает с тебя ответственности.

По авторским правам: Google's OSPO разобрался, используйте спокойно. Но интересно другое: Alan Donovan в треде заметил, что значительная часть CLs уже содержит LLM-сгенерированный код — авторы просто не признаются.

По Co-Authored-By — убрать. Причина прямолинейная: это бесплатная реклама AI-компаниям, и ничего больше. Юридически строчка бессмысленна (AI не может быть автором по US copyright), информации не несёт — непонятно кто что написал, и даже как маркер использования AI не работает: модель сама непоследовательно решает, добавлять её или нет.

————

Позиция Russ Cox мне близка, т.к. я лично сталкивался с подобными случаями даже на работе — когда разработчик перегибал с вайбкодингом. Работать с этим становится невозможно, проще переписать с нуля.

"Танцующие слоны" — это хорошее описание того, что происходит когда люди воспринимают AI как замену мышлению, а не как инструмент. Go team явно не собирается идти по этому пути ❤️

#goteam #llm #claude
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥307👍5💯3
Интересный хак для упрощения запросов Postgres

Если вы пишете сложный SELECT, в котором одно и тоже вычисляется несколько раз, например, для массовой обработки данных пачками, то наверняка вам хотелось завести локальную переменную

вот пример:



SELECT
price * quantity AS total_price,
(price * quantity) * 0.15 AS tax,
((price * quantity) + ((price * quantity) * 0.15)) AS grand_total
FROM orders;



Здесь price * quantity вычисляется несколько раз, и tax вычисляется дважды. Но это выглядит еще ок, в реальности это зачастую всякие монструозные свитч-кейсы с NULLIF, COALESCE и прочими ребятами.

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

Это делается так



SELECT
o.item_name,
o.price,
o.quantity,
v1.subtotal, -- используем переменные
v2.tax,
v1.subtotal + v2.tax as grandtotal
FROM orders o

-- "Объявляем" subtotal
CROSS JOIN LATERAL (
SELECT o.price * o.quantity AS subtotal
) AS v1

-- "Объявляем" tax, используя subtotal
CROSS JOIN LATERAL (
SELECT v1.subtotal * 0.15 AS tax
) AS v2



Т.е. мы выделяем расчеты в cross join lateral, давай получившимся полям человеческие имена. И хотя в целом строк больше, но меньше дублирования кода, в котором можно ошибиться, и читается это зачастую проще.

https://www.db-fiddle.com/f/wSnCfpqzZypaPXSnsVUaYi/0

🫥 Cross Join - канал о разработке
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3510🔥5🥴2
Сколько примерно процентов кода пишете с ии-агентами (cursor, claude code и т.д.)? Т.е. не копированием из чата chatGPT, а именно агент сам правит код по вашей просьбе.

Давайте замерим ситуацию на данный момент, через месяца три проведу опрос снова.
Final Results
17%
> 90%
10%
70%
8%
50%
11%
30%
28%
< 10%
25%
мне посмотреть
Ну вот такая динамика получилась. Я пересчитал проценты, убрав "мне посмотреть", и построил график по времени.

За три месяца доля тех, кто не пишет или почти не пишет код с агентским ИИ сократилась с 60% до 38%

Доля тех, кто весь или почти весь код пишет через агента, выросла с 8.8% до 23.3%

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

Я лично почувствовал, что в последние месяцы матерюсь всё меньше и меньше (cursor + gpt 5.2)

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

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


Вот сырые данные, если кто захочет построить свой график.

8 декабря такие данные:
"> 90%" - 46
"70%" - 38
"50%" - 46
"30%" - 79
"< 10%" - 313

3 марта такие

"> 90%" - 100
"70%" - 58
"50%" - 47
"30%" - 61
"<10%" - 163

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

🫥 Cross Join - канал о разработке
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17🔥2🗿2
😢6
Вообще, надо разделять использование ИИ-агентов в стиле "чистый вайб-кодинг" и в стиле "проверяю код и отвечаю за него".

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

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

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

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

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

Пишешь docker ai, и потом просто русским текстом пишешь, что тебе нужно, например "удали старые имиджи, которые не используются". И он делает там какие-то свои докерные команды, типа docker image prune с нужными параметрами
🤯31😁19🤣10🗿32🔥1
P.S. Ждём, когда с кубером можно будет поговорить. Не надо этих конфигов, хельмов всяких. Просто говоришь ему "там чё-то прод упал, почини". Или просто "сделай заебись". И ждёшь
🤩39😁11🔥5😎1
Программист - это мешок угля. По крайней мере, я на это надеюсь.

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

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

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

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

В общем, если программист - это как мешок угля, то согласно парадоксу Джевонса, повышение эффективности программистов с помощью ИИ может привести к тому, что программисты будут востребованы еще больше.

Это при условии, конечно, что технологии не разовьются настолько, что домохозяйка сможет написать сложную систему (банк там или биржу) за 5 минут, но пока что до этого далеко.
🔥20👍153🥴1
Исходный код Claude был слит в сеть через source map в их npm пакете.

Вайб есть - приватности нет.
Ребята запушили source map файл в npm пакет @anthropic-ai/claude-code (заметил Chaofan Shou). 59,8 мб файл.

С помощью него можно восстановить исходники в оригинальном состоянии, уже есть на GitHub:
Репо 1
Репо 2

Голландский Rust-ист - канал о веб разработке
🔥13
Рубрика "помогаю друзьям найти работу". Великий интернет, откликнись

Есть один правильный пацан Теймур, фронтендер с 2020 года. Опыт реальный, не накрученный, что сейчас важно. Помимо всего прочего волонтёрил фронтом на проекте "Лиза Алерт" (!)

Что умеет (цитата из резюме):

"Основной стек — React, TypeScript,
JavaScript; разрабатываю корпоративные платформы, административные интерфейсы и
сложные SPA с интеграцией по REST API. Работал с архитектурой frontend-модулей,
производительностью, тестированием, CI/CD, сложными формами, аналитикой и
legacy-рефакторингом. Помимо frontend-задач, интересуюсь смежными инженерными
областями: автоматизацией, backend-интеграциями, Python и AI-инструментами."

Удалёнка

В общем, время сейчас дурное, нужна помощь зала. За найм пожму виртуальную руку. За репост знакомым/эйчарам мысленно поставлю лайк. Даже два

Кто не наймёт, тот дурак

Пишите ему сразу напрямую в тг - @yellow_ears
1👍1710🥱2