Thoughts on Go vs. Rust vs. Zig • Hacker News Board

Re: Thoughts on Go vs. Rust vs. Zig

#431

Post by elsjaako » Fri, Dec 05, 2025, 9:59 AM UTC

disappoint wrote: post #283

stouset wrote: post #270

Earlier quoted context omitted.

I am quite certain that someone who has been on HN as long as you have is capable of understanding the difference between 0% compiler-enforced memory safety in a language with very weak type safety guarantees and 95%+ of code regions even in the worst case of low-level driver code that performs DMA with strong type safety guarantees.

Please explain the differences in typical aliasing rules between C and Rust. And please explain posts like https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/ https://news.ycombinator.com/item?id=41947921 https://lucumr.pocoo.org/2022/1/30/unsafe-rust/

The first two is the same article, but they point out that certain structures can be very hard to write in rust, with linked lists being a famous example. The point stands, but I would say the tradeoff is worth it (the author also mentions at the end that they still think rust is great).

The third link is absolutely nuts. Why would you want to initialize a struct like that in Rust? It's like saying a functional programming language is hard because you can't do goto. The author sets themselves a challenge to do something that absolutely goes against how rust works, and then complains how hard it is.

If you want to do it to interface with non-rust code, writing a C-style string to some memory is easier.

Re: Thoughts on Go vs. Rust vs. Zig

#432

Post by ErroneousBosh » Fri, Dec 05, 2025, 10:17 AM UTC

unshavedyak wrote: post #5

echelon wrote: post #2

> Many people seem confused about why Zig should exist if Rust does already. It’s not just that Zig is trying to be simpler. I think this difference is the more important one. Zig wants you to excise even more object-oriented thinking from your code. I feel like Zig is for the C / C++ developers that really dislike Rust. There have been other efforts like Carbon, but this is the first that really modernizes the langu…

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.

What do people generally write in Rust? I've tried it a couple of times but I keep running up against the "immutable variable" problem, and I don't really understand why they're a thing.

Re: Thoughts on Go vs. Rust vs. Zig

#433

Post by LinXitoW » Fri, Dec 05, 2025, 10:18 AM UTC

disappoint wrote: post #290

bigstrat2003 wrote: post #178

Earlier quoted context omitted.

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

> This could happen in every language ever made. It has nothing to do with rust. Except it does. This also has to do with culture. In Rust, I get the impression that one can set it up as roughly two communities. The first does not consider safety, security and correctness to be the responsibility of the language, instead they consider it their own responsibility. They merely appreciate it when the language helps with…

Again, this has nothing to do with the point at hand, which is that "in any language, a developer can choose the crash the problem if a unrecoverable state happens". That's it.

Tell me about how these supposed magical groups have anything at all to do with language features. What language can magically conjure triple the memory from thin air because the upstream query returned 200+ entries instead of the 60-ish you're required to support?

Re: Thoughts on Go vs. Rust vs. Zig

#434

Post by the_gipsy » Fri, Dec 05, 2025, 10:19 AM UTC

Mawr wrote: post #260

the_gipsy wrote: post #73

Earlier quoted context omitted.

"Context" here is just a string. Debugging means grepping that string in the codebase, and praying that it's unique. You can only come up with so many unique messages along a stack. You are also not forced to add context. Hell, you can easily leave errors unhandled, without compiler errors nor warnings, which even linters won't pick up, due to the asinine variable syntax rules.

I'm not impressed by the careless tossing around of the word "easily" in this thread. It's quite ridiculous that you're claiming errors can be easily left unhandled while referring to what, a single unfortunate pattern of code that will only realistically happen due to copy-pasting and gets you code that looks obviously wrong? Sigh.

Okay let's dissect that.

"Easily" doesn't mean "it happens all the time" in this context (e.g. PHP, at least in the olden days).

"Easily" here means that WHEN it happens, it is not usually obvious. That is my experience as a daily go user. It's not the result of copy-pasting, it's just the result of editing code. Real-life code is not a beautiful succession of `op1, op2, op3...`. You have conditions in between, you have for loops that you don't want to exit in some cases (but aggregate errors), you have times where handling an error means not returning it but doing something else, you have retries...

I don't use rust at work, but enough in hobby/OSS work to say that when an error is not handled, it sticks out much more. To get back on topic of succinctness: you can obviously swallow errors in rust, but then you need to be juggling error vars, so this immediately catches the eye. In go, you are juggling error vars all the time, so you need to sift through the whole thing every goddamn time.

Re: Thoughts on Go vs. Rust vs. Zig

#435

Post by discreteevent » Fri, Dec 05, 2025, 10:25 AM UTC

xpe wrote: post #245

vegabook wrote: post #80

The last paragraph captures the essence that all the PL theory arguments do not. "Zig has a fun, subversive feel to it". It gives you a better tool than C to apply your amazing human skills, freely, whereas both Rust and Go are fundamentally sceptical about you.

Self-aware people are mindful about what "future them" might do in various scenarios, and they plan ahead to tamp down their worse tendencies. I don't keep a raspberry cheesecake in my fridge, even though that would maximize a certain kind of freedom (the ability to eat cheesecake whenever I want). I much prefer the freedom that comes with not being tempted, as it leads to better outcomes on things I really care abou…

