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

341–350 of 599 posts

Re: Thoughts on Go vs. Rust vs. Zig

#341

Post by Horusiath »

forrestthewoods wrote: post #306
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…

If I created a new programming language I would just outright prohibit mutable global variables. They are pure pure pure evil. I can not count how many times I have been pulled in to debug some gnarly crash and the result was, inevitably, a mutable global variable.

Welcome to Pony: https://www.ponylang.io/

Re: Thoughts on Go vs. Rust vs. Zig

#342

Post by Dylan16807 »

bluGill wrote: post #253
kibwen wrote: post #182

Earlier quoted context omitted.

> If we can produce a substantial volume of software that can cope with allocation failures then the idea of using something than overcommit as the default becomes feasible. Except this won't happen, because "cope with allocation failure" is not something that 99.9% of programs could even hope to do. Let's say that you're writing a program that allocates. You allocate, and check the result. It's a failure. What do yo…

Even when I have a cache - it is probably in a different code path / module and it would be a terrible architecture that let me access that code.

A way to access an "emergency button" function is a significantly smaller sin than arbitrary crashes.

Re: Thoughts on Go vs. Rust vs. Zig

#343

Post by Panzerschrek »

forrestthewoods wrote: post #306
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…

If I created a new programming language I would just outright prohibit mutable global variables. They are pure pure pure evil. I can not count how many times I have been pulled in to debug some gnarly crash and the result was, inevitably, a mutable global variable.

In my programming language (see my latest submission) I wanted to do so. But then I realized, that in rare cases global mutable variables (including thread-local ones) are necessary. So, I added them, but their usage requires using an unsafe block.

Re: Thoughts on Go vs. Rust vs. Zig

#344

Post by gpm »

Zambyte wrote: post #305
kibwen wrote: post #222

Earlier quoted context omitted.

> languages where "trivial" things "just require" rapidly become "not so trivial" in the aggregate Sure. And in C and Zig, it's "trivial" to make a global mutable variable, it "just requires" you to flawlessly uphold memory access invariants manually across all possible concurrent states of your program. Stop beating around the bush. Rust is just easier than nearly any other language for writing concurrent programs,…

> it "just requires" you to flawlessly uphold memory access invariants manually across all possible concurrent states of your program. No it doesn't. Zig doesn't require you to think about concurrency at all. You can just not do concurrency. > Stop beating around the bush. Rust is just easier than nearly any other language for writing concurrent programs This is entirely unrelated to the problem of defining shared gl…

> Rust (and you) makes an assertion that all code should be able to run in a concurrent context.

It really doesn't. Rust's standard library does to an extent, because rust's standard library gives you ways to run code in concurrent contexts. Even then it supports non-concurrent primitives like thread locals and state that can't be transferred or shared between threads and takes advantage of that fact. Rust the language would be perfectly happy for you to define a standard library that just only supports the single threaded primitives.

You know what's not (generally) safe in a single threaded context? Mutable global variables. I mean it's fine for an int so long as you don't have safe ways to get pointer types to it that guarantee unique access (oops, rust does. And it's really nice for local reasoning about code even in single threaded contexts - I wouldn't want to give them up). But as soon as you have anything interesting, like a vector, you get invalidation issues where you can get references to memory it points to that you can then free while you're still holding the reference and now you've got a use after free and are corrupting random memory.

Rust has a bunch of abstractions around the safe patterns though. Like you can have a `Cell` instead of a `u64` and stick that in a thread local and access it basically like a u64 (both reading and writing), except you can't get those pointers that guarantee nothing is aliasing them to it. And a `Cell>` won't let you get references to the elements of the vector inside of it at all. Or a `RefCell` which is like a RwLock except it can't be shared between threads, is faster, and just crashes instead of blocking because blocking would always result in a deadlock.

Re: Thoughts on Go vs. Rust vs. Zig

#345

Post by forrestthewoods »

smallstepforman wrote: post #326
forrestthewoods wrote: post #306

Earlier quoted context omitted.

If I created a new programming language I would just outright prohibit mutable global variables. They are pure pure pure evil. I can not count how many times I have been pulled in to debug some gnarly crash and the result was, inevitably, a mutable global variable.

