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.
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?