errchan.Chan: всё оказалось немного сложнее

@pragus в https://news.1rj.ru/str/inv2004_dev_blog/150 накинул хороший пример, о том, что вызов .Err() не гарантирован => не гарантированы закрытие + drain канала. А сделать это через defer тоже _красиво_ не получится - потому как вызывать его надо на другом уровне.

Но не зря несколько раз говорили об итераторах - они тут пригодились, хотя и в другом контексте. С помощью него удалось принудительно закрыть и очистить канал сразу после закрытия чтения. Хотя теперь читается не сам канал, а итератор, в который заворачивается канал (может надо переименовать Chan()), но выглядит и функционирует одинаково.

Пример обновил: https://go.dev/play/p/dI40gU9DeZT

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

#golang

Оказывается канал в go нормально собирается GC и close ему для этого вовсе не обязателен.

Можно откатить прошлое "изобретение"

#golang

Детская травма в IT

Лет 20 назад работал в одной конторе и допиливал код за сотрудником, который уже покинул компанию. Там было несколько запросов и сложная логика кода на несколько страниц, которую пришлось разбирать. Но итог был удивительным: удалось выпилить вообще весь код , вся суть которого уместилась в LEFT JOIN.

Удивление вызвало, что недавно опять пришлось столкнуться с подобным подходом. И для меня это часто как красный флаг: с чего кто-то наскоком решил, что может в коде питона или go реализовать логику JOIN быстрее, чем это делает база? Основное свойство которой — делать именно это, что допиливали и разгоняли годами. Клик в расчёт не особо берём, я считаю, что JOIN — чуждый элемент в клике.

+ Отдельное удивление, что почти все базы до сих пор не смогли решить нормально проблему с пагинацией, которую раскидывают на дополнительные запросы параллельно.

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

Я попробовал все сборки поверх neovim и выбрал лучшую: 1/3

Начал я всё это из-за шила в ради старого ноутбука. Он хоть и старый, но лет так 5 назад я писал на нём на расте в Clion, параллельно собирая докер кликхауск в другом докере. Сейчас он заметно отстаёт по современным меркам, и это довольно заметно, что хорошо.

Опробованы: spacevim, nvchad, astrovim, lazyvim, lunarvim.

В двух словах: одни сильно тяжелее других: spacevim заметно тяжелее, самые лёгкие это nvchad и lazyvim. Но выбирал я исключительно по своему удобству, а именно в попытках понять, насколько это у авторов оно совпадает с моим. Первый же пример, когда что-то делаешь — переключиться на другой файл довольно частая задача, и нажимать space+f+f не так удобно, как space+space (lazyvim). Вся работа с кодом/lsp по space+c, с отладчиком по space+d. В других обычно это всё раскидано, как мне показалось, довольно хаотично, а в lazyvim вроде норм. Другой вопрос, сколько подпрыгиваний надо сделать, чтобы были и go, и cpp, и nim. Например, в nvchad надо сильно больше, чем в других. Выбрать-выбрал, но этого мало, теперь надо реально его использовать. Тут два момента: на домашнем ноуте особо негде, я поставлю на рабочий, где кодовая база сильно больше.

Тут надо разделить на две части: использование на работе и насколько оно лучше на старом ноуте, так как вещи не особо пересекающиеся.
...

#vim

Lazyvim в качестве рабочего инструмента: 2/3

Сорян за паузу, продолжаю.

В не слишком горячее время решил не открывать vscode и провести месяц-два в vim. Поначалу, конечно, ломало. Но в итоге всё удалось.

Основные простые функции работают нормально и удобно: навигация, рефакторинг через lsp, осмотр файлов проекта. Но, в остальном, как часто бывает в linux'ах, очень много недоделок.

Примеров масса, и чем дальше, тем больше они начинают напрягать:
- telescope неудобно обрезает широкие строки — сложно скроллить preview. Можно покрутить настройки.
- telescope вообще отрезает имена файлов, а в большом проекте это очень неудобно. Но тоже можно покрутить настройки
- statusbar тоже отрезает путь. Тоже надо поправить.
Почему это не из коробки так? Ощущение, что кто-то выложил plugin, но используют в реальной работе его не так много, уж точно не столько, как vscode, где все эти моменты уже отшлифованы. Потому и допиливают это значительно меньше.

- отладчик в vim — полурабочая штука, надо внешний.
+ neotest — работают хорошо и удобно, есть даже watch и перезапуск автоматом.
- call hierarchy — полный провал, и это один из решающих моментов. Я не очень понимаю, как без этого можно называться IDE. Судя по всему, вопрос до сих пор актуален.
+ lazygit — это открытие. Никогда его не использовал на постоянной основе, но в lazyvim он добавлен как основной инструмент, и оказалось очень удобно, удобнее vscode, где я больше просто git в консоле.
- multicursor — сильно удобнее regexp, вроде было что-то и для vim, но в ленивом vim не нашёл.

