[rjzzleep]

To call Rust syntax beautiful is a stretch. It seems that way in the beginning but then quickly devolves into a monstrosity when you start doing more complex things.

Zig on the other specifically addresses syntax shortcomings in part of C. And it does it well. That claim of rust making C more safe because it’s more readable applies to Zig more than it does to Rust.

I feel like the reason the rust zealots lobby like crazy to embed rust everywhere is twofold. One is that they genuinely believe in it and the other is that they know that if other languages that address one of the main rust claims without all the cruft gains popularity they lose the chance of being permanently embdedded in places like the kernel. Because once they’re in it’s a decade long job market

[hnarn]

> they know that if other languages that address one of the main rust claims without all the cruft gains popularity they lose the chance of being permanently embdedded in places like the kernel

First of all, I'm really opposed to saying "the kernel". I am sure you're talking about the Linux kernel, but there are other kernels (BSD, Windows etc.) that are certainly big enough to not call it "the" kernel, and that may also have their own completely separate "rust-stories".

Secondly, I think the logic behind this makes no sense, primarily because Rust at this point is 10 years old from stable and almost 20 years old from initial release; the adoption into the Linux kernel wasn't exactly rushed. Even if it was, why would Rust adoption in the Linux kernel exclude adoption of another language as well, or a switch to another, if it's better? The fact that Rust was accepted at all to begin with aside from C disproves the assumption, because clearly that kernel is open for "better" languages.

The _simplest_ explanation to why Rust has succeeded is that it's solves actual problems, not that "zealots" are lobbying for it to ensure they "have a job".

[throw9404049]

> Rust at this point is 10 years old from stable

Rust is not stable even today! There is no spec, no alternative implementations, no test suite... "Stable" is what "current compiler compiles"! Existing code may stop compiling any day....

Maybe in 10 years it may become stable, like other "booring" languages (Golang and Java).

Rust stability is why Linus opposes its integration into kernel.

[bayindirh]

In the "other good news department", GCC is adding a Rust frontend to provide the alternative implementation, and I believe Rust guys accepted to write a specification for the language.

I'm waiting for gccrs to start using the language, actually.

[latexr]

> To call Rust syntax beautiful is a stretch.

I don’t see where the comment you’re replying to does that (was it edited?). Their comment says nothing about aesthetics.

[fransje26]

Higher up

> Rust is the small, beautiful language hiding inside of Modern C++

[ModernMech]

That says Rust is beautiful, not its syntax.

[bayindirh]

> To call Rust syntax beautiful is a stretch.

I'm no Rust fan, but beauty of a syntax is always in the eye of the beholder.

I personally find Go, C++ and Python's syntax beautiful. All can be written in very explicit or expressive forms. On the other hand, you can hide complexity to a point.

If you are going to do complex things in a compact space, you'll asymptotically approach Perl or PCRE. It's maths.

All code is maths, BTW.

[kibwen]

> if other languages that address one of the main rust claims without all the cruft

But regardless of how much one likes Zig, it addresses none of the problems that Rust seeks to solve. It's not a replacement for Rust at all, and isn't suitable for any of the domains where Rust excels.

[sgt]

> and isn't suitable for any of the domains where Rust excels.

That's a pretty bold claim since Zig is specifically designed for systems programming, low level stuff, network services, databases (think Tigerbeetle). It's not memory safe like Rust is, but it comes with constructs that make it simple to build largely memory safe programs.

[JuniperMesos]

> It's not memory safe like Rust is, but it comes with constructs that make it simple to build largely memory safe programs.

Right, this is the specific important thing that Rust does that Zig doesn't (with the caveat that Rust includes the `unsafe` mechanism - as a marked, non-default option - specifically to allow for necessary low-level memory manipulation that can't be checked for correctness by the compiler). Being able to guarantee that something can't happen is more valuable than making it simple to do something correctly most of the time.

[dns_snek]

It's not that simple though, Zig has equivalent spatial memory safety which prevents issues that are pretty consistently among (or at) the top of the list for most dangerous vulnerability classes.

And while I don't have enough experience with Rust to claim this first hand, my understanding is that writing correct unsafe Rust code is at least an order of magnitude harder than writing correct Zig code due to all of the properties/invariants that you have to preserve. So it comes with serious drawbacks, it's not just a quick "opt out of the safety for a bit" switch.

> Being able to guarantee that something can't happen is more valuable than making it simple to do something correctly most of the time.

