[zozbot234]

> ...in the cloud especially, saving server resources can make a significant impact on the bottom line. There are not nearly enough performance engineers who understand how to take inefficient systems and make improvements to move towards theoretical maximum efficiency.

That's a very good point, actually. However...

> with fewer footguns

..the Crab People[0] would definitely quibble with that particular claim of yours.

[0] https://en.wikipedia.org/wiki/Crab_People of course.

[Tuna-Fish]

I would quibble with all of the claims, other than easier to learn.

I really see no advantage for Zig over Rust after you get past that 2 first two weeks.

[bbkane]

Coming from Go, I'm really disappointed in Rust compiler times. I realize they're comparable to C++, and you can structure your crates to minimize compile times, but I don't care. I want instant compilation.

Zig is trying to get me instant compilation and I see that as a huge advantage for Zig (even past the first 2 weeks).

I'll probably stick with Rust as my "low level language" due to its safety, type system, maturity, library ecosystem, and career opportunities.

But I remain jealous of Zig's willingness to do extreme things to make compilation faster.

[bombela]

On any Go production projects I worked on or near, the incremental compile time was slower than C++ and Rust.

A full build was definitely much faster, but not as useful. Especially when using a build system with shared networked caching (Bazel for example).

Yes those projects were a bloated mess, as it always seems to be.

[bbkane]

Re: slower incremental compile times - not my experience, but interesting data point. I'll keep a look out for this.

[samiv]

The key with c++ is to keep coding while compiling. Otherwise..yeah you're blocked.

[pjmlp]

The key with C++ is to learn how to use the build system, make use of binary libraries, and if one can afford to use the very latest compiler versions, modules.

And avoid header libraries, C++ isn't a scripting language.

[solatic]

Eh, I'd say that Rust has a different set of footguns. You're correct that you won't run into use-after-free footguns, but Rust doesn't protect you from memory leaks, unsafe code is still unsafe, and the borrow checker and Rust's language complexity are their own kind of footguns.

But I digress. I was thinking of Zig in comparison to C when I wrote that. I don't have a problem conceding that point, but I still believe the overall argument is correct to point to Zig specifically in the case of writing code to optimize a hotpath behind FFI; it is much easier to get to more optimal code and cross-compilation is easier to boot (i.e. to support Darwin/AppleSilicon for dev laptops, and both Linux/x64 and Linux/arm64 for cloud servers).

[vlovich123]

> but Rust doesn't protect you from memory leaks

In theory no. In practice it really does.

> unsafe code is still unsafe

Ok, but most rust code is not unsafe while all zig code is unsafe.

> and the borrow checker and Rust's language complexity are their own kind of footguns

Please elaborate. They are something to learn but I don’t see the footgun. A footgun is a surprisingly defect that’s pointed at your foot and easy to trigger (ie doing something wrong and your foot blows off). I can’t think how the borrow checker causes that when it’s the exact opposite - you can’t ever create a footgun without doing unsafe because it won’t even compile.

> but I still believe the overall argument is correct to point to Zig specifically in the case of writing code to optimize a hotpath behind FFI; it is much easier to get to more optimal code and cross-compilation is easier to boot (i.e. to support Darwin/AppleSilicon for dev laptops, and both Linux/x64 and Linux/arm64 for cloud servers).

I agree cross compilation with zig is significantly easier but Rust isn’t that hard, especially with the cross-rs crate making it significantly simpler. Performance, Rust is going to be better - zig makes you choose between safety and performance and even in unsafe mode there’s various things that cause better codegen. For example zig follows the C path of manual noalias annotations which has been proven to be non scalable and difficult to make operational. Rust does this for all variables automatically because it’s not allowed in the language.

[solatic]

> a footgun is a surprising defect that's pointed at your foot and easy to trigger

Close, but not the way I think of a footgun. A footgun is code that was written in a naive way, looks correct, submitted, and you find out after submitting it that it was erroneous. Good design makes it easy for people to do the right thing and difficult to do the wrong thing.

