Zig code looks way more readable to my eyes, damaged by the years of staring at C/C++. Also the learning curve for Zig so far seems to be relatively shallow. The documentation is rather "ok-ish", comparing to Go for example. But it's much better than a few of the other programming languages I've used. I really hope Zig will find the place it deserves in the programming world!
Fewer symbols[1] “look” more readable at first glance (like dynamic languages), and more beginner friendly, but it also means there's less intent communicated and the reader needs to look for the information elsewhere: it's an eternal trade-off.
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 don't know. When rust was first iterating it was basically a different language from what it is now.
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.
The "why" is memory safety without GC, which as far as I know no other non-toy language provides.
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.
What are you referencing on that page that is memory and safe, the program panicking when attempting to access invalid memory is one of the safety features, it means you have a programming error that you need to correct and it is bailing right now to prevent anything bad from happening.
Oops, after a cursory search, it would seem there's no easy way to disable runtime bounds checking. While runtime crashes aren't ideal, I do stand corrected, sorry.
Still, I think my point about safety being a cursor instead of a switch remains.
whats wrong with current iteration? I think rust has become better with things like lifetime elision? And many new thing like GAT, out of band lifetime etc will make it more better?
Before claiming why its counterintuitive I think you should have provided some example to backup such claim.
Nope, I have no idea which path Zig will take, but I somewhat doubt it will do the same Rust did. Rusts later stage development reminds me a bit of the design by committee approach and it doesn't seem like Zig has that problem, but it's also hard to make it to a mainstream language without a hugely popular project that's associated to it.
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.
Zig already has the main advantages of being mainstream: first, it is small and easy to learn, which means you can hire any C/C++/D/Rust programmer, and they'll be productive in no time. Second, it binds to C more easily than any other language (save maybe C++), which means you have access to a wealth of libraries already.
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.
- 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.
Mostly ecosystem and community support. There are a lot of interesting languages out there, but it's hard to do interesting things with them if they're missing support.
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.
In many ways, it already has. Zig has been under development for several years now and its syntax and semantics have change a lot since its first iterations. There are still some breaking changes coming that you can find at https://github.com/ziglang/zig/issues.
One of the cooler aspects of Zig's breaking changes is that its formatting tool can automatically update your code to the new syntax.
