Yeah that’s obviously a cool feature, but I think that’s also a reduction I mean you know this probably 100x better than i do, but Rust is so much more cooler than just it’s memory safety feature yet 99% of the noise is about it’s “memory safety” when it has so much more to it. It’s like if i were to talk about Zig and only mention that it has comptime, like it was the only thing that Zig has going for it. Without mentioning the allocators, the great balance, the C interrop, the package manager, the community, the C/C++ cross-compilation toolchain, the type system, the tagged union, the Io interface, the unit tests, the build system, the custom backends, the custom linkers, the ability to do shading language, the no hidden control flow, etc etc etc. Like there’s so many cool aspect in every language[1] that it feels very narrow.
This reminds me about fireflowers - The Rust Programming Language, in the words of its practitioners 
Different people value different things about Rust! My personal view is pretty much that Rust is mostly safety though 
To paraphrase Jonathan blow, from many years ago when talking about Jai, rust is a “big idea” language, the big idea being the borrow checker. Zig’s big idea is comptime. All other language features, while composed nicely, aren’t really novel, so they don’t get as much attention.
(Somewhat ironically, Jon was lamenting “big idea” languages at the time, only for Jai to become a big idea language of its own with its metaprogramming facilities, but I digress…)
Rust also brought sum types into the mainstream of systems programming (note, I’ve worded this carefully), which became an “I’m never going back” experience for many people.
Now we have other languages like Zig that are suitable for performance-oriented and relatively low-level programming while also offering nice type systems. So it is true that what remains distinctive about Rust is the borrow checker / memory safety model.
I just think it’s worth mentioning that if you ask a bunch of Rustaceans what they like about the language, many answers will point to the expressiveness of its type system.
Count me among them. I first got exposed to sum types learning Elm and was completely enamored with the idea of making illegal states unrepresentable. Before rust I had never gotten into systems programming because I couldn’t bring myself to learn (what felt to me like) antiquated languages like C and C++, so when rust came along with a sane build system and a modern type system, I was all about it.
This is a great example of pseudo-intellectualism. He lacks the self-confidence to make an actual criticism of Rust that can be examined, discussed, debunked, or substantiated. Therefore he resorts to this “big idea” analogy that neither ventures any credibility nor offers any meaningful insight.
Don’t fall into the same trap. To say that Zig’s comptime keyword makes it a “big idea” language is to focus on an obscure detail. Every language has compile-time execution to some degree. Zig just takes it a big further. It’s the sprinkle of salt on an otherwise complete meal, making it tastier, but not any more nutritious than it already was.
Yeah, in my opinion, the most important thing Rust did was its focus on ecosystem.
I hate the direction that the Rust ecosystem has evolved over time, but even for all of its faults, the Rust ecosystem STILL kicks the tar out of the C++, Haskell, OCaml, F#, Lisp/Scheme, etc. ecosystems.
Bun is Zig’s flagship project, and many people know Zig because of Bun. Will rewriting Bun in Rust prompt the development team to accelerate the development of version 1.0?
I’d say Zig is Zigs flagship project. Not to denigrate bun, but put things in proper order. I think the development team has done a good job prioritizing the development of zig and not strictly catering to the needs of large projects using it. it’s a imbalancing act 
, but an important one to get right.
With “wrong” direction (of crates.io mostly I guess?) do you mean missing namespaces, the problems arising when a maintainer “vanishes” (like the xy2 crates), or more? (I guess I missed some I know, but I guess I do also have some blind spots, using it a few times every week..)
The analogy stuck with me because it captured the idea that there’s an easily identifiable thing that set ssome languages apart from others. And I think there’s truth to the fact that if these things didn’t exist, the languages they’re attached to would never have achieved the mainstream success that they did. Of course, Jon frames this in a disparaging way, for the reasons you point out, but I find the analogy useful nonetheless.
I also think you’re doing yourself a disservice by characterizing comptime as an obscure detail. Yeah, rust has CTFE. It also has two different macro systems and generics all decomposed into separate mechanisms that zig managed to collapse into a single mechanism, which just so happens to be the language itself executing at compile time.
Not ISO C, but MISRA C or MISRA C++ (or some other standard which an institution requires, e.g. the pentagon has its own requirements).
For a famous example, see the C++ Coding Standards of the Joint Strike Fighter (i.e., F-35) program (PDF).
Even if it were to happen, I’d hope that the Andrew and co wouldn’t change their plans based on one project’s decisions that may or may not even have anything to do with Zig’s 1.0 status.
Zig is entirely technically and financially independent. Why would any actions taken by Anthropic have any effect on Zig’s roadmap?
-
I don’t like the fact that you must run cargo to resolve everything. Have they fixed cargo at some point so it would at least emit the dependencies?
-
I don’t like the special position of crates.io, period. If you’re not going to review, you shouldn’t anoint. The maintainer problems only exist because crates.io has a special position.
-
The Orphan Rule anoints winners in the ecosystem. Thus you wind up with Serde and Tokio being defaults that you can’t dislodge.
-
Is cross compiling finally not painful?
-
There are crates like syn and proc macros that belong in the compiler and not crates. These are fundamental, tied to the compiler, and definitely need to be maintained by the core people anyhow. Putting them in crates is dumb. There are lots of these kinds of crates that are fundamental to programming in Rust and need to be maintained by the core team and belong in the compiler. However, they stay in crates because nobody wants to step up and make a hard decision.
I have many others. That’s why I use Zig instead of Rust.
However, as I have pointed out, even when I have to fight the Rust ecosystem, that’s still WAY better than the other ecosystems where I have to assemble everything with tweezers, rice grains, and a hot glue gun.
I know these are two independent companies, and Zig has its own roadmap; Anthropic won’t affect Zig. However, while Bun’s departure may have its own business considerations, could it also be due to Zig’s ongoing revisions before releasing version 1.0?
Sure it could be the reason, but don’t take that to mean zig is at fault.
Zig is unstable software, it advertises that upfront; if zig’s breaking changes are an issue for them, then it is bun’s responsibility as they chose zig in the first place.
as far as i inderstand bun uses zig as programming language and minimized usage of std (emagine writing c app without c lib, not exactly but similar)
and as language zig is stable
Nice summary, I’ve been trying Rust for a while before switching to Zig and for me the biggest pain-points were:
- excessive mental gymnastics for things that are ought to be simple (linked lists)
- orphan rule, it’s just stupid, period.
- Rust stdlib is using some features you cannot use yourself (in stable Rust) - stdlib should be a proof that language is viable, not part of the language itself
- 2 different macro-languages (on top of regular rust syntax), yet both are useless unless you reimplement whole ast parsing (syn) yourself - there’s no introspection like we have in Zig
unsafe {}is not a way to use pointers but rather “I am hereby going to check everything what compiler does myself, and ALSO everything what it might check in the future” which is extremely scary (and I have no idea how anyone can say that Rust is safe with such feature)- closures somehow make impression that Rust is FP-friendly, yet it’s unable to express even a simple y-combinator because the borrow-checker cannot prove it’s safe
- the whole safety argument is only true until you interface with anything useful (like OS). we’ve seen that recently with coreutils and it’s also true for any JS/Python/Lua/xxx bindings because as long as you can wrap some user-space function/closure, you’re back in the “compiler can’t prove this safe” land, except that this time you’re out of the borrow checker’s sight. I might be wrong, but from what I’ve learned, you shouldn’t be able to wrap user-space function, that can call rust-side function, that can recur again to user-space function, unless you wrap everything in RefCell<>, and that’s not what people are doing… so it should be insta-undefined behavior.