А теперь самая "постыдная" часть этого поста.

Мне, неожиданно, понравилось! Без всяких скидок. Вот этот вот класс программ - fail fast в качестве обработок ошибок, IO, граф, корутинки - писать удобно и приятно, я думаю, я потратил меньше времени, чем бы сделав это на python, ну и результат "интереснее".

Думаю, если бы там появилась серьезная обработка ошибок, я бы что-то сделал на тему https://stackoverflow.com/questions/25025467/catching-panics-in-golang

#panic

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

Довольно очевидная мысль, но я раньше ее нигде не слышал.

#panic

* Наличие в языке runtime с hidden control flow усложняет сопряжение этого языка с компонентами на других языках. Читай c++ dynamic exceptions, go/java gc, etc. Понятно, почему? Потому что это hidden control flow может протекать между границами модулей, с понятными косяками.

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

Отсюда следует довольно простая мысль - что поляна кросс-языковых инфраструктурных библиотек будет попилена между языками, в которых нет такого runtime - zig, rust, C, #hare, и так далее. Просто потому, что их можно невозбранно звать друг из друга и передавать коллбеки, не боясь, что это взорвется к херам при раскрутке исключений или вызове финалайзеров в gc. И никого не будет волновать, что tls сделан на Rust, а парсер json - на zig, пока есть четкая граница между модулями.

А до кросс-вызовов они как-нибудь договорятся, на самом деле, уже договорились, через platform abi FFI.

С++, к сожалению, там не будет места. А могло бы и быть, если бы случились https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf

Но старперы из комитета по С++ предпочитают ныть, что их труды посылают к херам, да (https://www.opennet.ru/opennews/art.shtml?num=58527), вместо того, чтобы осознать и начать решать проблему.

Вышел go 1.22, https://www.opennet.ru/opennews/art.shtml?num=60564

И, тра-та-та, в нем появился yield, https://go.dev/wiki/RangefuncExperiment

На первый взгляд, цельнотянуто с Python, разве что, StopIteration() там нет, по понятным причинам.

Чаты кипят. В основном, возмущением.

Осталось только добавить сахарок для поимки #panic, и будет вообще лучший язык.

Настолько испытываю, что запилил альтернативу ya make, но на go - https://github.com/pg83/gg/blob/main/ya.go, за новогодние праздники.

Прямо сейчас это не имеет особого продуктового смысла, служит мне для упрощения и ускорения цепочки bootstrap. Ну и, BTW, это лучший выполнитель статического графа задач, из всех, что я изготавливал (там честные проценты выполнения, например)!

Кстати, если вы - фанат if err != nil {return err}, то почитайте этот файл, и оцените, как приятно может быть писать на go, с runtime exceptions!

#panic

От https://t.iss.one/code500/9747

А все почему?

Потому что обрабатывать ошибки через if err ... - муторно, неудобно, многословно, и потому - error prone!

Я несколько раз писал, и продолжу писать, что ошибки в go, если они происходят в рамках одного модуля, надо обрабатывать через #panic (например, https://t.iss.one/itpgchannel/2622), а вот уже между модулями стоит слать типизированные ошибки через return.

(в целом, этот совет, кстати, верен вообще для всех языков - https://t.iss.one/itpgchannel/913)