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

361–370 of 599 posts

Re: Thoughts on Go vs. Rust vs. Zig

#361

Post by kristianp »

yxhuvud wrote: post #359
auxiliarymoose wrote: post #300

Earlier quoted context omitted.

But how does one communicate and synchronize between tasks with structured concurrency? Consider a server handling transactional requests, which submit jobs and get results from various background workers, which broadcast change events to remote observers. This is straightforward to set up with channels in Go. But I haven't seen an example of this type of workload using structured concurrency.

The point of structured concurrency is that if you need to do that in code, then there is a need of a predefined structured way to do that. Safely, without running with scissors like how channel usage tend to be.

It would be good to see an example of what that looks like.

Re: Thoughts on Go vs. Rust vs. Zig

#362

Post by yxhuvud »

throwaway2037 wrote: post #187

> OOP has been out of favor for a while now I love these lines. Who writes this stuff? I'll tell you: The same people on HN who write "In Europe, X is true." (... when Europe is 50 countries!). > Zig is a language for data-oriented design. But not OOP, right? Or, OOP couldn't do the same thing? One thing that I have found over umpteen years of reading posts online: Americans just love superlatives. They love the gran…

It'd be very interesting to see an OO language that passes around allocators like zig does. There is definitely nothing in the concept itself that stops that.

Re: Thoughts on Go vs. Rust vs. Zig

#363

Post by throwaway2037 »

yxhuvud wrote: post #362
throwaway2037 wrote: post #187

> OOP has been out of favor for a while now I love these lines. Who writes this stuff? I'll tell you: The same people on HN who write "In Europe, X is true." (... when Europe is 50 countries!). > Zig is a language for data-oriented design. But not OOP, right? Or, OOP couldn't do the same thing? One thing that I have found over umpteen years of reading posts online: Americans just love superlatives. They love the gran…

It'd be very interesting to see an OO language that passes around allocators like zig does. There is definitely nothing in the concept itself that stops that.

What about allocators in C++ STL (Standard Template Library)? Honestly, I have been reading & writing C++ for a squillion years, and (1) I have never used an allocator myself, and (2) never seen anyone else use it. (Granted, I have not seen a huge number of enterprise C++ code bases.)

Re: Thoughts on Go vs. Rust vs. Zig

#364

Post by ii41 »

Zambyte wrote: post #305
kibwen wrote: post #222

Earlier quoted context omitted.

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

> it "just requires" you to flawlessly uphold memory access invariants manually across all possible concurrent states of your program. No it doesn't. Zig doesn't require you to think about concurrency at all. You can just not do concurrency. > Stop beating around the bush. Rust is just easier than nearly any other language for writing concurrent programs This is entirely unrelated to the problem of defining shared gl…

Rust doesn't require you to think about concurrency if you don't use it either. For global variables you just throw in a thread_local. No unsafe required.

Re: Thoughts on Go vs. Rust vs. Zig

#365

Post by codys »

dnautics wrote: post #247
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…

> 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 Allocator, and then create a new instance of Arena for each `Vec::new_in(alloc)` call.

Alternately, if you want every request to have a distinct Allocator type as well as instance, one can use `Box` as the allocators type (or use any other dispatch pattern), and provide whatever instance of the allocator is appropriate.

Re: Thoughts on Go vs. Rust vs. Zig

#366

Post by auxiliarymoose »

yxhuvud wrote: post #359
auxiliarymoose wrote: post #300

Earlier quoted context omitted.

But how does one communicate and synchronize between tasks with structured concurrency? Consider a server handling transactional requests, which submit jobs and get results from various background workers, which broadcast change events to remote observers. This is straightforward to set up with channels in Go. But I haven't seen an example of this type of workload using structured concurrency.

The point of structured concurrency is that if you need to do that in code, then there is a need of a predefined structured way to do that. Safely, without running with scissors like how channel usage tend to be.

But how does one actually do that? What does the architecture and code look like?

Re: Thoughts on Go vs. Rust vs. Zig

#368

Post by dannersy »

> This makes Rust hard, because you can’t just do the thing!

I'm a bit of a Rust fanboy because of writing so much Go and Javascript in the past. I think I just got tired of all the footguns and oddities people constantly run into but conveniently brush off as intentional by the design of the language. Even after years of writing both, I would still get snagged on Go's sharp edges. I have seen so many bugs with Go, written by seniors, because doing the thing seemed easy in code only for it to have unexpected behavior. This is where even after years of enjoying Go, I have a bit of a bone to pick with it. Go was designed to be this way (where Javascript/Typescript is attempting to make up for old mistakes). I started to think to myself: Well, maybe this shouldn't be "easy" because what I am trying to do is actually complicated behind the scenes.

I am not going to sit here and argue with people around language design or computer science. What I will say is that since I've been forced to be somewhat competent in Rust, I am a far better programmer because I have been forced to grasp concepts on a lower level than before. Some say this might not be necessary or I should have known these things before learning Rust, and I would agree, but it does change the way you write and design your programs. Rust is just as ugly and has snags that are frustrating like any other language, yes, but it was the first that forced me to really think about what it is I am trying to do when writing something that the compiler claims is a no-no. This is why I like Zig as well and the syntax alone makes me feel like there is space for both.

Re: Thoughts on Go vs. Rust vs. Zig

#369

Post by ViewTrick1002 »

afiori wrote: post #320
gjsjchd6 wrote: post #232

Earlier quoted context omitted.

Rust is a 99% solution to a 1% problem.

It they had not messed up async it would be much better

Given the constraints I still haven’t seen an asynchronous proposal for Rust that would do things differently.

Keep in mind that one requirement is being able to create things like Embassy.

https://github.com/embassy-rs/embassy

Re: Thoughts on Go vs. Rust vs. Zig

#370

Post by disappoint »

Dylan16807 wrote: post #335
disappoint wrote: post #283

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/

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, like some complex algorithm, it could by itself be worse overall. And Rust specifically have developers use unsafe for some algorithm implementations, for flexibility and performance.

Post reply on HN