Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thoughts on Go vs. Rust vs. Zig

sinclairtarget.com

Post reply on HN
Print view View original

141–150 of 599 posts

Re: Thoughts on Go vs. Rust vs. Zig

#141

Post by zozbot234 »

bsder wrote: post #128
raggi wrote: post #11

I really hate the anti-RAII sentiments and arguments. I remember the Zig community lead going off about RAII before and making claims like "linux would never do this" ( https://github.com/torvalds/linux/blob/master/include/linux/... ). There are bad cases of RAII APIs for sure, but it's not all bad. Andrew posted himself a while back about feeling bad for go devs who never get to debug by seeing 0xaa memory segments,…

> So RAII isn't the big evil monster, and we need to stop talking about RAII, globals, etc, in these ways. I disagree and place RAII as the dividing line on programming language complexity and is THE "Big Evil Monster(tm)". Once your compiled language gains RAII, a cascading and interlocking set of language features now need to accrete around it to make it ... not excruciatingly painful. This practically defines the…

> Every adherent of managed memory languages should take it as a personal insult that people are choosing to write modern terminal emulators in Rust and Zig.

How so? Garbage collection has inherent performance overhead wrt. manual memory management, and Rust now addresses this by providing the desired guarantees of managed memory without the overhead of GC.

A modern terminal emulator is not going to involve complex reference graphs where objects may cyclically reference one another with no clearly-defined "owner"; which is the one key scenario where GC is an actual necessity even in a low-level systems language. What do they even need GC for? Rather, they should tweak the high-level design of their program to emsure that object lifetimes are properly accounted for without that costly runtime support.

Re: Thoughts on Go vs. Rust vs. Zig

#142

Post by throwawaymaths »

andsoitis wrote: post #139
globalnode wrote: post #48

Earlier quoted context omitted.

so does the rust compiler check for race conditions between threads at compile time? if so then i can see the allure of rust over c, some of those sync issues are devilish. and what about situations where you might have two variables closely related that need to be locked as a pair whenever accessed.

> so does the rust compiler check for race conditions between threads at compile time? My understanding is that Rust prevents data races, but not all race conditions. You can still get a logical race where operations interleave in unexpected ways. Rust can’t detect that, because it’s not a memory-safety issue. So you can still get deadlocks, starvation, lost wakeups, ordering bugs, etc., but Rust gives you: - No data…

and you can have good races too (where the order doesnt matter)

Re: Thoughts on Go vs. Rust vs. Zig

#143

Post by wavemode »

dlisboa wrote: post #129
wavemode wrote: post #118

Earlier quoted context omitted.

I imagine people who care about this sort of thing are happy to disable overcommit, and/or run Zig on embedded or specialized systems where it doesn't exist.

There are far more people running/writing Zig on/for systems with overcommit than not. Most of the hype around Zig come from people not in the embedded world.

I never said that all Zig users care about recovering from allocation failure.

Re: Thoughts on Go vs. Rust vs. Zig

#145

Post by sestep »

raggi wrote: post #11

I really hate the anti-RAII sentiments and arguments. I remember the Zig community lead going off about RAII before and making claims like "linux would never do this" ( https://github.com/torvalds/linux/blob/master/include/linux/... ). There are bad cases of RAII APIs for sure, but it's not all bad. Andrew posted himself a while back about feeling bad for go devs who never get to debug by seeing 0xaa memory segments,…

Heh, sounds like you'd love the work-in-progress I'm about to present at MWPLS 2025 :)

Re: Thoughts on Go vs. Rust vs. Zig

#146

Post by irishcoffee »

stouset wrote: post #131
irishcoffee wrote: post #122

Earlier quoted context omitted.

> Even if you do, you now have an effective comment that tells you where to look if you ever get suspicious behavior. By the time suspicious behavior happens, isn’t it kind of a critical inflection point? For example, the news about react and next that came out. Once the code is deployed, re-deploying (especially with a systems language that quite possibly lives on an air-gapped system with a lot of rigor about updat…

Are you with a straight face saying that occasionally having a safety bug in limited unsafe areas of Rust is functionally the same as having written the entire program in an unsafe language like C? One, the dollar cost is not the same. The baseline floor of quality will be higher for a Rust program vs. a C program given equal development effort. Second, the total possible footprint of entire classes of bugs is zero t…

> The baseline floor of quality will be higher for a Rust program vs. a C program given equal development effort.

Hmm, according to whom, exactly?

> Second, the total possible footprint of entire classes of bugs is zero thanks to design features of Rust (the borrowck, sum types, data race prevention), except in a specifically delineated areas which often total zero in the vast majority of Rust programs.

And yet somehow the internet went down because of a program written in rust that didn’t validate input.

Re: Thoughts on Go vs. Rust vs. Zig

#147

Post by int_19h »

pm90 wrote: post #138

I still don’t get the point of zig, at least not from this post? I really don’t want to do memory management manually. I actually think rust is pretty well designed, but allows you to write very complex code. go tries really hard to keep it simple but at the cost of resisting modern features.

If you don't want to do memory management manually, then you're not the intended target audience for Zig. It's a language where any piece of code that needs to do heap allocation has to receive an allocator as an explicit argument in order to be able to allocate anything at all.

Re: Thoughts on Go vs. Rust vs. Zig

#148

Post by irishcoffee »

mh2266 wrote: post #133
irishcoffee wrote: post #122

Earlier quoted context omitted.

> Even if you do, you now have an effective comment that tells you where to look if you ever get suspicious behavior. By the time suspicious behavior happens, isn’t it kind of a critical inflection point? For example, the news about react and next that came out. Once the code is deployed, re-deploying (especially with a systems language that quite possibly lives on an air-gapped system with a lot of rigor about updat…

This just skips the: > First, if you aren't writing device drivers/kernels or something very low level there is a high probability your program will have zero unsafe usages in it. from the original comment. Meanwhile all C code is implicitly “unsafe”. Rust at least makes it explicit! But even if you ignore memory safety issues bypassed by unsafe, Rust forces you to handle errors, it doesn’t let you blow up on null po…

Isn’t rust proffered up as a systems language? One that begged to be accepted into the Linux kernel?

Don’t device drivers live in the Linux kernel tree?

So, unsafe code is generally approved in device driver code?

Why not just use C at that point?

Re: Thoughts on Go vs. Rust vs. Zig

#149

Post by treyd »

globalnode wrote: post #48
kibwen wrote: post #29

> In Rust, creating a mutable global variable is so hard that there are long forum discussions on how to do it. In Zig, you can just create one, no problem. Well, no, creating a mutable global variable is trivial in Rust, it just requires either `unsafe` or using a smart pointer that provides synchronization. That's because Rust programs are re-entrant by default, because Rust provides compile-time thread-safety. If…

so does the rust compiler check for race conditions between threads at compile time? if so then i can see the allure of rust over c, some of those sync issues are devilish. and what about situations where you might have two variables closely related that need to be locked as a pair whenever accessed.

This was a primary design goal for Rust! To prevent data races (and UAF and other types of memory unsafety) by construction through the type system.

Re: Thoughts on Go vs. Rust vs. Zig

#150

Post by mirashii »

publicdebates wrote: post #110
mirashii wrote: post #91

Earlier quoted context omitted.

> But from my own experience, UB just means "consult your compiler to see what it does here because this question is beyond our pay grade." People are taught it’s very bad because otherwise they do exactly this, which is the problem. What does your compiler do here may change from invocation to invocation, due to seemingly unrelated flags, small perturbations in unrelated code, or many other things. This approach enc…

I understand, but you have to see how you would be considered one of the Standards-Purists that I was talking about, right? If Microsoft makes a guarantee in their documentation about some behavior of UB C code, and this guarantee is dated to about 14 years ago, and I see many credible people on the internet confirming that this behavior does happen and still happens, and these comments are scattered throughout those…

> If Microsoft makes a guarantee in their documentation about some behavior of UB C code

But do they? Where?

More likely, you mean that a particular compiler may say "while the standard says this is UB, it is not UB in this compiler". That's something wholly different, because you're no longer invoking UB.

Post reply on HN