В целом, недоработанных мелочей полная коробка — то диалог не там отроется, то два split экрана неожиданно путаются местами.

В сумме по мелочам и не только итог, что как IDE vim всё ещё не тянет. Куда более рабочая схема — vscode + vim-plugin.

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

... дальше про то, насколько это всё легко работает на старом ноуте

#vim

Я попробовал все парсеры командной строки для Nim и выбрал лучший

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

Требования такие:
- поддержка отдельных команд
- каждая команда должна иметь отдельный набор аргументов
- умение работать с типами - я не хочу парсить в своём коде
- аргументы не текущей команды не должны быть доступны при компиляции

Итого, из 13 библиотек в финал прошла всего одна: https://bitbucket.org/maxgrenderjones/therapist.

На втором месте: https://github.com/casey-SK/commandant.

Я немного удивлён тому, что, оказывается, это не так просто — предоставить хороший интерфейс для такой простой штуки. Хотя бы вспоминая clap из Rust, где даже это требовало обильной обмазки макросами. В идеале так вообще лучше всё типами описать, а оно само разберётся, и therapist тоже к этому тоже ближе всего.

Скинул примеры сюда: https://github.com/inv2004/argparse_nim_examples

#nim

Шаблон с шаблонами

Запилил по работе в ClickHouse wrapper ошибок для случая, когда всякие корпоративные krb5 тикеты протухают. Код довольно абстрактный получился, так как покрывает всё взаимодействие с hdfs => на входе и выходе любые функции и типы могут быть. И теперь для меня мем пакет с пакетами звучит как

шаблон с шаблонами

#cpp

Vim на старом железе: 3/3

Как я писал тут https://news.1rj.ru/str/inv2004_dev_blog/155, всё это по причине, что, видимо, раз в 5 лет опять свербит: «А вдруг Linux стал хорошим десктопом?» => и эта идея залетает на старый ноут.

В этот раз залетели void-linux + (lazy) vim. Итог:

- Оказалось (очевидно же), что сам редактор для разработки — это меньшая часть того, что его подпирает и тормозит при этом.
- Даже якобы лёгкий vim со всеми свистелками может лагать и зависать, например, telescope легко фризится на секунду-две. Точную причину не знаю, думаю, тут три момента: treesitter пытается раскрасить preview, и, может быть, не особо асинхронно это делает. Тут же возникает впечатление, что vscode тормозит меньше просто по причине, что все эти моменты там полировали значительно больше народу и дольше. Аналогично, когда LSP-сервис что-то сканирует — даже курсор тормозит.

Итог: я опять вернулся к мысли, которую уже озвучивал тут https://news.1rj.ru/str/inv2004_dev_blog/30. Я не знаю причин, но после установки win-10 обратно на машину — она выглядит опять достаточно рабочей. Про причины у меня только догадки: может быть графическая подсистема (хотя карта старая и встроенная), может быть как-то по-другому работает scheduler, может быть кеши как-то иначе кешируют. Может быть всё вместе, просто из-за того, что это самый массовый десктоп и там всё долго оптимизировать, но и браузер, и vscode+WSL-2 работают заметно плавнее (не быстрее) под win. Замечу, что на машинах посильнее эта разница уже не особо заметна. Обратно тоже применимо: на современных машинах WSL-2 не отличается по производительности от нативного Linux: https://github.com/inv2004/bench_nim_build.

P. S.: можно сказать, что я потратил время с почти нулевой пользой и вернулся в исходную точку по этому вопросу. Но, некие минорные, но полезные вещи я всё же узнал, о чём напишу потом.

#linux

Диванные бенчмарки

Скорость сборки в WSL-2 на Win-10 и Win-11

Старый 6300U::
- win-10: 350s
- win-11: 388s
- Нативный Arch: 299s

Но не стоит ликовать, на 12600K оно так:
- win-11: 61s
- Linux 5.16: 71s

https://github.com/inv2004/bench_nim_build

Другие тесты:
https://www.phoronix.com/review/windows11-wsl2-zen4
https://www.pugetsystems.com/labs/hpc/wsl2-vs-linux-hpl-hpcg-namd-2354/
https://openbenchmarking.org/result/2107013-IB-WIN11WSL289
https://www.phoronix.com/review/wsl-wsl2-tr3970x/2
, но меня интересовал именно bench_nim_build

Диванные бенчмарки: вывод по WSL2

* может вызвать гнев

Кто-то мне рассказал про CachyOS - заоптимизированный Arch, а тут под руку еще и флешка подвернулась и я не устоял. Запускал всё на ramfs.