In Rust it is extremely easy to hit the borrow checker including for code which is otherwise safe and which you know is safe. You walk on eggshells around the borrow checker hoping that it won't fire and shoot you in the foot and force you to rewrite. It is not a runtime footgun, it is a devtime footgun.

Which, to be fair, is sometimes desired. When you have a 1m+ LOC codebase and dozens of junior engineers working on it and requirements for memory safety and low latency requirements. Fair enough trade-off in that case.

But in Zig, you can just call defer on a deinit function. Complexity is the eternal enemy, and this is just a much simpler approach. The price of that simplicity is that you need to behave like an adult, which if the codebase (hotpath optimization) is <1k LOC I think is eminently reasonable.

[vlovich123]

> A footgun is code that was written in a naive way, looks correct, submitted, and you find out after submitting it that it was erroneous.

You’re contradicting yourself a bit here I think. Erroneous code generally won’t compile whereas in Zig it will happily do so. Also, Zig has plenty of foot guns (eg forgetting to call defer on a deinit but even misusing noalias or having an out of bounds result in memory corruption). IMHO the zig footgun story with respect to UB behavior is largely unchanged relative to C/C++. It’s mildly better but it’s closer to C/C++ than being a safe language and UB is a huge ass footgun in any moderate complexity codebase.

[davemp]

> IMHO the zig footgun story with respect to UB behavior is largely unchanged relative to C/C++

The only major UB from C that zig doesn’t address is use after free afaik. How is that largely unchanged???

Just having an actual strong type system w/o the “billion dollar mistake” is a large change.

[vlovich123]

Depends how you compile it. If you’re compiling ReleaseFast/ReleaseSmall, it’s not very different from C (modulo as you said it has some language features to make it less likely you do it):

* Double free

* Out of bounds array access

* Dereferencing null pointers

* Misaligned pointer dereference

* Accessing uninitialized memory

* Signed integer overflow

* Accessing a union field for which the active tag is something else.

[ozgrakkurt]

As an example to this, I was using polars in rust as a dependency in a fairly large project.

It has issues like panicking or segfaulting when using some data types (arrow array types) in the wrong place.

It is extremely difficult to write an arrow implementation in Rust.

It is much easier to do it in zig or c(without strict aliasing).

I also had the same experience with glommio in Rust.

Also the binary that we produce compiles in several minutes and is above 30mb. This is an insane amount of bloat. And unfortunately I don’t think there is another feasible way of doing this kind of work in rust, because it is so hard to write proper low level code.

I don’t agree with noalias being bad personally. I fuond it is the only way to do it. It is much harder to write code with pointers with implicit aliasing like c has by default and rust has as the only option. And you don’t ever need to use noalias except some rare places.

To make it clear, I mean the huge footgun in rust is producing a ton of bloat and subpar code because you can’t write much and you end up depending on too many libraries

[vlovich123]

> To make it clear, I mean the huge footgun in rust is producing a ton of bloat and subpar code because you can’t write much and you end up depending on too many libraries

Nothing is forcing you to do that other than it’s easy to add dependencies. I don’t see how zig is much different

[ozgrakkurt]

I find it easier to write all the code I want in zig or c since it is easy to write low level code.

Hashmap is a good example to this. I was able to fairly easily port some parts of hashbrown to c but I’m pretty sure I can’t write that code in Rust in a reasonable amount of time.

[program_whiz]

Not the GP, but I've noticed that because if you don't anticipate how you might need to mutate or share state in the future, you can have a "footgun" that forces large-scale code changes for relatively small "feature-level" changes, because of the rust strictness. Its not a footgun in the sense that your code does what you don't expect, its a footgun in that your maintenance and ability to change code is not what you expect (and its easy to do). I'm sure if you are really expert with rust, you see it coming and don't use patterns that will cause waves of changes (but if you're expert at any language you avoid the footguns).

[vlovich123]

That’s not a footgun and happens in any language. I have not observed rust code to be more prone to it. Certainly less so than c++ for various reasons around the build time and code organization.

[dnautics]

It's possible to do memory safety analysis for zig. I think you could pretty easily add a noalias checker on top of this:

https://github.com/ityonemo/clr