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

441–450 of 599 posts

Re: Thoughts on Go vs. Rust vs. Zig

#441

Post by ivanyu »

pansa2 wrote: post #126
verdverm wrote: post #117

Earlier quoted context omitted.

We were taught not to use exceptions for control flow, and reading a file which does not exist is a pretty normal thing to handle in code flow, rather than exceptions. That simple example in Python is missing all the other stuff you have to put around it. Go would have another error check, but I get to decide, at that point in the execution, how I want to handle it in this context

In Python, it’s common to use exceptions for control flow. Even exiting a loop is done via an exception: `StopIteration`.

It's not "common". You have to deal with StopIteration only when you write an iterator with the low-level API, which is maybe once in the career time for most of developers.

Re: Thoughts on Go vs. Rust vs. Zig

#442

Post by SkiFire13 »

irishcoffee wrote: post #146
stouset wrote: post #131

Earlier quoted context omitted.

Are you with a straight face saying that occasionally having a safety bug in limited unsafe areas of Rust is functionally the same as having written the entire program in an unsafe language like C? One, the dollar cost is not the same. The baseline floor of quality will be higher for a Rust program vs. a C program given equal development effort. Second, the total possible footprint of entire classes of bugs is zero t…

> The baseline floor of quality will be higher for a Rust program vs. a C program given equal development effort. Hmm, according to whom, exactly? > Second, the total possible footprint of entire classes of bugs is zero thanks to design features of Rust (the borrowck, sum types, data race prevention), except in a specifically delineated areas which often total zero in the vast majority of Rust programs. And yet someh…

> And yet somehow the internet went down because of a program written in rust that didn’t validate input.

No, it _did validate_ the input, and since that was invalid it resulted in an error.

People can yap about that unwrap all they want, but if the code just returned an error to the caller with `?` it would have resulted in a HTTP 500 error anyway.

Re: Thoughts on Go vs. Rust vs. Zig

#443

Post by zozbot234 »

raggi wrote: post #215
zozbot234 wrote: post #141

Earlier quoted context omitted.

> Every adherent of managed memory languages should take it as a personal insult that people are choosing to write modern terminal emulators in Rust and Zig. How so? Garbage collection has inherent performance overhead wrt. manual memory management, and Rust now addresses this by providing the desired guarantees of managed memory without the overhead of GC. A modern terminal emulator is not going to involve complex r…

> How so? Garbage collection has inherent performance overhead wrt. manual memory management, and Rust now addresses this by providing the desired guarantees of managed memory without the overhead of GC. I somewhat disagree, specifically on the implicit claim that all GC has overhead and alternatives do not. Rust does a decent job of giving you some ergonomics to get started, but it is still quite unergonomic to fix…

> I somewhat disagree, specifically on the implicit claim that all GC has overhead and alternatives do not.

Not a claim I made. Obviously there are memory management styles (such as stack allocation, pure static memory or pluggable "arenas"/local allocators) that are even lower overhead than a generic heap allocator, and the Rust project does its best to try and support these styles wherever they might be relevant, especially in deep embedded code.

In principle it ought to be also possible to make GC's themselves a "pluggable" feature (the design space is so huge and complex that picking a one-size-fits-all implementation and making it part of the language itself is just not very sensible) to be used only when absolutely required - a bit like allocators in Zig - but this does require some careful design work because the complete systems-level interface to a full tracing GC (including requirements wrt. any invariants that might be involved in correct tracing, read-write barriers, pauses, concurrency etc. etc.) is vastly more complex than one to a simple allocator.

Re: Thoughts on Go vs. Rust vs. Zig

#444

Post by aw1621107 »

ErroneousBosh wrote: post #432
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.

What do people generally write in Rust? I've tried it a couple of times but I keep running up against the "immutable variable" problem, and I don't really understand why they're a thing.

> but I keep running up against the "immutable variable" problem

...Is that not what mut is for? I'm a bit confused what you're talking about here.

