Live data from Hacker News

Thoughts on Go vs. Rust vs. Zig

sinclairtarget.com

371–380 of 599 posts

Re: Thoughts on Go vs. Rust vs. Zig

#372
post #120

Earlier quoted context omitted.

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#?

Also Haskell, Java, Kotlin, Scala, OCaml, D, and the list goes on.

Re: Thoughts on Go vs. Rust vs. Zig

#373
post #222
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.

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

I find Elixir and Erlang easier, but I'm still a neophyte with Rust, so I may feel differently in a year.

Re: Thoughts on Go vs. Rust vs. Zig

#374
post #296
post #4

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

I think generics ruined the language. Zig doesn’t have them

But it has something for it (compile time evaluation of functions).

Re: Thoughts on Go vs. Rust vs. Zig

#375

Earlier quoted context omitted.

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/

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]

Re: Thoughts on Go vs. Rust vs. Zig

#376
post #205
post #4

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

Are you familiar with Zig's error handling? It's arguably more Go-like than the Rust approach.

No, Zig's error handling is decent - you either return an error or a value and you have some syntactic sugar to handle it. It's pretty cool, especially given the language's low-level domain.

Meanwhile Go's is just multiple value-returns with no checks whatsoever and you can return both a valid value and an error.

Re: Thoughts on Go vs. Rust vs. Zig

#377
Reading about the the complexity of Rust makes me appreciate more OCaml. OCaml also has a Hindley Milner type system and provides similar runtime guarantees, but it is simpler to write and it has a very, very fast compiler. Also, the generated code is reasonably fast.

Re: Thoughts on Go vs. Rust vs. Zig

#378

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…

> Even if we accept the premise that unsafe Rust is harder than C (which frankly is ludicrous on the face of it) I think there's a very strong dependence on exactly what kind of unsafe code you're dealing with. On one hand, you can have relatively straightforwards stuff like get_unsafe or calling into simpler FFI functions. On the other hand, you have stuff like exposing a safe, ergonomic, and sound APIs for self-ref…

[flagged]

Re: Thoughts on Go vs. Rust vs. Zig

#379

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

> Rust can also do arena allocations, and there is an allocator concept in Rust, too.

Just a pure question: Is Rust allocator global? (Will all heap allocations use the same allocator?)

Re: Thoughts on Go vs. Rust vs. Zig

#380

Earlier quoted context omitted.

SAFETY comments do not magically make unsafe Rust correct nor safe. And Miri cannot catch everything, and is magnitudes slower than regular program running. https://github.com/rust-lang/rust/commit/71f5cfb21f3fd2f1740... https://materialize.com/blog/rust-concurrency-bug-unbounded-...

I think you might be misreading GP's comment. They are not claiming that SAFETY comments and MIRI guarantee correctness/safety; those are just being used as examples of the extra effort that can be and are expended on the relatively few unsafe blocks in your codebase, resulting in "your probability of success [being] vastly higher" compared to "might as well have used C".

[flagged]
Post reply on HN