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

151–160 of 599 posts

Re: Thoughts on Go vs. Rust vs. Zig

#151

Post by frizlab »

oncallthrow wrote: post #46

> Other features common in modern languages, like tagged unions or syntactic sugar for error-handling, have not been added to Go. > It seems the Go development team has a high bar for adding features to the language. The end result is a language that forces you to write a lot of boilerplate code to implement logic that could be more succinctly expressed in another language. Being able to implement logic more succinct…

Swift is great for that:

    do {
       let file = try FileManager.create(…)
    } catch {
       logger.error("Failed creating file", metadata: ["error": "\(error)"])
    }
Note the try is not actual CPU exceptions, but mostly syntax sugar.

You can opt-out of the error handling, but it’s frowned upon, and explicit:

    let file = try? FileManager.create(…)
or

    let file = try! FileManager.create(…)
The former returning an optional file if there is an error, and the latter crashing in case of an error.

Re: Thoughts on Go vs. Rust vs. Zig

#152

Post by incompatible »

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…

I don't know Zig. The article says "Many people seem confused about why Zig should exist if Rust does already." But I'd ask instead why does Zig exist when C does already? It's just a "better" C? But has the drawback that makes C problematic for development, manual memory management? I think you are better off using a language with a garbage collector, unless your usage really needs manual management, and then you can pick between C, Rust, and Zig (and C++ and a few hundred others, probably.)

Re: Thoughts on Go vs. Rust vs. Zig

#153

Post by 9rx »

edflsafoiewq wrote: post #61
oncallthrow wrote: post #46

> Other features common in modern languages, like tagged unions or syntactic sugar for error-handling, have not been added to Go. > It seems the Go development team has a high bar for adding features to the language. The end result is a language that forces you to write a lot of boilerplate code to implement logic that could be more succinctly expressed in another language. Being able to implement logic more succinct…

Python's f = open('foo.txt', 'w') is even more succinct, and the exception thrown on failure will not only contain the reason, but the filename and the whole backtrace to the line where the error occurred.

But no context, so in the real world you need to write:

    try:
        f = open('foo.txt', 'w')
    except Exception as e:
        raise NecessaryContext("important information") from e
Else your callers are in for a nightmare of a time trying to figure out why an exception was thrown and what to do with it. Worse, you risk leaking implementation details that the caller comes to depend on which will also make your own life miserable in the future.

Re: Thoughts on Go vs. Rust vs. Zig

#154

Post by frizlab »

iainmerrick wrote: post #108
raggi wrote: post #11

