Then those developers won't ever use anything ever. Why would breaking changes in an explicitly unstable development version exclude it from use for all time?
If you want stability, stick to stuff that has stability guarantees, but at the very least let them make breaking changes during development.
I think its a control vs safety trade off. Zig forces explicit control over memory with some tools for safety. Rust forces safety with some tools for control. I only have hobbyist level experience with these languages. I find both enjoyable and I hope Zig continues to mature.
A much better source on Zig vs Rust would be Alex Kladov [0], one of the authors of TigerBeetle [1], which is one of the best Zig code bases I have seen.
The two languages have completely different design philosophies and a completely different feel leading to a completely different experience. I would say they're more different from each other than Java is different from Python. Some low-level developers will be drawn to Rust more while others will be drawn to Zig more.
I just wonder what are the advantages of using a language that is not memory-safe and it's not even stable yet...
Edit: If there's any technical reason. Of course, being a hobby project, the author is free to pick whatever he feels is most ergonomic/he likes the most.
I am not a 10x systems programmer but I have used both for MCU projects.
An expert Rust programer probably wouldn't have the same friction points I experienced.
Two of the main advantages of the Rust borrow checker is preventing use after free and iterator invalidation.
Zig's deferred free helps with the first, and hardware FIFOS, doorbells etc often caused me to have a non significant amount of unsafe code.
For me, the array safety in Zig removes most of the C foot guns, and the Rust projects decision to error on the constrained side of the static analysis dichotomy was getting in the way.
It isn't even a case of one being 'better' for me, the tradeoffs just made Zig better for this use case for me.
The idea that memory safety is a binary choice between what Rust provides and anything less than that has absolutely no grounding in either empirical or theoretical results. For example, it is true that there are good empirical reports that some high percentage (~70%) of security issues in C programs are due to memory safety, but most of those are due to lack of spatial safety, and Zig offers the same level of spatial memory safety as Rust. But in short, you get a language that's far safer than C and far simpler than Rust, which appeals to some just as Rust appeals to some (and frankly, both appeal to far fewer people than what's necessary to achieve even a medium level of success).
The moment I read "Needing two of the most famous non-Linux operating systems for the layman to sanely develop programs for Linux systems" I knew this comment would be a big pile of unfactual backed opinions.
there was this German talking head "Nico Lange" who made this claim first without providing evidence for it. He is an ex politician and a regular in the Munich Security Conference and I assume this is who was (mainly) responsible for spreading it.
AI gets so much boost from this nonsense. Because now it's about saving our lives.
Yeah – the shadowsocks developer is Chinese and the government went after them for working on an iOS VPN app back in the day on GitHub. That was a while ago, before the CCP had direct control over the App Store with law.
OpenPOWER was created to sell chips more then anything else. But many people don't just want some stanard 'high performance' chip. There are many different kinds of high-performance chip. A high-performance chip, for a car, a gaming computer, a AI chip or a cloud chip that runs VM are all different.
There is simply not that amount of options in the POWER market. Its a restrictive set of vendors.
Pretty much every new startup designing high performance chips picked RISC-V. And they optimize their chips for specific use-cases.
In addition, the software ecosystem for RISC-V is arguable already better then POWER. And many companies and universities are working together on making it first class. Android is going to RISC-V, it will never be on POWER.
So if you were to design something for consumers, not going with RISC-V would be crazy.
RISC-V is also evolving far more quickly. There are like 80 working groups working on improvements all in the open. The amount of companies working on POWER is tiny in comparison.
Power and RISC-V are going after different markets.
While Power is IRSC has a lot of legacy baggage that makes it significantly more complex that RISC-V (which is clean slate and purposely simplified.) It is also definitely not optimized for low power situations / embedded.
It is basically super computer chip.
Also unlike ARM and RISC-V it isn't designed to be extensible/customized by users. It is more monolithic.
I wouldn't say "super computer" chip (or at least "supercomputer")...
I've read the definition of a supercomputer as "some computer that takes specific domain, compute-bound problems and turns them into IO bound problems." (Implicitly, in that statement is the second statement of "and they have a ton of IO too). They're not really general purpose computers, and likely you'd be able to use risc-v or anything else, with specialized hardware, as the basis of a "supercomputer".
The power platform, on the other-hand (I'll create a new word here) is a foundation for a "SuperEnterprise(tm)" computer.
Power has insane / awesome things like "oh, you can use the ECC bits for ECC and hardware memory tagging[1]." Eventually such things may trickle down to things like ARM or RISC-V, but they're pioneered at the top of the enterprise mountain and trickle down...
If you're a student in a microarchitecture class who has to implement a core in a semester then the simplicity of RISC-V makes it a much better choice. And if you're a grad student trying to try out some idea in your thesis then you should also choose RISC-V for the same reason.
If you're creating a microcontroller for a specific product then RISC-V's ability to only implement the hardware features you need is a big benefit and its compressed instructions let you save money using fewer RAM chips.
The people I know using RISC-V don't want a high performance core. They want a very small area low power core for things like PCIE and DDR link training.
reply