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

291–300 of 599 posts

Re: Thoughts on Go vs. Rust vs. Zig

#291

Post by disappoint »

bigstrat2003 wrote: post #178
irishcoffee wrote: post #146

Earlier quoted context omitted.

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

Google's Android teams also categorize old C code as C++, and mix gotos into their modern C++ code.

Re: Thoughts on Go vs. Rust vs. Zig

#292

Post by mirashii »

ux266478 wrote: post #196
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…

> Code that invokes UB is incorrect, full stop. That's not true at all, who taught you that? Think of it like this, signed integer over/underflow is UB. All addition operations over ints are potentially invoking UB. int add (int a, int b) { return a + b; } So this is incorrect code by that metric, that's clearly absurd. Compilers explicitly provide you the means to disable optimizations in a granular way over undefin…

> -fno-strict-aliasing doesn't suddenly make pointer aliasing defined behavior.

No, it just protects you from a valid but unexpected optimization to your incorrect code. It's even spelled out clearly in the docs: https://www.gnu.org/software/c-intro-and-ref/manual/html_nod...

"Code that misbehaves when optimized following these rules is, by definition, incorrect C code."

> We have compiler behavior for incorrect code, and it's refusing to compile the code in the first place

This isn't and will never be true in C because whether code is correct can be a runtime property. That add function defined above isn't incorrect on its own, but when combined with code that at runtime calls it with values that overflows, is incorrect.

Re: Thoughts on Go vs. Rust vs. Zig

#293

Post by skybrian »

wrs wrote: post #60

> In Go, a slice is a fat pointer to a contiguous sequence in memory, but a slice can also grow, meaning that it subsumes the functionality of Rust’s Vec type and Zig’s ArrayList. Well, not exactly. This is actually a great example of the Go philosophy of being "simple" while not being "easy". A Vec has identity; the memory underlying a Go slice does not. When you call append(), a new slice is returned that may or ma…

It seems kind of odd that the Go community doesn't have a commonly-used List[T] type now that generics allow for one. I suppose passing a growable list around isn't that common.

Re: Thoughts on Go vs. Rust vs. Zig

#294

Post by metaltyphoon »

vips7L wrote: post #120
dmoy wrote: post #4

For a lot of stuff what I really want is golang but with better generics and result/error/enum handling like rust.

Me too. There’s a huge market for a natively compiled language with GC that has a better type system than Go. The options I’ve seen so far are: OCaml, D, Swift, Nim, Crystal, but none of them have seen to be able to capture a significant market.

C#?

Re: Thoughts on Go vs. Rust vs. Zig

#295

Post by yawaramin »

throwaway894345 wrote: post #24
Yoric wrote: post #20

Earlier quoted context omitted.

Have you tried OCaml? With the latest versions, it also has an insanely powerful concurrency model. As far as I understand (I haven't looked at the benchmarks myself), it's also performance-competitive with Go.

How's the build tooling these days? Last I tried, it used some jbuild/dune + makefiles thing that was really painful to get up and running. Also there were multiple standard libraries and (IIRC) async runtimes that wouldn't play nicely together. The syntax and custom operators was also a thing that I could not stop stubbing my toes on--while I previously thought syntax was a relatively unimportant concern, my experie…

    $ dune init project my-project
    $ dune build
That's it, now you have a compiling project and can start hacking.

Re: Thoughts on Go vs. Rust vs. Zig

#297

Post by Mawr »

mh2266 wrote: post #119
unshavedyak wrote: post #5

Earlier quoted context omitted.

Rust is hard in that it gives you a ton of rope to hang yourself with, and some people are just hell bent on hanging themselves. I find Rust quite easy most of the time. I enjoy the hell out of it and generally write Rust not too different than i'd have written my Go programs (i use less channels in Rust though) . But i do think my comment about rope is true. Some people just can't seem to help themselves.

I feel like it is the opposite, Go gives you a ton of rope to hang yourself with and hopefully you will notice that you did: error handing is essentially optional, there are no sum types and no exhaustiveness checks, the stdlib does things like assume filepaths are valid strings, if you forget to assign something it just becomes zero regardless of whether it’s semantically reasonable for your program to do that, no n…

> error handing is essentially optional

Theoretically optional, maybe.

> the stdlib does things like assume filepaths are valid strings

A Go string is just an array of bytes.

The rest is true enough, but Rust doesn't offer just the bare minimum features to cover those weaknesses, it offers 10x the complexity. Is that worth it?

Re: Thoughts on Go vs. Rust vs. Zig

#298

Post by tptacek »

nu11ptr wrote: post #271
tptacek wrote: post #254

Earlier quoted context omitted.

Right, for error handling, I'd rather have Rust's bones to build on than Go's. I prefer Go to Rust --- I would use Go in preference to Rust basically any time I could get away with it (acknowledging that I could not get away with it if I was building a browser or an LKM). But this part of Rust's type system is meaningfully better than Go's. Which is why it's weird to me that the error handling culture of Rust seems t…

Interesting. It is semi-rare that I meet someone who knows both Rust and Go and prefers Go. Is it the velocity you get from coding in it? I have a love/hate relationship with Go. I like that it lets me code ideas very fast, but my resulting product just feels brittle. In Rust I feel like my code is rock solid (with the exception of logic, which needs as much testing as any other lang) often without even testing, just…

I think this is kind of a telling observation, because the advantage to working in Go over Rust is not subtle: Go has full automatic memory management and Rust doesn't. Rust is safe, like Go is, but Rust isn't as automatic. Building anything in Rust requires me to make a series of decisions that Go doesn't ask me to make. Sometimes being able to make those decisions is useful, but usually it is not.

The joke I like to snark about in these kinds of comparisons is that I actually like computer science, and I like to be able to lay out a tree structure when it makes sense to do so, without consulting a very large book premised on how hard it is to write a doubly-linked list in Rust. The fun thing is landing that snark and seeing people respond "well, you shouldn't be freelancing your own mutable tree structures, it should be hard to work with trees", from people who apparently have no conception of a tree walk other than as a keyed lookup table implementation.

But, like, there are compensating niceties to writing things like compilers in Rust! Enums and match are really nice there too. Not so nice that I'd give up automated memory management to get them. But nice!

I'm an ex-C++/C programmer (I dropped out of C++ around the time Alexandrescu style was coming into vogue), if my background helps any.

Re: Thoughts on Go vs. Rust vs. Zig

#299

Post by gt0 »

I think it overstates the complexity and difficulty of Rust. It has some hard concepts, but the toolchain/compiler is so good that it practically guides you through using them.

Re: Thoughts on Go vs. Rust vs. Zig

#300

Post by auxiliarymoose »

kibwen wrote: post #228
Rikudou wrote: post #76

I think the Go part is missing a pretty important thing: the easiest concurrency model there is. Goroutines are one of the biggest reasons I even started with Go.

I'll disagree with you there. Structured concurrency is the easiest concurrency model there is: https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

But how does one communicate and synchronize between tasks with structured concurrency?

Consider a server handling transactional requests, which submit jobs and get results from various background workers, which broadcast change events to remote observers.

This is straightforward to set up with channels in Go. But I haven't seen an example of this type of workload using structured concurrency.

Post reply on HN