I would rather live in a world where I can put a raspberry cheesecake in my fridge occasionally. Because I know how to enjoy cheesecake without having to buy it every week. Not a world where when I pick the cheesecake off the shelf in the store someone says "Raspberry cheesecake! You may be one of these people who is lacking in self awareness so let me guide you. Did you know that it might be unsafe! Are you sure it's going to lead to a better outcome?"

A programming language forces a culture on everybody in the project - it's not just a personal decision like your example.

Re: Thoughts on Go vs. Rust vs. Zig

#436

Post by ixsploit » Fri, Dec 05, 2025, 10:34 AM UTC

theshrike79 wrote: post #413

ixsploit wrote: post #409

Earlier quoted context omitted.

Is there a good resource on how to get better at python prototyping? The typing system makes it somewhat slow for me and I am faster prototyping in Go then in Python, despite that I am writing more Python code. And yes I use type annotations everywhere, ideally even using pydantic. I tend to use it a lot for data analytics and exploration but I do this now in nushell which holds up very well for this kind of tasks.

Just do it I guess? :D When I'm receiving some random JSON from an API, it's so much easier to drop into a Python REPL and just wander around the structure and figure out what's where. I don't need to have a defined struct with annotations for the data to parse it like in Go. In the first phase I don't bother with any linters or type annotations, I just need the skeleton of something that works end to end. A proof of…

Thank you, but the JSON API stuff is exactly what i am using nushell for at the moment. Makes it trivial to navigate large datasets.

For me it's pretty hard to work without type annotations, it just slows me down.

Don't get me wrong, I really like python for what it is, I simply missing out on the fast prototype stuff that everyone else is capable of.

Re: Thoughts on Go vs. Rust vs. Zig

#437

Post by thrwyexecbrain » Fri, Dec 05, 2025, 10:42 AM UTC

kibwen wrote: post #93

10000truths wrote: post #77

The reason I really like Zig is because there's finally a language that makes it easy to gracefully handle memory exhaustion at the application level. 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. Stack space is not treated like magic - the compiler can reason about its maximum size by exam…

> 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.

Overcommit only matters if you use the system allocator.

To me, the whole point of Zig's explicit allocator dependency injection design is to make it easy to not use the system allocator, but something more effective.

For example imagine a web server where each request handler gets 1MB, and all allocations a request handler does are just simple "bump allocations" in that 1MB space.

This design has multiple benefits: - Allocations don't have to synchronize with the global allocator. - Avoids heap fragmentation. - No need to deallocate anything, we can just reuse that space for the next request. - No need to care about ownership -- every object created in the request handler lives only until the handler returns. - Makes it easy to define an upper bound on memory use and very easy to detect and return an error when it is reached.

In a system like this, you will definitely see allocations fail.

And if overcommit bothers someone, they can allocate all the space they need at startup and call mlock() on it to keep it in memory.

Re: Thoughts on Go vs. Rust vs. Zig

#438

Post by zozbot234 » Fri, Dec 05, 2025, 10:58 AM UTC

thrwyexecbrain wrote: post #437

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.

Overcommit only matters if you use the system allocator. To me, the whole point of Zig's explicit allocator dependency injection design is to make it easy to not use the system allocator, but something more effective. For example imagine a web server where each request handler gets 1MB, and all allocations a request handler does are just simple "bump allocations" in that 1MB space. This design has multiple benefits:…

The Rust folks are also working on having local allocators/arenas in the language, or perhaps a generalization of them known as "Storages" that might also interact in non-trivial ways with other work-in-progress features such as safe transmute or placement "new". The whole design space is somewhat in flux, that's why it's not part of stable Rust yet.

Re: Thoughts on Go vs. Rust vs. Zig

#439

Post by aw1621107 » Fri, Dec 05, 2025, 11:01 AM UTC

disappoint wrote: post #375

stouset wrote: post #332

Earlier quoted context omitted.

Is three random people saying unsafe Rust is hard supposed to make us forget about C’s legendary problems with UB, nil pointers, memory management bugs, and staggering number of CVEs? You have zero sense of perspective. Even if we accept the premise that unsafe Rust is harder than C (which frankly is ludicrous on the face of it) we’re talking about a tiny fraction of the overall code of Rust programs in the wild. You…

[flagged]

> Shold one compare Rust with C or Rust with C++?

Well, you're the one asking for a comparison with C, and this subthread is generally comparing against C, so you tell us.

> Modern C++ provides a lot of features that makes this topic easier, also when programs scale up in size, similar to Rust. Yet without requirements like no universal aliasing. And that despite all the issues of C++.

Well yes, the latter is the tradeoff for the former. Nothing surprising there.

Unfortunately even modern C++ doesn't have good solutions for the hardest problems Rust tackles (yet?), but some improvement is certainly more welcome than no improvement.

> Which is wrong

Is it? Would you be able to show evidence to prove such a claim?

Re: Thoughts on Go vs. Rust vs. Zig

#440

Post by scotty79 » Fri, Dec 05, 2025, 11:01 AM UTC

I've been using Zig for few days. And my gotchas so far:

- Can't `for (-1..1) {`. Must use `while` instead.

- if you allocated something inside of a block and you want it to keep existing outside of a block `defer` won't help you to deallocate it. I didn't find a way to defer something till the end of the function.

- adding variable containing -1 to usize variable is cumbersome. You are better of running everything with isize and converting to usize as last operation wherever you need it.

- language evolved a bunch and LLMs are of very little help.