Also, Zig comptime is extremely powerful, which means you can do many many things with them, but it makes it pretty hard to understand what's happening: you always need to wonder “what will this code become when compiled”. A bit like with super-macro-heavy C code, or even lisp (even though comptime don't even work the same way macro do so you also need to wrap your head around it). In the end, IMHO it makes it “really fun to write, and hard to read”. This, combined with the lack of memory safety[2], probably make Zig the perfect hacker/hobbyist language, but not desirable for production (being the perfect mirror of Rust).
[1] even though Zig isn't a particularly good example for this, when reading real-world Zig code, there's `@` and unusual keywords (`align` `inline` `try` `comptime`, etc.), and (kind of) static typing. Of course it has a lighter syntax than Rust, but it's not like a dynamically-typed language either.
[2] yes, I know, there are some plans to have some kind of op-in memory-safety thanks to runtime checks, which is better than C's “everything is UB and sanitizer are an afterthought”, but still far away from the “proven safe” situation you get when using Rust. It's pretty sad that Zig didn't want to build upon the ownership framework developed by Rust.
I cannot find the appeal of the current iteration. It's very counterintuitive, which makes it really unsuitable for mainstream programming IMHO. Sure, you could argue that it's not intended for mainstream programming and that we want people to know exactly what they're doing, but then you're basically making the same argument Torvalds did for C.
And then you kinda have to ask yourself ... why?
It's also why I feel that the comparison with Zig is a bit unfair: Zig is not memory safe. If Rust was willing to compromise with this constraint it would remove could remove some of the intellectual overhead for the developer and result in simpler looking, if unsafe, code.
But then it would also destroy the one killer feature of the language.
The borrow checker is a Big Deal™, but even outside unsafe blocks, Rust did not go all the way to perfect safety. Safety remains a spectrum, not a binary choice. The extreme end of that spectrum isn't Rust. It's using a proof assistant to mechanically check the correctness of your entire program.
Still, I think my point about safety being a cursor instead of a switch remains.
Rust has evolved a lot, even since 1.0, but all changes were well designed and for the better, in my view.
Before claiming why its counterintuitive I think you should have provided some example to backup such claim.
I was generally rooting for mainstream usage of Rust, but I don't see it happening with the path it has taken. I also don't really hope it will for the same reasons.
Ironically, neutralising network effects like that is perhaps the best way to make sure Zig becomes mainstream, eventually.
Not to lionize andy or anything, but I'm pretty sure that strategies to neutralize these concerns is a deliberate choice in his stewardship of the language.
As long as it's a good language, why do we care if it's mainstream or not?
- There are extremely few jobs that recognise it. I'm attempting to learn C++ because of this.
- Documentation can be lacking as there isn't as much demand for it, or people with time to write it. That said, personal support in small communities can be great.
- Smaller library ecosystem.
- Survival of the language into the future is less certain without the financial support mainstream languages have.
I've used Haxe for years despite these points, it's a great language. A language is more than it's engineering though.
Zig might be in a good position here as it has very nice C interop, which lets you leverage the past 30 years of programming history, but it's still got a ways to go before it will be "ready for primetime" from the look of it.
One of the cooler aspects of Zig's breaking changes is that its formatting tool can automatically update your code to the new syntax.