Yeah, I’m leaning towards zig but I’m a bit on the fence still.

For Rust, I kind of got tired of writing unsafe rust for embedded, but that’s addressable afaik. The real dealbreaker was that after 10k+ lines of code I still will pop open the source of a library that solves a simple problem and the code looks indecipherable. I also don’t really agree with the dependency explosion that cargo encourages.

Zig is very nice in that it has the most ergonomic struct usage I’ve encountered. The stdlib could really use some improvement though. Comptime is very cool, but I also worry if the community will get undisciplined with it.

Zig is fantastic, however there are a few issues (mostly related to its immature/wip status):

- the build system is constantly changing in a breaking way (between releases some of the repos I have on GH no longer build and need their build.zig to be updated).

- the comptime section of the docs needs to be heavily expanded, I'd love to see them take common Go interfaces and redo them in Zig (like io.Writer, io.Reader), breaking down the process step-by-step. It took me a little bit longer than it should've to efficiently use comptime.

- a whole section dedicated to things like using WaitGroup and multithreading, for those coming from langs like Go. Also, higher-level concurrency primitives like channels would be fantastic.

- a better import system for external zig libraries, the zig fetch => .dependency => .root_module.addImport stuff is not as straightforward as it should be although for someone coming from C it definitely does feel like using meson

None of these are critical and again, all signs of Zig's "youth".

>Also, higher-level concurrency primitives like channels would be fantastic.

That can be done trough a library.

Agreed! There is actually a nice C library (libdill: https://libdill.org).

Would still like it as a first-class language construct.

I like Zig, too. Not sure if it's a Rust alternative as in you still have to manage the memory yourself.

But is much simpler, easier to read, easier to understand, easier to follow and easier to reason about. It's less verbose and more productive.

It feels like what C would look like had it been invented today.

When I say "Rust alternative" it's precisely because it competes in the same space: very low-level, no GC, extremely high performance constraints, safety guarantees.

Re: safety guarantees, much digital ink has been spilled on how Zig can give Rust a run for its money when it comes to safety.

When people say: Rust <=> C++, Zig <=> C; they forget that C++ was precisely meant to be an enhanced C, which is what Zig is trying to accomplish. They simply eschewed chasing complexity as the holiest of holy grails, which in turn leads to the cognitive load of writing/reading Zig code to be MUCH smaller than C++ or other langs in that space.

All that said, I'd never recommend a company build their product on Zig just yet, at least not with some kind of red telephone to the Zig team or a dedicated Zig developer, given it's still not fully mature.

Re: managing memory yourself, Zig's defer makes this much, much more straightforward than you would think, and feeding in your own allocators can simplify this in many cases (and make testing for leaks much easier).

It has the same safety guarantees than Modula-2 and Object Pascal have been offering for decades, but apparently curly brackets and @ everywhere is better than begin/end.

Curly braces have taken over the world (let's ignore Python for now...).

If you present Zig like a C successor (which C++ was at the moment of its inception), I totally agree.

Zig is decent as a systems programming language. It's good they don't add lots of features and keep it simple.

The only downside I see is companies aren't investing in it much.