https://github.com/carbon-language/carbon-lang #carbon

Carbon, новый язык от Google(хотя они это, кажется, не афишируют, но их фирменный стайлгайд и сборка на Bazel выдают их с потрохами).

https://news.ycombinator.com/item?id=32153320

Элегантная комбинация синтаксиса от Rust(включая совершенно уебищную модель generic'ов**) + memory safety C++, то есть, кажется, это язык, на котором лично я программировать не буду.

Кажется, это пока больше декларация о намерениях, потому что реального кода самого языка в репозитории довольно мало(https://github.com/carbon-language/carbon-lang/tree/trunk/toolchain).

Собрать это чудо у меня пока не вышло, и не выйдет в ближайшей перспективе, потому что Java и Bazel.

**: да, я считаю, что современные веяния, когда надо явно указывать, какие интерфейсы реализует класс - это очень так себе, duck typing шаблонов в C++ мне кажется куда как более здравым решением. У меня тут есть такое соображение - "клеить" статически типизируемые языки мега-удобно с помощью duck typed прокладки, типа, С + Python, или вот С++ + templates.

Собрал первую программу на #go, сразу с cgo.

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/emptty/ix.sh

Выглядит, вроде, неплохо.

Go я честно #bootstrap, начиная с версии 1.4, которая последняя на С, и кончая версией 1.18.

Скажу, что авторы Go, конечно, по гугловым меркам, упыри - у них слишком много "ценного мнения" на единицу кода.

Одна игра с GOROOT_BOOTSTRAP/GOROOT_FINAL чего стоит, ну и официально рекомендованный сопосб установки свежескомпилированного тулчейна доставляет:

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/go/4/ix.sh#L35

Доставили игры с линкером от Go:

* Он так и не смог научиться понимать мою структуру директорий с библиотеками, пришлось сделать так, что он всегда использует external linker - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/go/18/c/ix.sh#L21

* Еще внутренний линкер, кажется, не умеет линковать в бинарь статические библиотеки, собранные без -fpic, не поддержан соответствующий relocation.

Ну и эпичнейший баг с cgo - https://github.com/golang/go/issues/40415 - оно не работает, когда clang делает разноцветный выхлоп:

"The cgo tool doesn't really do string analysis of error messages. It just uses the file name and line number. But it does look for the literal string ": error:". It looks like -fdiagnostics-color is messing that up, because color codes are written out after the first colon."

"Не, мы не парсим выхлоп компилятора. Ну, ладно, парсим, на полшишечки, но это не считается", пишет нам некто ianlancetaylor.

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/go/18/c/ix.sh#L17

Вендоринг для Go я пока даже не начинал делать, а это значит, что нужно уже учиться в системе сборки помечать ноды как use_net/pure/impure, и чтобы сборка pure нод не могла зависеть от impure нод.

* компилятор Go от переписывания с С на Go замедлился раза в 2, если не больше, живите с этим знанием :D

* https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/go/18/t/ix.sh#L37 - go ищет сертификаты по каким-то захардкоженным путям, прищлось это исправить.

* https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/go/18/t/ix.sh#L42 - вот тут какая-то очень странная упячка, go, при сборке, почему-то очень хотел записать новый runtime.a по путям, по которым лежит предыдущая версия go. В интеренете на эту тему мутно - у кого-то тоже случалось, почему - непонятно. Я просто копирую исходный тулчейн во временную папку.

Кстати, кажется, вполне можно воспринимать #carbon именно вот с этой точки зрения, что, наконец-то, какая-то компания взяла, и решила запилить С++ 2.0 на основе clang, все, как я и заказывал.

(а всратый синтаксис от Rust - дань моде и попытка хайпануть)

#cplpl_doomed

Опять я мастер предсказывать уже произошедшие события!

https://www.reddit.com/r/programming/comments/w2thvo/carbon_an_experimental_c_successor_language/

Утащу комментарий с reddit:

"To give some context, in February of 2020 there was a crucial vote in the C++ standard committee about breaking ABI compatibility in favor of performance, mostly pushed by Google employees.
The vote failed. Consequently, many Googlers have stopped participating in the standardization of C++, resigned from their official roles in the committee, and development of clang has considerably slowed down.
Now, they've revealed that they've been working on a successor language to C++. This is really something that should be taken seriously."

Листал https://github.com/avelino/awesome-go, https://github.com/uhub/awesome-go - смотрел, есть ли тут что-нибудь полезное, что я раньше не мог положить в #stal/ix.

https://github.com/hashicorp/go-plugin:

"Plugins are Go interface implementations. This makes writing and consuming plugins feel very natural. To a plugin author: you just implement an interface as if it were going to run in the same process. For a plugin user: you just use and call functions on an interface as if it were in the same process. This plugin system handles the communication in between"

"Cross-language support. Plugins can be written (and consumed) by almost every major language. This library supports serving plugins via gRPC. gRPC-based plugins enable plugins to be written in any language"

"Protocol Versioning"

"Host upgrade while a plugin is running"

"Plugins can't crash your host process"

"Plugins are very easy to install"

"Plugins can be relatively secure: The plugin only has access to the interfaces and args given to it, not to the entire memory space of the process"

https://github.com/hashicorp/go-plugin#architecture
https://github.com/hashicorp/go-plugin#what-about-shared-libraries

https://github.com/xxxserxxx/gotop

"Extensions have proven problematic; go plugins are not usable in real-world cases, and the solution I had running for a while was hacky, at best. Consequently, extensions have been moved into the main code base for now"

В этом смысле экосистема Go - бальзам на мое израненное сердце.

Вот Google последовательно не дает людям механизма заниматься херней, и люди ВЫНУЖДЕНЫ делать правильно - или вообще не добавлять динамическую загрузку плагинов там, где они не нужны, или делать это через отдельные процессы, что очень хорошо и правильно.

Я окончательно зашкварился на go накодил закоммитил первые 10 строк на Go - https://github.com/tvrzna/emptty/pull/71

Дело в том, что emptty(очень достойный login manager, не скажешь, что на Go) не поддерживал хешированные пароли в /etc/passwd, а только схему с /etc/shadow, на которую мне все лень перейти.

Кстати, в чем отличие моих PR just for lulz, и PR по делу - все четко, быстро, понятно. Видно, что автор не стремится донести свою "важную точку зрения по любому вопросу", все исключительно по существу. Даже помог иcправить ошибку, в том же PR(а так можно было?)

Что я ощутил от разработки на #go? #обмазаться_шоколадом

Spread the word!

https://github.com/carbon-language/carbon-lang/issues/1519

https://github.com/python/cpython/blob/main/Lib/tempfile.py#L206

Например, код, проверяющий доступность для записи во временную папку для python.

Продолжал эксперименты с #imgui

Выяснил, что оно фигачит 60rps даже в моменты, когда это не требуется от слова совсем - https://github.com/ocornut/imgui/pull/5116

Ну, то есть, gui должен перерисовываться только в случае прихода какого-то event, от мышки, клавиатуры, или от таймера(для создания анимаций).

ImGUI, будучи заточенным под игры, шпарит всегда с максимально возможной скоростью, а это греет GPU.

Нет в жизни счастья :(

https://github.com/carbon-language/carbon-lang/issues/1519#issuecomment-1192285832

"We think we've made it pretty low-overhead to grab Carbon and start building all the same. And no one else should need to interface with us at this point, it is much much too early. So for now, it seems reasonable to just focus on what works well for the team. Does that make sense?"

UPD: тут вот меня спрашивают - зачем писать, если все равно ничего не поменяется?

Как говорит моя любимая Шульман, "только сопротивление дает субъектность".

Я напишу, что не согласен, ты полайкаешь, или тоже напишешь - глядишь(с вероятностью 5%) что-то и поменяется.

А не напишешь - точно ничего не поменяется.

Вот так вот поторопишься, похвалишь, а потом БАЦ!

* emptty жрет по 10 мегабайт памяти на процесс, и это только чтобы залогинить меня в систему. На 5 tty будет 50 мегабайт. mingetty жрет примерно в 100 - 1000 раз меньше.

*

go: downloading github.com/google/g
    o-querystring v1.1.0
# github.com/gopasspw/gopass/
    internal/backend
    internal/backend/registry.go:85:45:
    internal compiler error: 
    assertion failed

Please file a bug report 
including a short program 
that triggers the error.
https://go.dev/issue/new

Причем, что важно, компилятор Go написан на Go, и double bootstrapped, то есть, следа от моего кода, который мог бы быть бажным(типа musl + allocator) в нем нет.

У меня тут сегодня замес про Go и разработчиков на нем. Прочтите посты под тегом #школота перед прочтением, это довольно важно.

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

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

Тогда был пример про #rust, сегодня будет пример про #go.

По ссылкам я писал, что хотел бы часть репозитория написать на Rust/C++ - конкретно, выполнялку графа и process supervisor.

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

Но тут я решил, что, наверняка же, так как задача очень хорошо ложится на Go, то ее уже решили, и нефиг велосипедить.

Вот, пожалуйста, https://taskfile.dev - 5.5К звезд на гитхабе, хорошая, популярная вещь. Принимает граф в виде yaml/json, не совсем как у меня, но за полчаса я написал конвертор графа.

Мой тестовый граф был 5 мегабайт yaml, пара сотен нод.

Эта МЕРЗОТА на этом графе съела 5 ГИГАБАЙТ физической памяти, заняла 16 ядер моего CPU только под свой код, и так и не выполнила задачу, вот с таким сообщением:

task: [/ix/store/oZAVqMSU6AQOJIdR/touch] 
    echo aW1wb3J0IGFwgbmV3KQojIGV1Yw== | 
    base64 -d | /bin/ix misc runpy 
    /ix/store/5qYMWLFMqGDGHJII/automake-1.16.5.tar.xz 
    /ix/store/oZAVqMSU6AQOJIdR/automake-1.16.5.tar.xz 
    sha:f01d58cd6d9d77fbdca....69
task: maximum task call exceeded (100) for task 
"/ix/store/XG2mYVvSFINEVPWm-bin-file/touch": 
probably an cyclic dep or infinite loop

ЕБАТЬ, кто это написал, что это за пионеры, кто это вообще может использовать в проде?!?! СУКА, у тебя весь граф с зависимостями на руках, какой, в жопу, "probably"???

#goвно, #наgoнакодили, у меня для этого только такие теги.

И это, знаете ли, я отложил написание этого поста на сутки, чтобы немного остыть.

А теперь наезд на go по существу.

Компания Google умеет ставить задачи, и умеет решать задачи.

Компания Google поставила себе задачу "запилить язык, чтобы даже долбоебы могли на нем программировать". Они эту задачу успешно решили, но зато теперь долбоебы программируют именно на Go.

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

Это было за упокой, а теперь за здравие.

После такого печального опыта я решил, что уж как-нить напишу очередную выполнялку графа сам, и написал!

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/assemble/as.go

Заняло это у меня часа 3 времени, потому что по сути, до этого больше 5 строк на Go я не писал, а тут примерно все - и парсинг json, и корутины, и запуск процессов, и IO.

Программа успешно выполняет мой граф, жрет 0% CPU, 20 мегабайт памяти, по сути, только загруженный json. Я тут поддержал все фичи старого выполнителя, в том числе, отдельные пулы для CPU и network узлов, выполнение сверху вниз, а не снизу вверх(если цель готова, то не проверять сначала ее зависимости, этим много кто грешит), и так далее.

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

Я тут принципиально не хотел брать готовые библиотеки:

* Ну c'mon, а вы первую часть поста прочли?

* чтобы не зависеть от закачки из интернета, мне тут нужно принципиально "чистую" сборку.

Короче, написал, и уже успел заменить старый executor на питоне в моем проде. Размер бинаря упал с 10 до полутора мегабайт.

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

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

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

#panic

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

https://thephd.dev/finally-embed-in-c23
https://news.ycombinator.com/item?id=32201951

Наверное, только ленивый не рассказал про embed в C, я же хочу сосредоточиться вот на каком аспекте этого события - про комитеты, лоббирование, и почему С/С++ #cplpl_doomed

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

https://news.ycombinator.com/item?id=32202627
https://news.ycombinator.com/item?id=32204481

Там он рассказывает примерно вот про что(прочтите, вдруг я в глаза долблюсь):

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

* Есть платформы, на которых даже нет файлов.

* Есть платформы, на которых byte - 32 бита, и это не PDP в музее.

* Наши ошибки могут стоить ажно 1% перфа(тут я хочу напомнить, что недавно из-за ABI комитет по С++ отказался ускорить С++ на 5 - 10%).

И, поэтому, конечно, совершенно нормально, что на мелкую фичу, которая НИКАК с этим не связана:

"Are we're really talking about compiling on such platforms?"

"No, I'm mainly talking about targeting. My point is not so much about embed, but rather that, almost anything you assume you think you know about how computers work isn't necessarily true, because C targets such a wide group of platforms."

потрачено 5 лет.

Ну, то есть, нам рассказывают как все сложно на target, чтобы потом сказать, что 5 лет обсуждали, есть ли понятие "файла для embed" на host платформе, или нет.

Про комитеты, С/C++, и вообще:

* Почет и уважение члена такого сообщества заключается не в том, насколько он упростил жизнь нам с вами, а сколько много сложных и интересных задач он затащил от людей, которые ставят туда задачи(это не мы с вами)

* Если ты разобрался в сложной теме, например, в модели памяти С/C++, то у тебя довольно мало реальных стимулов эту модель упрощать. Если в ней станет легко разобраться - а зачем нужен ты и твой ценный сейчас опыт? А сложных и интересных задач "приделай сюда еще одну заклепку", которые все еще более усложнят - завались.

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

По какому номеру в списке идет упрощение модели памяти и починка range-based-for-loop, вы сами можете дофантазировать.

https://www.bmj.com/content/378/bmj.o1808.full

Не очень про IT, но, КМК, подходит для данной аудитории. Красивое.

https://news.ycombinator.com/item?id=32160703
https://www.reddit.com/r/worldnews/comments/w3hy8i

Немного отполировал новый executor, теперь он выглядит неплохо даже с точки зрения человека, привыкшего к динамическим исключениям:

Небольшой runtime, https://github.com/pg83/ix/blob/621140f98bb48fe06e42702813551d23ee94a8f4/pkgs/bin/assemble/as.go#L14-L60, и можно писать вот так:

https://github.com/pg83/ix/blob/621140f98bb48fe06e42702813551d23ee94a8f4/pkgs/bin/assemble/as.go#L332-L336 - поимка исключения.

https://github.com/pg83/ix/blob/621140f98bb48fe06e42702813551d23ee94a8f4/pkgs/bin/assemble/as.go#L298 - бросание исключения.

Можно написать еще немножко кода, чтобы работал return value из этих блоков try/catch, но пока не нужно.

Я соврешенно не претендую на первенство, или на то, что это написано наилучшим образом, но, КМК, написать вот такие 50 строк кода очень полезно для понимания того, как работает runtime языка.

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

To be absolutely clear: летать исключениям между модулями - не надо. Но в рамках одного модуля считаю вполне ОК. Про историю с переписыванием парсера json с такой схемы на обычные return value, и про небольшой профит в перфе - знаю, КМК, тут этот опыт нерелевантен.

А еще улучшил свой текстовый редактор, чтобы он вызывал gofmt на выходе. https://github.com/pg83/ted/blob/main/ted#L1097!