The concept of lifetimes was invented long before Rust borrow checker was even "scratched on paper." Of course, people who understand what they are they doing have known about these concepts for decades and have built their architectures around them. However, Rust borrow checker is much stricter than that. You have to build your architecture around the fact that you can't have more than one mutable reference at a time, and your data structures have to be represented as directed, acyclic graphs, etc. If you have to break all these rules by using a lot of unsafe because it's too difficult to represent your system within Rust safe subset using only value semantics and borrow-checked references, etc, then why use Rust instead of C++, C, or Zig?
What I mentioned is only a tiny part of the entire software, which has been successfully written in C, C++, and now in Zig as well, and is used daily by people around the world.
For 99.99% of cases, you're reading and writing this under an operating system whose kernel is written in a language without send/sync, and inside a browser that also largely written in languages without send/sync, because those systems are fundamentally well designed. So instead of fixing the bugs and rethinking the architecture, the author of Bun decided to transpile almost the entire codebase from Zig to Rust without a deep architectural review. Okay...
If you use Rust the way it was designed to be used, rather than relying on countless "unsafe" blocks, you need to redesign the entire codebase architecture to make it compatible with the borrow checker rules.
To me, this whole effort of rewriting Bun from Zig to Rust looks like a big marketing move. The question is: if Anthropic AI is really that powerful, why not just fix the bugs and give it the more ambitious task of redesigning the existing Bun Zig codebase in a way that eliminates not only the current bugs but also prevents similar ones from happening in the future?
2664 "unsafe {", 1835 "unsafe fn". This is completely unsafe. It doesn't look like a rewrite that understands what's actually going on or how the architecture should be redesigned to take advantage of Rust strengths. Instead, it looks like an AI generated transpilation with extensive use of raw pointers.
The biggest advantages of Zig for me are that everything is explicit (no hidden features like overloads or implicit conversions) and that its metaprogramming is powerful, easy to use, and easy to understand.
Just look at this: https://pvs-studio.com/en/blog/posts/cpp/1129/ - 11 parts about C++ undefined behavior from people who specialize in finding this stuff. And that’s only the tip of the iceberg.
I use C++ daily, and it’s an overcomplicated language. The really good thing about Rust or Zig is that (mostly) everything is explicit, and that’s a big win in my opinion.
In defense of C++, I can only say that lots of interesting projects in the world are written in it.
No, it does. "The only two features in the language that do not follow the zero-overhead principle are runtime type identification and exceptions, and are why most compilers include a switch to turn them off." - https://en.cppreference.com/w/cpp/language/Zero-overhead_pri...
At first glance, when I looked through the Zig reference, I didn’t like a lot about its syntax (though syntax isn’t the most important thing for me). But when I tried writing in it, I changed my mind - it’s a concise and convenient language with a very low entry barrier. It feels like Go, and with some C experience, you can quickly start writing functional stuff.
"func" is fine; "function" is too long. "fn" is also good, but for example, Go was designed with "func," and it's one of the most successful, readable languages in the world, so why not?
This is true. I agree with this statement. It's the holy cow of C. However, the problem with generic programming and metaprogramming isn't going away, and many people continue to struggle with it. Introducing something like compile-time reflection might be a solution...
I'm currently at a crossroads: C++ or Zig. One is very popular with a large community, amazing projects, but has lots of ugly design decisions and myriad rules you must know (this is a big pain, it seems like even Stroustrup can't handle all of them). The other is very close to what I want from C, but it's not stable and not popular.
Hey, I understand you and know this stuff well, having worked with it for many years as a C dev. To be honest, this isn't how things should generally be done. Macros were invented for very simple problems. Yes, we can abuse them as much as possible (for example, in C++, we discovered SFINAE, which is an ugly, unreadable technique that wasn't part of the programming language designer's intent but rather like a joke that people started abusing), but is it worth it?
Many C programmers need proper generic programming mechanisms (perhaps something like Zig's comptime) in C, but macros are the worst possible approach, and they don't want to switch to a different language like C++. As a result, they struggle with these issues. This is what I think the standardization committee should focus on, but instead, they introduced _Generic.