You need to be pragmatic and practical. Extra large codebases have controllers/managers that must be accessible by many modules. A single global vs dozens of local references to said “global” makes code less practical.

One of my favorite talks of all-time is the GDC talk on Overwatch's killcam system. This is the thing that when you die in a multiplayer shooter you get to see the last ~4 seconds of gameplay from the perspective of your killer. https://www.youtube.com/watch?v=A5KW5d15J7I

The way Blizzard implemented this is super super clever. They created an entirely duplicate "replay world". When you die the server very quickly "backfills" data in the "replay world". (Server doesn't send all data initially to help prevent cheating). The camera then flips to render the "replay world" while the "gameplay world" continues to receives updates. After a few seconds the camera flips back to the "gameplay world" which is still up-to-date and ready to rock.

Implementing this feature required getting rid of all their evil dirty global variables. Because pretty much every time someone asserted "oh we'll only ever have one of these!" that turned out to be wrong. This is a big part of the talk. Mutables globals are bad!

> Extra large codebases have controllers/managers that must be accessible by many modules.

I would say in almost every single case the code is better and cleaner to not use mutable globals. I might make a begrudging exception for logging. But very begrudgingly. Go/Zig/Rust/C/C++ don't have a good logging solution. Jai has an implict context pointer which is clever and interesting.

Rust uses the unsafe keyword as an "escape hatch". If I wrote a programming language I probably would, begrudgingly, allow mutable globals. But I would hide their declaration and usage behind the keyworld `unsafe_and_evil`. Such that every single time a programmer either declared or accessed a mutable global they would have to type out `unsafe_and_evil` and acknowledge their misdeeds.

Re: Thoughts on Go vs. Rust vs. Zig

#346

Post by aw1621107 »

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…

I don't think you're actually disagreeing with the person you're responding to here. Even if you take your grouping as factual, there's nothing that limits said grouping to Rust programmers. Or in other words:

> This could happen in every language ever made. It has nothing to do with rust.

Re: Thoughts on Go vs. Rust vs. Zig

#347

Post by notnullorvoid »

frobisher wrote: post #303
gt0 wrote: post #299

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.

Although I find my brainspace being dedicated to thinking about memory, rather than the problem at hand. Which can be a worthwhile cost if the benefits of speed and security are needed. But I think it's certainly a cognitive cost.

You can use RC liberally to avoid thinking about memory though. The only memory problem to think about then is circular refs, which GC languages also don't fully avoid.

Re: Thoughts on Go vs. Rust vs. Zig

#349

Post by rrgok »

apitman wrote: post #302
ajross wrote: post #214

Earlier quoted context omitted.

> [...] is trivial in Rust [...] it just requires [...] This is a tombstone-quality statement. It's the same framing people tossed around about C++ and Perl and Haskell (also Prolog back in the day). And it's true, insofar as it goes. But languages where "trivial" things "just require" rapidly become "not so trivial" in the aggregate. And Rust has jumped that particular shark. It will never be trivial, period.

Nah, learning Rust is trivial. I've done it 3 or 4 times now.

In how many lifetimes?

Re: Thoughts on Go vs. Rust vs. Zig

#350

Post by scuff3d »

attractivechaos wrote: post #329
deathanatos wrote: post #162

> I’m not the first person to pick on this particular Github comment, but it perfectly illustrates the conceptual density of Rust: But you only need about 5% of the concepts in that comment to be productive in Rust. I don't think I've ever needed to know about #[fundamental] in about 12 years or so of Rust… > In both Go and Rust, allocating an object on the heap is as easy as returning a pointer to a struct from a fu…

> But you only need about 5% of the concepts in that comment to be productive in Rust. The similar argument against C++ is applicable here: another programmer may be using 10% (or a different 5%) of the concepts. You will have to learn that fraction when working with him/her. This may also happen when you read the source code of some random projects. C programmers seldom have this problem. Complexity matters.

There's also the problem of the people who are either too clever for their own good, or not nearly as clever as they think they are. Either group can produce horribly convoluted code to perform relatively simple tasks, and it's irritating as hell everytime I run into it. That's not unique to Rust of course, but the more tools you give to them the bigger mess they make.
Post reply on HN