A New Era for C and C++? Goodbye, Rust? raised my attention.
There have already been several discussion on “safe” topic on the forum.
They all concerned technical side.
And this is mainly marketing issue, because Zig will be compared not with C, but with the future “Great Safe C”.
How we are going to sell Zig?
I think the major advantage of Zig is that it was designed with safety in mind.
Sure you can stick extra safety measures on top of C, but it won’t be for free. You will always pay a higher performance cost than the equivalent check in Zig.
Take the slice for example. In Zig the compiler knows that it is a pointer and a length, and the safety check can be done on the length. However in Safe C the equivalent struct {T* ptr; usize len;} would require adding a third, hidden attribute to the pointer for bounds checking.
I’m actually really interested in this topic, although I’m nowhere near knowledgeable enough to really grasp what’s happening.
The thing is… you should not force a language to a task. Some tasks are solved more naturally in some languages than others.
To some extent that goes with devs too.
If you don’t like (relatively) low level stuff like C and zig, then it would be hard sell anyway.
Probably, instead of “selling”, we should just be honest what are the features. It can backfire if you hype something and can’t deliver. Before switching to zig, I did try rust as I was constantly bombarded by hype how good it is… and don’t get me wrong, it is good for some tasks… but the more I was writing the more I disliked the experience.
I agree that marketing isn’t necessarily the good approach. Together we serve the users. The goal isn’t to sell Zig, but to find out what’s the best “Great Safe C” for a given use-case.
If Zig 1.0 really is that good that it should be the replacement for C, then it will be as long as the transition from C so Zig is smooth enough. If not there’s no point to “sell” it.
I expect that by the time Zig reaches 1.0, it will be developing a rich tooling ecosystem that include linters and verifiers that can help cover a lot of the “safety” territory.
Rust evangelism has pushed the notion of ‘memory safe’ as a property of languages, rather than of programs. I think this was largely inadvertent on the part of the core contributors to the language, to be clear, but it muddles the discourse.
Python code isn’t memory safe if there’s a bug in the Python interpreter, its garbage collector, or (main threat) any of the C code linked through the FFI. Rust code isn’t memory safe if there are mistakes in the implementation of Rust, or (main threat) if any unsafe blocks are incorrect. Both of these languages reduce the surface area where memory bugs can happen, but it’s programs which are memory safe, not languages.
Zig does a lot to make it easier and more practical to write memory-safe programs. It’s a language with explicit memory management, and that does allow for memory bugs, of course. But things like null-safety, bounds-checking (in safe release modes), pervasive slices, an idiomatic use of the GPA in debug modes to detect memory bugs, the ease of using patterns like arenas to reduce the surface area of possible memory bugs, these things add up.
I don’t expect Zig will need much selling. For the kind of code where Zig really shines, developers are already aware of both the promise of Rust, and the sacrifices needed to cooperate with the strict lifetime and mutability rules, and are able to weigh the benefits of both approaches. Sometimes that balance tilts one way, sometimes the other.
What we need to do is keep writing good software in Zig. I expect it will find its natural niche in high-assurance software: performance-critical low-level systems where bugs are not an acceptable outcome. These systems don’t have a special carve-out for memory bugs, where it’s ok to have logic bugs or crash on a bounds-check as long as memory isn’t corrupted. Bugs are not acceptable and memory bugs are an example of an unacceptable defect which must be corrected before the software is complete.
Zig’s values are a natural fit here, because it provides all the tools needed to detect memory errors in the course of development, and also emphasizes simplicity, explicit control flow, and legibility of the source code. TigerBeetle is actively demonstrating that Zig is a useful language for this kind of task.
I hope Zig gets pinning and ability to detect if I’ve accidentally returned a pointer to the current function scope. For the last 2 ys, these were the only bugs I had/found.
EDIT: What I’m trying to say is that Zig is IMHO very close to “safe” languages already. If you pass allocators and use arena to denote lifetimes, and compile with ReleaseSafe, you should be quite ok.
How are we going to sell Zig?
Make great software that users love.
Don’t say it’s written in Zig, just make everyone want to use the software. Make the software fast and bug-free without putting “blazingly fast” in your readme.
Quietly delight users, and then when they look under the hood, they find Zig and think, “I knew it!”.
Just my opinion.
Odd business plan. Was hoping for more conventional ideas like “vendor lock in”, or Open Core Model. /sarc
“The compiler is free, but you have to buy the proprietary optimizations”
And there are implementation bugs (which take a long time to fix), demonstrated by this package GitHub - Speykious/cve-rs: Blazingly 🔥 fast 🚀 memory vulnerabilities, written in 100% safe Rust. 🦀 :
cve-rs implements the following bugs in safe Rust:
- Use after free
- Buffer overflow
- Segmentation fault
cve-rs also contains safe reimplementations of:
std::mem::transmutestd::ptr::null()/null_mut()but for references
Explained in these videos:
Every language that claims to be safe has this issue, that it may not actually live up to that 100% in its implementation, personally I don’t really want to rely on a type system that is complex, because I see the implementation of the language as part of my responsibility as a developer and ultimately I would want to understand not only how to use the language, but also how it is implemented.
IMHO Rust seems too complex to me, like it would require several people each specialized in one area, with Zig I feel more hopeful that I may have an at least basic understanding of all of its parts, eventually, in a more practical amount of time.
I also find the approach of having a multitude of tools, that when applied correctly, provide safety in specific ways, a more practical way to approach safety. That way specific tools can have a bug, while others still work, seems like this would allow for a more gradual and incremental way to approach a more safe future.
When safety is discussed, I always have to think about lock-picking demonstrations and the various ways they get around a lock that was supposed to be safe. I think safety shouldn’t be thought of as a global property, but instead as something that needs to be considered at every level of detail and for every boundary or new element that is added.
When a language is hyped for being safe, but then its implementation has bugs, I think all people using the resulting software end up in a worse place, where the developers are less aware of having to look out for exploits, like what is demonstrated above, and operating from a false sense of security.
If anything I would want the Rust community to put a spotlight on these soundness issues and develop practices around making sure that none of those are used in popular packages, until they are fixed.
Currently it seems to me like not many people are aware of these problems existing, which means that less careful developers may add packages to their projects that use those exploits. (To be fair, maybe it is more known once you are actually part of the community, than it seems to me looking from the outside?)
With languages that don’t claim to be safe, developers are more prepared to take responsibility for the code and dependencies that they rely on and to carefully vet them. (But to be fair, there is also no guarantee that they actually do it.)
Ultimately I think both approaches have their benefits (complex type system vs simpler type system), but I think Rust has some problems to overcome in its implementation and personally I would like it if those were communicated in a more prominent space, to people who consider using the language, instead of having to read a blog post, which seems a bit like shoving it under the carpet.
Inspired by Zig, in my personal C projects I’ve been using a get macro that gives trapped slice bounds checking in sanitized debug builds and no overhead in release. Obviously not idiomatic, but it is essentially equivalent to Zig outside of using get(slice, i) rather than slice[i] syntax.