xtensa-zig VS zig

Zig is still "not production ready," embedded is still rough, and you might have to contribute to Ziglang itself to get any particular architecture working appropriately. That said, yes people are using Zig a little for embedded stuff:

https://codelv.com/blog/2020/5/using-zig-and-the-stm32h7-to-...

https://www.mdeditor.tw/pl/2Ap9

Xtensa is less supported. M0 might also have some issues: https://github.com/Schroedingers-Hat/xtensa-zig

I've been meaning to try it out for embedded myself; I'll let you know how it goes.

One thing I'm super excited about here is that Zig can now cross-compile CGO to macOS [0], granted you link the appropriate macOS frameworks and SDK [1].

[0]: https://github.com/ziglang/zig/issues/20689, https://github.com/ziglang/zig/issues/21721

[1]: https://github.com/tpoechtrager/osxcross

> Chose boring technology. I genuinely find myself picking libraries that have been around for a while partly because that way it’s much more likely that LLMs will be able to use them.

This is an appeal against innovation.

> I’ll finish this rant with a related observation: I keep seeing people say “if I have to review every line of code an LLM writes, it would have been faster to write it myself!”

> Those people are loudly declaring that they have under-invested in the crucial skills of reading, understanding and reviewing code written by other people. I suggest getting some more practice in. Reviewing code written for you by LLMs is a great way to do that.

As someone who has spent [an incredible amount of time reviewing other people's code](https://github.com/ziglang/zig/pulls?q=is%3Apr+is%3Aclosed), my perspective is that reviewing code is fundamentally slower than writing it oneself. The purpose of reviewing code is mentorship, investing in the community, and building trust, so that those reviewees can become autonomous and eventually help out with reviewing.

You get none of that from reviewing code generated by an LLM.

But the situation for Rust-C++ interop is also worse than for Rust-C interop. Why else would Google spend maybe $1 million on improving it in 2024? https://www.theregister.com/2024/02/05/google_rust_donation/ Many years after Rust got support in Mozilla for usage with Firefox written in C++.

>My sibling is also correct, language decisions were made in order to keep FFI zero overhead.

Yet overhead is only one piece of the puzzle for FFI and interop with C, or for that matter, C++.

How does Rust compare with a language with less advanced and more simple semantics and requirements of invariants, like Zig?

https://ziglang.org/

>Incrementally improve your C/C++/Zig codebase.

Regarding the reproducible bootstrapping problem, what is your project's policy on building from binary sources? For instance, Zig is written in zig and bootstraps from a binary wasm file which is translated to C: https://github.com/ziglang/zig/tree/master/stage1

Golang has an even more complicated bootstrapping procedure requiring to build each successive version of the compiler to get to the most recent version.

I love Zig and I love that it’s getting attention, but can someone convince me of its memory safety? One thing that surprised me is that returning pointers to stack-allocated memory doesn’t cause a compiler error — it just segfaults at runtime. This has been an open issue since 2019 [#2646](https://github.com/ziglang/zig/issues/2646).

That, along with the number of memory-related issues in one of Zig’s most popular project, Bun.js [search: segfault](https://github.com/oven-sh/bun/issues?q=is%3Aissue+segfault), gives me pause.

The duck typing argument is absolutely not based on minimal or missing documentation. There wouldn't be countless issues about it in the Zig repository if it were that simple. See https://github.com/ziglang/zig/issues/17198

I'm simply going to quote one of the comments from the linked GitHub issue:

> generic code is hard. Hard to implement correctly, hard to test, hard to use, hard to reason about. But, for better or worse, Zig has generics. That is something that cannot be ignored. The presence of generic capabilities means that generic code will be written; most of the std relies on generic code.

`appendSliceOptimized` is implemented using knowledge of the underlying writer, the way that say an interface implementation in Go would be able to. It's a big part of the reason that reading a file in Zig line-by-line can be so much slower than in other languages (2)

(1) https://gist.github.com/karlseguin/1d189f683797b0ee00cdb8186...

(2) https://github.com/ziglang/zig/issues/17985