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

391–400 of 599 posts

Re: Thoughts on Go vs. Rust vs. Zig

#391

Post by Yoric »

zozbot234 wrote: post #39
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.

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.

As far as I understand, OCaml's recent multicore GC is pretty good.

I haven't looked at benchmarks, though, so take this with a pinch of salt.

Re: Thoughts on Go vs. Rust vs. Zig

#392

Post by theshrike79 »

auxiliarymoose wrote: post #132
Rikudou wrote: post #76

I think the Go part is missing a pretty important thing: the easiest concurrency model there is. Goroutines are one of the biggest reasons I even started with Go.

Agreed. Rob Pike presented a good talk "Concurrency is not Parallelism" which explains the motivations behind Go's concurrency model: https://youtu.be/oV9rvDllKEg Between the lack of "colored functions" and the simplicity of communicating with channels, I keep surprising myself with how (relatively) quick and easy it is to develop concurrent systems with correct behavior in Go.

Just the fact that you can prototype with a direct solution and then just pretty much slap on concurrency by wrapping it in "go" and adding channels is amazing.

Re: Thoughts on Go vs. Rust vs. Zig

#393

Post by librasteve »

librasteve wrote: post #44
librasteve wrote: post #19

I love this take - partly because I agree with it - but mostly because I think that this is the right way to compare PLs (and to present the results). It is honest in the way it ascribes strengths and weaknesses, helping to guide, refine, justify the choice of language outside of job pressures. I am sad that it does not mention Raku ( https://raku.org ) ... because in my mind there is a kind of continuum: C - Zig - C…

I tried to get an LLM to write a Raku chapter in the same vein - naah. Had to write it myself: Raku Raku stands out as a fast way to working code, with a permissive compiler that allows wide expression. Its an expressive, general-purpose language with a wide set of built-in tools. Features like multi-dispatch, roles, gradual typing, lazy evaluation, and a strong regex and grammar system are part of its core design. T…

I see that my Raku chapter was downvoted a couple of times. Well OK, I am an unashamed shill for such a fantastic and yet despised language. Don’t knock til you try it.

Some comments below on “I want a Go, but with more powerful OO” - well Raku adheres to the Smalltalk philosophy… everything is an object, and it has all the OO richness (rope) of C++ with multiple inheritance, role composition, parametric roles, MOP, mixins… all within an easy to use, easy to read style.

  my $forty-two = 42 but 'forty two';
Look away now if you hate sigils.

Re: Thoughts on Go vs. Rust vs. Zig

#394

Post by veltas »

smallstepforman wrote: post #330
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…

Linux has overcommit so failing malloc hasnt been a thing for over a decade. Zig is late to the party since it strong arms devs to cater to a scenerio which no longer exists.

On Linux you can turn this off. On some OS's it's off by default. Especially in embedded which is a major area of native coding. If you don't want to handle allocation failures in your app you can abort.

Also malloc can fail even with overcommit, if you accidentally enter an obviously incorrect size like -1.

Re: Thoughts on Go vs. Rust vs. Zig

#395

Post by forgotpwd16 »

dismalaf wrote: post #137

One of these is not like the others... Odin vs Rust vs Zig would be more apt, or Go vs Java vs OCaml or something...

Have noticed Go/Rust/Zig are quite popular for self-contained natively-compiled network-oriented/system apps/utilities/services, and they're similar in their integrated compiler/package-management tooling. So for this use case that trio worths comparing.

Re: Thoughts on Go vs. Rust vs. Zig

#396

Post by dmoy »

Yoric wrote: post #28
throwaway894345 wrote: post #18

Earlier quoted context omitted.

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…

FWIW `fmt.Errorf("opening file %s: %w", filePath, err)` is pretty much equivalent to calling `err.with_context(|| format!("opening file {}", path))?` with anyhow. What `thiserror` or manually implementing `Error` buys you is the ability to actually do something about higher-level errors. In Rust design, not doing so in a public facing API is indeed considered bad practice. In Go, nobody seems to care about that, whic…

> In Rust design, not doing so in a public facing API is indeed considered bad practice. In Go, nobody seems to care about that, which of course makes code easier to write, but catching errors quickly becomes stringly typed. Yes, it's possible to do it correctly in Go, but it's ridiculously complicated, and I don't think I've ever seen any third-party library do it correctly.

Yea this is exactly what I'm talking about. It's doable in golang, but it's a little bit of an obfuscated pain, few people do it, and it's easy to mess up.

And yes on the flip side it's annoying to exhaustively check all types of errors, but a lot of the times that matters. Or at least you need an explicit categorization that translates errors from some dep into retryable vs not, SLO burning vs not, surfaced to the user vs not, etc. In golang the tendency is to just slap a "if err != nil { return nil, fmt.Errorf" forward in there. Maybe someone thinks to check for certain cases of upstream error, but it's reaaaallly easy to forget one or two.

Re: Thoughts on Go vs. Rust vs. Zig

#398

Post by rascul »

forrestthewoods wrote: post #345
smallstepforman wrote: post #326

Earlier quoted context omitted.

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

Could you describe what you would consider a good logging solution?

Re: Thoughts on Go vs. Rust vs. Zig

#399

Post by dwb »

kachapopopow wrote: post #180
int_19h wrote: post #163

Earlier quoted context omitted.

What is "generally accepted" though? If you mean C-style declarations, the fact that tools such as https://linux.die.net/man/1/cdecl even exist to begin with shows what's wrong with it.

(array?) (:)= (value) ( [:] [(->/:) type] [import/use/using] ( [/|:|::|.] | "file") (ok header files are a relic of the past I have to admit that) I tried writing zig and as someone who has pretty much written in every commonly used language it just felt different enough where I kept having to look up the syntax.

There’s almost countless languages that don’t do anything like this, whereas Zig is very similar. It’s fine to prefer this syntax or that, but Zig is pretty ordinary, as languages go. So yes, the differences are trivial enough that it’s a bit much to complain about. You can’t have spent much time with Zig or you’d have learned the syntax easily.

Re: Thoughts on Go vs. Rust vs. Zig

#400

Post by dmoy »

Yoric wrote: post #390
dmoy wrote: post #277

Earlier quoted context omitted.

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 :)

Fair lol

Though as a side note I see no open gitlab positions mentioning ocaml. Lot of golang and ruby. Whereas jane street kinda always has open ocaml positions advertised. They even hire PL people for ocaml

Post reply on HN