Live data from Hacker News

Thoughts on Go vs. Rust vs. Zig

sinclairtarget.com

381–390 of 599 posts

Re: Thoughts on Go vs. Rust vs. Zig

#381

Earlier quoted context omitted.

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

[flagged]

Re: Thoughts on Go vs. Rust vs. Zig

#382
post #43

Earlier quoted context omitted.

These are extremely trivial, to the point that I don’t really know what you’re complaining about. What would expect or prefer?

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

The same goes for go, though. And out of the two, I find Zig is still closer to any sane existing language schema. While go is like, let's write C-style types, but reverse the order, even though there is a widely accepted type notation that already reverses it with a :, that even let's you infer types in a sane way.

Re: Thoughts on Go vs. Rust vs. Zig

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

I am glad that there is such comment among countless that try their best to convince that Rust way is just the best way to do stuff, whatever the context.

But no, clearly there is no cult build around Rust, and everyone that suggest otherwise is dishonest.

Re: Thoughts on Go vs. Rust vs. Zig

#384

I'd rather read 3 lines of clear code than one line of esoteric syntactic sugar. I think regardless of what blogs say, Go's adoption compared to that of Rust or Zig speaks for itself

By that metric we should all use Javascript

Well, if Go is somehow part of this set than JS might as well be. Go is closer to JS than to Rust or Zig, this triumvirate makes zero sense.

Re: Thoughts on Go vs. Rust vs. Zig

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

> They are pure pure pure evil.

They are to be used with caution. If your execution environment is simple enough they can be quite useful and effective. Engineering shouldn't be a religion.

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

I've never once had that happen. What types of code are you working on that this occurs so frequently?

Re: Thoughts on Go vs. Rust vs. Zig

#386

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

Complexity has to live somewhere. If it's not in the language, it's either in the runtime and/or your code and/or your code's undocumented behavior.

Re: Thoughts on Go vs. Rust vs. Zig

#388
post #301

Rust Alternatives https://blog.fox21.at/2025/03/09/rust-alternatives.html

for author's specific criteria

Thus not a general article. For some criteria Python will be a good Rust alternative.

>Can I have a #programming language/compiler similar to #Rust, but with less syntactic complexity?

That's a good question. But considering Zig is manually memory managed and Crystal/Go are garbage collected, you sidestep Rust's strongest selling point.

Re: Thoughts on Go vs. Rust vs. Zig

#389

> [Go] is like C in that you can fit the whole language in your head. Go isn't like C in that you can actually fit the entire language in your head. Most of us who think we have fit C in our head will still stumble on endless cases where we didn't realize X was actually UB or whatever. I wonder how much C's reputation for simplicity is an artifact of its long proximity to C++?

30 years in C/C++ here. Give an example of UB code that you have committed in real life, not from blogs. I am genuinely curious.

All the memory safety vulnerabilities, which are the majority of bugs in most C/C++ projects?

Re: Thoughts on Go vs. Rust vs. Zig

#390
post #277
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.

Yea, there's not much for large scale production ocaml though, do it would be a tough sell at my work. It's one of those things where like.... if I got an offer to work at jane street I might take it solely for the purpose of ocaml lol.

There's also OCaml at GitLab and Semgrep, if you're on the market :)
Post reply on HN