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

31–40 of 599 posts

Re: Thoughts on Go vs. Rust vs. Zig

#31

Post by ekropotin »

ojosilva wrote: post #15

Fine, but there's a noticeable asymmetry in how the three languages get treated. Go gets dinged for hiding memory details from you. Rust gets dinged for making mutable globals hard and for conceptual density (with a maximally intimidating Pin quote to drive it home). But when Zig has the equivalent warts they're reframed as virtues or glossed over. Mutable globals are easy in Zig (presented as freedom, not as "you ca…

I pretty new to Rust and I’m wondering why global mutables are hard?

At first glance you can just use static variable of a type supporting interior mutability - RefCell, Mutex, etc…

Re: Thoughts on Go vs. Rust vs. Zig

#32

Post by iterance »

throwaway894345 wrote: post #18
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.

I cautiously agree, with the caveat that while I thought I would really like Rust's error handling, it has been painful in practice. I'm sure I'm holding it wrong, but so far I have tried: * thiserror: I spend ridiculous and unpredictable amounts of time debugging macro expansions * manually implementing `Error`, `From`, etc traits: I spend ridiculous though predictable amounts of time implementing traits (maybe LLMs…

I will at least remark that adding a new error to an enum is not a breaking change if they are marked #[non_exhaustive]. The compiler then guarantees that all match statements on the enum contain a generic case.

However, I wouldn't recommend it. Breakage over errors is not necessarily a bad thing. If you need to change the API for your errors, and downstreams are required to have generic cases, they will be forced to silently accept new error types without at least checking what those new error types are for. This is disadvantageous in a number of significant cases.

Re: Thoughts on Go vs. Rust vs. Zig

#33

Post by written-beyond »

throwaway894345 wrote: post #18
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.

I cautiously agree, with the caveat that while I thought I would really like Rust's error handling, it has been painful in practice. I'm sure I'm holding it wrong, but so far I have tried: * thiserror: I spend ridiculous and unpredictable amounts of time debugging macro expansions * manually implementing `Error`, `From`, etc traits: I spend ridiculous though predictable amounts of time implementing traits (maybe LLMs…

You have to chill with rust. Just anyhow macro wrap your errors and just log them out. If you have a specific use case that relies on using that specific error just use that at the parent stack.

Re: Thoughts on Go vs. Rust vs. Zig

#34

Post by Yoric »

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…

I'm re-discovering OCaml these days after an OCaml burnout quite a few years ago, courtesy of my then employer, so I'm afraid I can't answer these questions reliably :/

So far, I like what I've seen.

Re: Thoughts on Go vs. Rust vs. Zig

#35

Post by Aperocky »

Anecdotally, as a result of the traits that made it hard to learn for humans, Rust is actually a great language for LLM.

Out of all languages I do development in the past few months: Go, Rust, Python, Typescript; Rust is the one that LLM has the least churn/problems in terms of producing correct and functional code given a problem of similar complexity.

I think this outside factor will eventually win more usage for Rust.

Re: Thoughts on Go vs. Rust vs. Zig

#36

Post by written-beyond »

ekropotin wrote: post #31
ojosilva wrote: post #15

Fine, but there's a noticeable asymmetry in how the three languages get treated. Go gets dinged for hiding memory details from you. Rust gets dinged for making mutable globals hard and for conceptual density (with a maximally intimidating Pin quote to drive it home). But when Zig has the equivalent warts they're reframed as virtues or glossed over. Mutable globals are easy in Zig (presented as freedom, not as "you ca…

I pretty new to Rust and I’m wondering why global mutables are hard? At first glance you can just use static variable of a type supporting interior mutability - RefCell, Mutex, etc…

I don't think it's specifically hard, it's more related to how it probably needed more plumbing in the language that authors thought would add to much baggage and let the community solve it. Like the whole async runtime debates

Re: Thoughts on Go vs. Rust vs. Zig

#37

Post by Quothling »

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 not hard. Rust has a standard library that looks an awful lot like Python or Ruby, with similarly named methods.

I would read this in regard to Go and not so much in regards to Zig. Go is insanely productive, and while you're not going to match something like Django in terms of delivery speed with anything in Go, you almost can... and you can do it without using a single external dependency. Go loses a little of this in the embeded space, where it's not quite as simple, but the opinonated approach is still very productive even here.

I can't think of any language where I can produce something as quickly as I can in Go with the use of nothing but the standard library. Even when you do reach for a framework like SQLC, you can run the external parts in total isolation if that's your thing.

I will say that working with the interoperability of Zig in our C for Python binaries has been very easy, which it wasn't for Rust. This doesn't mean it's actually easier for other people, but it sure was for me.

> This is one of Rust's superpowers !

In some industries it's really not.

Re: Thoughts on Go vs. Rust vs. Zig

#39

Post by zozbot234 »

Yoric wrote: post #20
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.

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.

There's also ReasonML if you want an OCaml with curly braces like C. But both are notably missing the high-performance concurrent GC that ships with Golang out of the box.

Re: Thoughts on Go vs. Rust vs. Zig

#40

Post by [deleted] »

nicoburns wrote: post #13
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.

That seems like an odd characterization of Rust. The borrow checker and all the other type safety features, as well as features like send/sync are all about not giving you rope to hang yourself with.

[deleted]
Post reply on HN