Of course, all other things being equal, but they're not.

[goku12]

> And while I don't have enough experience with Rust to claim this first hand, my understanding is that writing correct unsafe Rust code is at least an order of magnitude harder than writing correct Zig code due to all of the properties/invariants that you have to preserve.

How do you make such boldly dismissive assertions if you don't have enough experience with Rust? You are talking as if these invariants are some sort of requirements/constraints that the language imposes on the programmer. They're not. It's a well-known guideline/paradigm meant to contain any memory safety bugs within the unsafe blocks. Most of the invariants are specific to the problem at hand, and not to the programming language. They are conditions that must be met in any language - C and Zig are no exceptions. Failure to adhere to them will land you in trouble, no matter what sort of safety your language guarantees. They are often talked about in the context of Rust because the ones related to memory-unsafe operations can be tackled and managed within the small unsafe blocks, instead of being sprawling it throughout the code base.

> So it comes with serious drawbacks, it's not just a quick "opt out of the safety for a bit" switch.

Rust is not the ultimate solution to every problem in the world. But this sort of exaggeration and hyperbole is misleading and doesn't help anyone choose any better.

[dns_snek]

> How do you make such boldly dismissive assertions

As I said that's my understanding from talking and listening to people who have a lot of experience with Rust, Zig, and C.

So generally speaking, are you saying that writing correct unsafe Rust is only as difficult as writing correct Zig code and not, as I understand it to be, significantly more difficult?

[JuniperMesos]

> And while I don't have enough experience with Rust to claim this first hand, my understanding is that writing correct unsafe Rust code is at least an order of magnitude harder than writing correct Zig code due to all of the properties/invariants that you have to preserve. So it comes with serious drawbacks, it's not just a quick "opt out of the safety for a bit" switch.

I think this is hard to generalize about. There are many instances where one might want to do unsafe memory operations in rust, with different correctness implications. I am suspicious that in Zig you do actually have to preserve all the same properties and invariants, and there's just nothing telling you if you did so or not or even what all of them are, so you don't know if your code is correct or not.

[ViewTrick1002]

I would compare the recent Rust Android post [1], where they have a 5000x lower memory vulnerability rate compared to traditional C/C++ with the number of segfaults found in Bun. [2]

In my opinion Zig does not move the needle on real safety when the codebase becomes sufficiently complex.

[1]: https://security.googleblog.com/2025/11/rust-in-android-move...

[2]: https://github.com/oven-sh/bun/issues?q=segfault%20OR%20segm...

[dns_snek]

Why are we comparing a number of exploitable vulnerabilities to the number of segfault reports? Where does the "5000x" figure come from?

[sgt]

Sure but there's this belief in the Rust community that it's not responsible anymore to write software that isn't memory safe on the same level as Rust.

So Zig would fail that, but then you could also consider C++ unsuitable for production software - and we know it clearly is still suitable.

I predict Zig will just become more and more popular (and with better, although not as complete- memory safety), and be applied to mission critical infra.

[pjmlp]

If we ignore recent movents in govermental cybersecurity agencies, and big tech to move away from unsafe programming languages, as much as technically possible.

Introducing a language with the same safety as Modula-2 or Object Pascal, would make sense in the 1990's, nowadays with improved type systems making the transition from academia into mainstream, we (the industry) know better.

It is not only Rust, it is Linear Haskell, OCaml effects, Swift 6 ownership model, Ada/SPARK, Chapel,....

[sgt]

Of those listed, I'd bet Swift (having had experience with it) is the most pleasant to work with. I just hope it takes off on the systems and backend side at some point.

[JuniperMesos]

> So Zig would fail that, but then you could also consider C++ unsuitable for production software - and we know it clearly is still suitable.

Speak for yourself, I never want to write C++ ever again in my life.

I'm not a huge fan of the language of responsibility. I don't think there should be a law banning the use of C or C++ or any other programming language on account of it being unsafe, I don't think that anyone who writes in C/C++ is inherently acting immorally, etc.

What I do think is that Rust is a better-designed language than C or C++ and offers a bunch of affordances, including but not limited to the borrow checker, unsafe mode, the type system, cargo, etc. that make it easier and more fun for programmers to use to write correct and performant software, most of the time in most cases. I think projects that are currently using C/C++ should seriously consider switching off of them to something else, and Rust is an excellent candidate but not the only candidate.

