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

171–180 of 599 posts

Re: Thoughts on Go vs. Rust vs. Zig

#171

Post by kibwen »

irishcoffee wrote: post #146
stouset wrote: post #131

Earlier quoted context omitted.

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 someh…

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

What? The Cloudflare bug was from a broken system configuration that eventually cascaded into (among other things) a Rust program with hardcoded limits that crashed loudly. In no way did that Rust program bring down the internet; it was the canary, not the gas leak. Anybody trying to blame Rust for that event has no idea what they're talking about.

Re: Thoughts on Go vs. Rust vs. Zig

#172

Post by tayo42 »

oncallthrow wrote: post #46

> Other features common in modern languages, like tagged unions or syntactic sugar for error-handling, have not been added to Go. > It seems the Go development team has a high bar for adding features to the language. The end result is a language that forces you to write a lot of boilerplate code to implement logic that could be more succinctly expressed in another language. Being able to implement logic more succinct…

I feel like almost always `?` is a mistake in Rust and should just be used for quick test code like using unwrap.

Go's wrapping of errors is just a crappy exception stack trace with less information.

Re: Thoughts on Go vs. Rust vs. Zig

#173

Post by dlisboa »

int_19h wrote: post #161
dlisboa wrote: post #124

Earlier quoted context omitted.

> Go programmer attitude is "do what I said, and trust that I read the library docs before I said it". I agree and think Go gets unjustly blamed for some things: most of the foot guns people say Go has are clearly laid out in the spec/documentation. Are these surprising behaviors or did you just not read? Getting a compiler and just typing away is not a great way of going about learning things if that compiler is not…

It's not unjust to blame the tool if it behaves contrary to well established expectation, even if that's documented - it's just poor ergonomics then.

Outside very simple programming techniques there is no such thing as well-established when it comes to PL. If one learns more than a handful of languages they’ll see multiple ways of doing the same thing.

As an example all three of the languages in the article have different error handling techniques, none of which are actually the most popular choice.

Built in data structures in particular, each language does them slightly differently to there’s no escaping learning their peculiarities.

Re: Thoughts on Go vs. Rust vs. Zig

#174

Post by nu11ptr »

irishcoffee wrote: post #146
stouset wrote: post #131

Earlier quoted context omitted.

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 someh…

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

Tell me which magic language creates programs free of errors? It would have been better had it crashed and compromised memory integrity instead of an orderly panic due to an invariant the coder didn't anticipate? Type systems and memory safety are nice and highly valuable, but we all know as computer scientists we have yet to solve for logic errors.

Re: Thoughts on Go vs. Rust vs. Zig

#175

Post by teleforce »

>I’m not the first person to pick on this particular Github comment, but it perfectly illustrates the conceptual density of Rust:

https://github.com/rust-lang/rust/issues/68015#issuecomment-...

Wow, Rust does take programming complexity to another level.

Everything, including programming languages, need to be simple but no simpler. I'm of the opinion that most the computing and memory resources complexity should be handled and abstracted by the OS for example the address space isolation [1].

The author should try D language where it's the Goldilocks of complexity and meta programming compared to Go, Rust and Zig [2].

[1] Linux address space isolation revived after lowering performance hit (59 comments):

https://news.ycombinator.com/item?id=44899488

[2] Ask HN: Why do you use Rust, when D is available? (255 comments):

https://news.ycombinator.com/item?id=23494490 [2]

Re: Thoughts on Go vs. Rust vs. Zig

#176

Post by silisili »

PaulKeeble wrote: post #155
auxiliarymoose wrote: post #132

Earlier quoted context omitted.

Agreed. Rob Pike presented a good talk "Concurrency is not Parallelism" which explains the motivations behind Go's concurrency model: https://youtu.be/oV9rvDllKEg Between the lack of "colored functions" and the simplicity of communicating with channels, I keep surprising myself with how (relatively) quick and easy it is to develop concurrent systems with correct behavior in Go.

Its a bit messy to do parallelism with it but it still works and its a consistent pattern and their are libraries that add it for the processing of slices and such. It could be made easier IMO, they are trying to dissuade its use but its actually really common to want to process N things distributed across multiple CPUs nowadays.

True. But in my experience, the pattern of just using short lived goroutines via errgroup or a channel based semaphore, will typically get you full utilization across all cores assuming your limit is high enough.

Perhaps less guaranteed in patterns that feed a fixed limited number of long running goroutines.

Re: Thoughts on Go vs. Rust vs. Zig

#177

Post by kibwen »

10000truths wrote: post #134
kibwen wrote: post #93

Earlier quoted context omitted.

> No more praying that your program isn't unceremoniously killed just for asking for more memory - all allocations are assumed fallible and failures must be handled explicitly. But for operating systems with overcommit, including Linux, you won't ever see the act of allocation fail, which is the whole point. All the language-level ceremony in the world won't save you.

Sure, but you can do the next best thing, which is to control precisely when and where those allocations occur. Even if the possibility of crashing is unavoidable, there is still huge operational benefit in making it predictable. Simplest example is to allocate and pin all your resources on startup. If it crashes, it does so immediately and with a clear error message, so the solution is as straightforward as "pass bi…

No, this is still misunderstanding.

Overcommit means that the act of memory allocation will not report failure, even when the system is out of memory.

Instead, failure will come at an arbitrary point later, when the program actually attempts to use the aforementioned memory that the system falsely claimed had been allocated.

Allocating all at once on startup doesn't help, because the program can still fail later when it tries to actually access that memory.

Re: Thoughts on Go vs. Rust vs. Zig

#178

Post by bigstrat2003 »

irishcoffee wrote: post #146
stouset wrote: post #131

Earlier quoted context omitted.

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 someh…

> Hmm, according to whom, exactly?

Well, Google for one. https://security.googleblog.com/2025/11/rust-in-android-move...

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

You're ignoring other factors (it wasn't just Cloudflare's rust code that led to the issue), but even setting that aside your framing is not accurate. The rust program went down because the programmer made a choice that, given invalid input, it should crash. This could happen in every language ever made. It has nothing to do with rust.

Re: Thoughts on Go vs. Rust vs. Zig

#179

Post by ux266478 »

iainmerrick wrote: post #89
ux266478 wrote: post #52

Generally a good writeup, but the article seems a bit confused about undefined behavior. > What is the dreaded UB? I think the best way to understand it is to remember that, for any running program, there are FATES WORSE THAN DEATH. If something goes wrong in your program, immediate termination is great actually! This has nothing to do with UB. UB is what it says on the tin, it's something for which no definition is…

Race conditions, silent bugs, etc. can occur as the result of the compiler mangling your code thanks to UB, but so can crashes and a myriad of other things. [...] That's it. That's all there is to UB. You don’t think that’s pretty bad?

They can also occur from defined behavior. The point being that they're completely besides one another.

Re: Thoughts on Go vs. Rust vs. Zig

#180

Post by kachapopopow »

int_19h wrote: post #163
kachapopopow wrote: post #156

Earlier quoted context omitted.

it's not about triviality, but why not use what is generally accepted already, why did zig decide to be different?

What is "generally accepted" though? If you mean C-style declarations, the fact that tools such as https://linux.die.net/man/1/cdecl even exist to begin with shows what's wrong with it.

(array?) (:)= (value)

([:] [(->/:) type]

[import/use/using] ([/|:|::|.] | "file") (ok header files are a relic of the past I have to admit that)

I tried writing zig and as someone who has pretty much written in every commonly used language it just felt different enough where I kept having to look up the syntax.

Post reply on HN