Re: Thoughts on Go vs. Rust vs. Zig

#445

Post by michaelscott »

kibwen wrote: 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…

After using Rust for many years now, I feel that a mutable global variable is the perfect example of a "you were so busy figuring out whether you could, you never stopped to consider whether you should".

Moving back to a language that does this kind of thing all the time now, it seems like insanity to me wrt safety in execution

Re: Thoughts on Go vs. Rust vs. Zig

#446

Post by aw1621107 »

disappoint wrote: post #370
Dylan16807 wrote: post #335

Earlier quoted context omitted.

You phrase that as if 0-5% of a program being harder to write disqualifies all the benefits of isolating memory safety bugs to that 0-5%. It doesn't.

And it can easily be more than 5%, since some projects both have lots of large unsafe blocks, and also the presence of an unsafe block can require validation of much more than the block itself. It is terrible of you and overall if my understanding is far better than yours. And even your argument taken at face value is poor, since if it is much harder, and it is some of the most critical code and already-hard code, li…

> since if it is much harder, and it is some of the most critical code and already-hard code, like some complex algorithm, it could by itself be worse overall.

(Emphasis added)

But is it worse overall?

It's easy to speculate that some hypothetical scenario could be true. Of course, such speculation on its own provides no reason for anyone to believe it is true. Are you able to provide evidence to back up your speculation?

Re: Thoughts on Go vs. Rust vs. Zig

#447

Post by weavie »

codys wrote: post #365
dnautics wrote: post #247

Earlier quoted context omitted.

> there is an allocator concept in Rust, too. aren't allocators types in rust? suppose you had an m:n system (like say an evented http request server split over several threads so that a thread might handle several inbound requests), would you be able to give each request its own arena?

Allocators in rust are objects that implement the allocator trait. One (generally) passes the allocator object to functions that use the allocator. For example, `Vec` has `Vec::new_in(alloc: A) where A: Allocator`. And so if in your example every request can have the same Allocator type, and then have distinct instances of that type . For example, you could say "I want an Arena" and pick the Arena type that impls All…

To be clear though, the allocator API is still experimental and from what I remember has been for quite a while now..

Re: Thoughts on Go vs. Rust vs. Zig

#448

Post by Orygin »

gf000 wrote: post #423
beautron wrote: post #404

Earlier quoted context omitted.

But sometimes it is useful to return both a value and a non-nil error. There might be partial results that you can still do things with despite hitting an error. Or the result value might be information that is useful with or without an error (like how Go's ubiquitous io.Writer interface returns the number of bytes written along with any error encountered). I appreciate that Go tends to avoid making limiting assumpti…

Then just return a value representing what you want, instead of breaking a convention and hacking something and hoping that at use site someone else has read the comment. Also, just let the use site pass in (out variable, pointer, mutable object, whatever your language has) something to store partial results.

> instead of breaking a convention and hacking something and hoping

It's not a convention in Go, so it's not breaking any expectations

Re: Thoughts on Go vs. Rust vs. Zig

#449

Post by yccs27 »

tapirl wrote: post #379
deathanatos wrote: post #162

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

No. There is a global allocator which is used by default, but all the stdlib functions that allocate memory have a version which allows you to pass in a custom allocator. These functions are still "unstable" though, so they can currently only be used with development builds of the compiler.

Re: Thoughts on Go vs. Rust vs. Zig

#450

Post by ErroneousBosh »

aw1621107 wrote: post #444
ErroneousBosh wrote: post #432

Earlier quoted context omitted.

What do people generally write in Rust? I've tried it a couple of times but I keep running up against the "immutable variable" problem, and I don't really understand why they're a thing.

> but I keep running up against the "immutable variable" problem ...Is that not what mut is for? I'm a bit confused what you're talking about here.

I don't really get immutable variables, or why you'd want to make copies of things so now you've got an updated variable and an out-of-date variable. Isn't that just asking for bugs?
Post reply on HN