I think Zig is also almost certainly an better language than C/C++ in every respect (I hedge more here because I'm less familiar with Zig, and because it's still being developed). Not having as strong memory safety guarantees as Rust is disappointing and I expect that it will result in Zig-written software being somewhat buggier than Rust-written software over the long term. But I am not so confident that I am correct about this, or that Zig won't bring additional benefits Rust doesn't have, that I would argue that people shouldn't use Zig or work on languages like Zig.

[ViewTrick1002]

Given the density of memory issues in the Bun issue tracker I have a hard time squaring the statement that Zig makes it "easy" to build memory safe programs.

https://github.com/oven-sh/bun/issues?q=segfault%20OR%20segm...

[nvlled]

> https://github.com/oven-sh/bun/issues?q=segfault%20OR%20segm...

It should be noted that most of those issues are created by opening a link that bun creates when it crashes, they are not yet reviewed/confirmed and most likely a lot of them are dulplicates of the same issue.

[ViewTrick1002]

Comparing Deno most of their segfaults come from having to integrate with V8, and their density is a fraction compared to Bun.

[GuB-42]

Rust is not designed for low level system programming / embedded systems like Zig is. It is designed to make a browser and software that share requirements with making a browser.

There is some overlap but that's still different. The Zig approach to memory safety is to make everything explicit, it is good in a constrained environment typical of embedded programming. The Rust approach is the opposite, you don't really see what is happening, but there are mechanisms to keep your safe. It is good for complex software with lots of moving parts in an unconstrained environment, like a browser.

For a footgun analogy, one will hand you a gun that will never go off unless you aim and pull the trigger, so you can shoot your foot, but no sane person will. It is a good sniper rifle. The Rust gun can go off at any time, even when you don't expect it, but it is designed in such a way that it will never happen when it is pointed at your foot, even if you aim it there. It is a good machine gun.

[Ygg2]

> Rust is not designed for low level system programming / embedded systems like Zig is.

Pray tell, with Rust already being used in kernels, drivers, and embedded what makes Zig better suited for low-level systems?

More chance to explode a UB in your hand? For that, there is C.

[GuB-42]

Great C interop, first class support for cross-compilation, well suited for arena allocators.

You can use Rust in kernel/embedded code, you can also use C++ (I did) and even Java! but most prefer to use C, and I think that Zig is a better alternative to C for those in the field.

There is still one huge drawback with Zig and that's maturity. Zig is still in beta, and the closest you get to the metal, the more it tends to matter. Hardware projects typically have way longer life cycles and the general philosophy is "if it ain't broke, don't fix it". Rust is not as mature as C by far, there is a reason C is still king, but at least, it is out of beta and is seeing significant production use.

I remember when I talk about Zig to the CTO of the embedded branch of my company. His reaction was telling. "I am happy to hear someone mention Zig, it is a very interesting language and it is definitely on my watch list, but not mature enough to invest in it". He was happy that I mentioned Zig because in the company, the higher ups are all about Rust because of the hype, even though we do very little of if BTW, it is still mostly C and C++. And yeah, hype is important, customers heard about Rust as some magical tech that will make the code bug-free, they didn't hear about Zig, so Rust sells better. In the end, they go for C anyways.

[Ygg2]

> Great C interop, first class support for cross-compilation, well suited for arena allocators.

C interop and arena allocators aren't hard requirements for a kernel language. In fact, why would a kernel in <INSERT LANG> need to talk to C? You need it to talk to Assembly/Machine code, not C.

It helps if it can talk to/from C but it's not a requirement.

> customers heard about Rust as some magical tech that will make the code bug-free

That's on customers not having a clear picture. What we can look at experimentally is that yes, Rust will remove a whole suite of bugs, and no, Zig won't help there. Is Zig better than C? Sure, but so is C++ and it still sucks at it.

Like, the few big things wrong with Rust is probably compilation speed and async needing more tweaks (pinned places ergonomics, linear types to deal with async drop...) to make it way better.

[andy12_]

For my part, I don't know why, but Zig's syntax feels wrong to me. I don't even know why. I really want to like its syntax, as Zig seems really promising to me, but I just don't, which makes it not very enjoyable for me to write.

I don't know if it's my lack of practice, but I never felt the same about, say, Rust's syntax, or the syntax of any other language for that matter.

[keybored]

> I feel like

Needless flame bait follows.