Терпеть не могу статьи в стиле псевдомонолога персонажей в чьей-то там голове, но, тем не менее, свежий подход к тому, как можно сопрягать go с другими компилируемыми языками, минуя cgo:

https://xeiaso.net/blog/carcinization-golang/

TL;DR - конпелируете библиотеку на Rust в #WebAssembly, и загружаете ее в Go через #wazero (pure go #WebAssembly #WASM #WASI runtime)

Что нам это дает? Нам это дает:

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

(это отличается от ранее представленных способов, типа конпеляции всего в WebAssembly, и объединения через WebAssembly VM)

Понятное дело, что тут у нас в полный рост startup/warmup cost, и все, что с этим связано, но способ довольно интересный.

#wasi #wasm #webassembly #bootstrap

https://determinate.systems/posts/nix-wasm/

Вот, коллега очень верно пишет про "nix as a meta build system", для сборки кода в WASI. Но, как это часто бывает, начал он за здравие, а кончил тем, что собрал какое-то мелкое приложение на Rust, так и не продемонстрировав мощь метапакетной системы для сборки произвольного кода.

Ну потому что Rust и так умеет собирать в этот target, ничего нового не произошло.

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

https://t.iss.one/itpgchannel/1330
https://t.iss.one/itpgchannel/1195

Даже мои эксперименты с wasm бывали более содержательны - https://t.iss.one/itpgchannel/1189

Или, например, вот - https://t.iss.one/itpgchannel/1553

https://www.opennet.ru/opennews/art.shtml?num=61656

Коллеги хотя автоматически транслировать C в Rust, без unsafe.

C unsafe это довольно просто, правда, результат интересует только тех, кто хочет прикопать наследие C, и, в целом, довольно малоинтересно.

Без unsafe эта задача кажется нерешаемой, только если у вас нет AGI #strong_ai, более хорошего, чем человеческий, потому что такое переписывание с С - процесс очень творческий, он должен держать в голове всю программу, и иметь возможность (и уметь!) менять структуру данных этой программы, и, возможно, способы ее взаимодействия с внешним миром.

А если у вас есть такой AGI, то вам больше нет дела до Rust, хехе.

Короче, дело хорошее, но верится с трудом.

Мне тут более интересным кажется подход Мозиллы, которая занимается тем, что компилирует видеокодеки в #WebAssembly. Типа, модуль за модулем, пусть они там себе ездят по памяти, но только в пределах маленькой выделенной им области адресного пространства, и не вредят остальной части процесса.

#WASM #WebAssembly #WASI #blob #wazero

Тема с компиляцией C/Rust кода в wasm (https://t.iss.one/itpgchannel/1553), и использование его через wazero в go, кажется, пошла в массы:

https://github.com/ncruces/go-sqlite3

Очень разумный способ использовать зависимости на С/Rust без CGO, и без соответствующих проблем.

Правда, так как в go отсутствует вменяемая система сборки, sqlite3, собранный в wasm, прикопали прямо в репке - https://github.com/ncruces/go-sqlite3/blob/main/embed/sqlite3.wasm. Как я это нашел? Ну, так как я знаю, что go build не в состоянии выразить такую зависимость, то просто взял, и нашел.

Ай-яй-яй, никогда такого не было (https://t.iss.one/itpgchannel/1281), и вот, опять, нам тащат вирусню в проект добавили очередной supply chain attack.

#llvmweekly #rant

https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696

TL;DR - хочется уметь красиво выводить в отладчике не встроенные типы, для этого предлагается завести секцию, в котороую писать bytecode, который умеет выводить на эран те или иные типы в программе.

Почему не положить туда готовые python форматтеры, которые уже есть, и написаны?

"The logical next step would be to store full Python formatters instead of summary strings, but Python code is larger and more importantly it is potentially dangerous to just load an execute untrusted Python code in LLDB.

To address these problems, I’m proposing a minimal bytecode tailored to running LLDB formatters. It defines a human-readable assembler representation for the language, an efficient binary encoding, a virtual machine for evaluating it, and format for embedding formatters into binary containers"

Объяснение не стоит и выеденного яйца, потому что ТЫ УЖЕ ЗАПУСТИЛ этот бинарь, запусти и Python, в песочнице.

https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696/10

Или возьми готовый VM, в который llvm уже умеет (hint - #WebAssembly, #bpf, #ebpf https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696/12).

Но нет, это было бы слишком просто, на таком фиолетовое не получить.

Вообще, удивительно, в маленький #harfbuzz тащат большой #WebAssembly (https://t.iss.one/itpgchannel/1201), а в большой LLDB (который уже умеет в #WebAssembly) тащат самопальный байткод...

Где логика-то?

Новости #bootstrap

https://jakstys.lt/2024/zig-reproduced-without-binaries/

zig сумели собрать из исходников. Не из прикопанного бинаря zig.wasm (кстати, в копилку креативных способов использования #WebAssembly), а цепочкой, с самых ранних стадий разработки:

1) Build Zig from the C++ implementation of the commit above (with hacks and tricks to make it actually compile).

2) Use previous step to build the first Zig self-hosted.

3) Proceed to the next step. When the updated Zig does not build, find creative ways to build it anyway (or, when really stuck, ask @mlugg).

4) Goto 2 for 45+ times.