I really hate the anti-RAII sentiments and arguments. I remember the Zig community lead going off about RAII before and making claims like "linux would never do this" ( https://github.com/torvalds/linux/blob/master/include/linux/... ). There are bad cases of RAII APIs for sure, but it's not all bad. Andrew posted himself a while back about feeling bad for go devs who never get to debug by seeing 0xaa memory segments,…

Have you tried Swift? It has the sort of pragmatic-but-safe-by-default approach you’re talking about.

And it is a joy to use, truly.

Re: Thoughts on Go vs. Rust vs. Zig

#155

Post by PaulKeeble »

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.

Its a bit messy to do parallelism with it but it still works and its a consistent pattern and their are libraries that add it for the processing of slices and such. It could be made easier IMO, they are trying to dissuade its use but its actually really common to want to process N things distributed across multiple CPUs nowadays.

Re: Thoughts on Go vs. Rust vs. Zig

#156

Post by kachapopopow »

dwb wrote: post #43
kachapopopow wrote: post #26

I could never get into zig purely because of the syntax and I know I am not alone, can someone explain the odd choices that were taken when creating zig? the most odd one probably being 'const expected = [_]u32{ 123, 67, 89, 99 };' and the 2nd most being the word 'try' instead of just ? the 3rd one would be the imports and `try std.fs.File.stdout().writeAll("hello world!\n");` is not really convincing either for a ba…

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?

Re: Thoughts on Go vs. Rust vs. Zig

#157

Post by nu11ptr »

irishcoffee wrote: post #122
nu11ptr wrote: post #116

Earlier quoted context omitted.

> I would assume trivial means the default approach works for most cases. Perhaps mutable global variables are not a common use case. Unsafe might make it easier, but it’s not obvious and probably undesired. I'm a Rust fan, and I would generally agree with this. It isn't difficult, but trivial isn't quite right either. And no, global vars aren't terribly common in Rust, and when used, are typically done via LazyLock…

> Even if you do, you now have an effective comment that tells you where to look if you ever get suspicious behavior. By the time suspicious behavior happens, isn’t it kind of a critical inflection point? For example, the news about react and next that came out. Once the code is deployed, re-deploying (especially with a systems language that quite possibly lives on an air-gapped system with a lot of rigor about updat…

> might as well have used C, the dollar cost is the same.

When your unsafe area is small, you put a LOT of thought/testing into those small blocks. You write SAFETY comments explaining WHY it is safe (as you start with the assumption there will be dragons there). You get lots of eyeballs on them, you use automated tools like miri to test them. So no, not even in the same stratosphere as "might as well have used C". Your probability of success vastly higher. A good Rust programmer uses unsafe judiciously, where as a C programmer barely blinks as they need ensure every single snippet of their code is safe, which in a large program, is an impossible task.

As an aside, having written a lot of C, the ecosystem and modern constructs available in Rust make writing large scale programs much easier, and that isn't even considering the memory safety aspect I discuss above.

Re: Thoughts on Go vs. Rust vs. Zig

#158

Post by kachapopopow »

usrnm wrote: post #49
kachapopopow wrote: post #26

I could never get into zig purely because of the syntax and I know I am not alone, can someone explain the odd choices that were taken when creating zig? the most odd one probably being 'const expected = [_]u32{ 123, 67, 89, 99 };' and the 2nd most being the word 'try' instead of just ? the 3rd one would be the imports and `try std.fs.File.stdout().writeAll("hello world!\n");` is not really convincing either for a ba…

I will never understand people bashing other languages for their syntax and readability and then saying that they prefer Rust. Async Rust is the ugliest and least readable language I've ever seen and I've done a lot of heavily templated C++

I don't really prefer rust, but I'd take that syntax over zig, c++ templating is just evil though. Also it's not about readability, but rather the uniqueness to it.

Re: Thoughts on Go vs. Rust vs. Zig

#159

Post by simonask »

bsder wrote: post #128
raggi wrote: post #11

I really hate the anti-RAII sentiments and arguments. I remember the Zig community lead going off about RAII before and making claims like "linux would never do this" ( https://github.com/torvalds/linux/blob/master/include/linux/... ). There are bad cases of RAII APIs for sure, but it's not all bad. Andrew posted himself a while back about feeling bad for go devs who never get to debug by seeing 0xaa memory segments,…

> So RAII isn't the big evil monster, and we need to stop talking about RAII, globals, etc, in these ways. I disagree and place RAII as the dividing line on programming language complexity and is THE "Big Evil Monster(tm)". Once your compiled language gains RAII, a cascading and interlocking set of language features now need to accrete around it to make it ... not excruciatingly painful. This practically defines the…

Go ahead, invent a GC that doesn’t require at least 2-4x the program’s working set of memory, and that doesn’t drizzle the code with little branches and memory barriers.

You will be very rich.

Re: Thoughts on Go vs. Rust vs. Zig

#160

Post by dystopiandevel »

oncallthrow wrote: post #46

> Other features common in modern languages, like tagged unions or syntactic sugar for error-handling, have not been added to Go. > It seems the Go development team has a high bar for adding features to the language. The end result is a language that forces you to write a lot of boilerplate code to implement logic that could be more succinctly expressed in another language. Being able to implement logic more succinct…

Also having explicit error handling is useful because it makes transparent the possibility of not getting the value (which is common in pure functional languages). With that said I have a Go project outside of work and it is very verbose. I decided to use it for performance as a new version of the project that mostly used bash scripts and was getting away too cryptic. The logic is easier to follow and more robust in the business domain but way more lines of code.
Post reply on HN