- Сначала проверил время сборки в Void: https://github.com/inv2004/bench_nim_build/issues/107
57.675s + 15.594s
- Потом CachyOS: https://github.com/inv2004/bench_nim_build/issues/108
55.545s + 14.893s
- Win11+WSL2: https://github.com/inv2004/bench_nim_build/issues/109
56.206s + 15.657s - это и ставит точку - отличий даже от оптимизированного CachyOS почти нет
- Win10 + WSL2: https://github.com/inv2004/bench_nim_build/issues/110
55.382s + 14.341s - понятно, что тут _все_ цифры в пределах погрешности, но тут даже быстрее чем CachyOS
- И напоследок решил запустить Opensuse Tumbleweed: https://github.com/inv2004/bench_nim_build/issues/111
52.725s + 14.464s - и вот тут магия - он заметно оторвался от всех других.

Вывод: В нативном Linux для разработки нету необходимости, если только нет каких-то предпочтений по UI => WSL2 вообще никак не отстаёт, если не опережает большинство дистрибутивов

— added —
- ubuntu тоже удивила в плохом смысле: https://github.com/inv2004/bench_nim_build/issues/115
59.900s + 16.025s

Кажется мне надо. Кто-то в китае берёт thinkpad клавиатуры от ноутов и делает обычные

Самое смешное, что случилось в HighTech в 2024м

Другая команда сказала, что мы слишком быстро посылаем пачку сообщений в кафку, а они не успевают читать и сохранять и попросили вставить что-то вроде sleep(X) на нашей стороне - чтобы они успевали.

Тут я понял, что, так сказать, не боги горшки обжигают

... пост вызван 8 годами разочарования в сообществе C++ ...
... автор ожидает возмездия за свои обвинения ...

Лучшее за сегодня: https://300.ya.ru/pzMdEwEG

Из комментов https://news.1rj.ru/str/itpgchannel/2723

#golang #rust

Наткнулся:

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

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

#clickhouse

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

я честно не хотел больше про раст картинки постить

#rust

bench_nim_build пополнился многими интересными замерами:

- M4, причём в разных вариантах, ожидаемо top.
- M2 - тоже в top
- Неожиданно выше M2 ворвался ноутбучный Intel x86 Ultra 7 155H
- Ниже идёт редкий ThinkPad на Snapdragon X Elite
- Даже был какой-то "секретный" Sparc, но попросили убрать

@RussianE39 рассказал довольно много интересных вещей, которые так с ходу не прямо очевидные, о том, что компиляция под разные платформы сама по себе может занимать довольно разное время. Т. е. clang to arm != clang to x86. И ещё много ньюансов, например, разные скорости даже соседних версий clang. Т.е. вывод такой, что тест меряет только то, что он меряет (с) кэп, но каждый конкретный промежуточный шаг может быть разным, вплоть до отдельных частей кода для arm/x84/mac/linux.

Переключу тест на clang, так как gcc или нет присутствует на mac и очень сильно тормозит. Не значит, что он плох, да и цель компилятора - не скорость компиляции, но просто не для этого теста.

https://github.com/inv2004/bench_nim_build

Как выжить в мире Windows

Агрессивные фанаты Linux / Mac — закройте глаза или хотя бы держите себя в руках.

Первое, чем раздражает Windows сразу после установки — в системе включено всё, что только возможно, что даже не просили, и сверху ещё много всего. Отключается это разными простыми и не очень способами, но периодические обновления или включают что-то обратно, или приносят что-то новое. Раньше это было терпимо, но с годами ситуация стала всё более раздражающей. Победить эту проблему, а заодно многие другие поможет следующий совет:

В Windows есть много веток, которые отличаются как раз только обновлениями и количеством включенного мусора. И самая спокойная из них даже не предназначается (по мнению MS) для десктопа, хотя это та же самая система и отличает как раз только включенными/выключенными опциями, частотой патчей и сроками поддержки — и имя этой ветки ... барабанная дробь ... IoT Enterprise LTSC

Windows 10 недавно закончила получать обновления с фичами (на LTSC ветках они вообще редки) и остановилась на версии 21H2. Windows 11 в том же варианте IoT Enterprise LTSC имеет версию 24H2. Для себя я не вижу причин торопиться обновляться на Win 11 и даже откатился обратно на Win 10.

Что решает такая установка:
- LTSC IoT будет получать security updates ещё много лет:
- Windows 10 IoT Enterprise LTSC 2021 до 2032-го года
- Windows 11 IoT Enterprise LTSC 2024 до 2034-го года.
- LTSC IoT максимально избегает раздражающих feature updates
- Отключена телеметрия
- Выключен MS Store
- нет UWP приложений (плиток).

Для себя я дополнительно:
- устанавливаю Winget, через который ставлю всё остальное
- если не лень, удаляю Edge, хотя этот шаг нетривиален
- отключаю Defender через group policy

И главное:
- установить WSL2 с любым дистрибутивом или даже несколькими

#windows

Несложно подсчитать, что через 10 лет он сможет победить в категории "язык, на котором я бы хотел работать" в 16й раз

#rust