Вот последний пункт, конечно, очень впечатляет - это же сколько настойчивости надо иметь?

Автору респект и уважуха.

#WASM #WebAssembly #WASI #blob

https://github.com/wasilibs/go-yamllint

Технология движется семимильными шагами!

На этот раз yamllint, запускается через тот же #wazero, только это не Rust, а вполне себе настоящий интерпретатор питона, собранный под #WASI.

(спасибо нашим читателям за наводку!)

https://creston.blog/wasm-will-replace-containers/

Скорее бы уже, потому что я все еще имею мечту про "правильно" устроенный Linux:

* Все компилируется в #WASI #WebAssembly

* Есть одна большая WebAssembly VM, в которую статически слинкованы "системные" библиотеки - API opengl/vulkan, драйвера для opengl/vulkan (mesa), libc, ABI ядра, fontconfig, harfbuzz, и так далее - все, что имеет стабильный ABI.

* Все пользовательские приложения - тонкие клиенты к этой VM. В них нет свох кешей шейдеров, своих кешей шрифтов, и так далее, все это живет в VM.

* WebAssembly VM - идеальный клей между языками и рантаймами (CGO - тихий ужас, а вот загрузить Rust модуль в #wazero - это заебись. Линковать mesa в каждую программму - тихий ужас, а вот иметь OpenGL как "тонкий клиент" в VM - очень даже хорошо).

#gold

> Одмен, а в чем прикол делать дистр с фулл статик линковкой? У тебя пост на канальчике про это есть какой-нить?

У меня про это много чего написано, достаточно погрепать канал по "статическая".

В целом, аргументация такая:

* динлинковка - это вынужденная мера, появившаяся, когда у компухтеров было мало памяти
* динамическая линковка - сложнее, тулинг хуже (санитайзеры требуют, чтобы почти весь код (кроме того, что перехватывается), был собран статически использовать msan с кучей .so - заградительно сложно, отладчик работает хуже, код ходит через GOT/plt, а не напрямую).
* динамическая линковка - сложнее, например, во взаимодействии с другими системами (fork(), threads, tls, etc)
* динамический загрузчик - сложный, а еще он #suid, есть известные проблемы с безопасностью
* плагины лежат хз где, и часто их не хватает, потому что приложения не могут сказать, чтобы в gstreamer был такой-то #plugins
* в целом, загружать в runtime сторонний код в свое приложение (не в песочнице) - очень странная идея, потому что CI с ним, у вас, скорее всего, не было, и как он будет ездить по вашим данным - неизвестно. Для плагинов сейчас норм решение - #WebAssembly в песочнице, или там https://github.com/libriscv/libriscv
* code bloat, больше поверхность для rop
* #ABI - это бич C/C++
* #perf - 5 - 10% CPU на дороге не валяются
* динамически слинкованные бинари дольше запускаются

В общем, я не за статлинковку, я против динамической.

Статлинковка простая, как 5 копеек, и современные окружения (go, rust) это понимают.