Hacker News Reader

Comment by lumost | Hacker News Reader

so something I wonder, in a typical language you can easily pass by reference between components and threads. Avoiding any allocations.

In rust the unspoken rule seems to be to allocate, allocate, allocate - unless you are writing a special purpose library etc. Which makes me wonder, is rust actually faster than a GC'd language when doing heavy async work?

View on HN

I think a lot of Rust users would argue they don’t even care much about performance. They just enjoy all of the correctness guarantees the compiler can enforce, as well as how ergonomic the language can feel. Being able to deploy a single static binary, and having an easy to use build tool and package manager are significant bonuses as well. Rust makes really hard problems easier when you know the compiler has your back.

Rust gives you the tools to write very high performance code, but it doesn’t have to be about that.

I’ve had to point out to people quite a few times that garbage collectors can improve performance… especially compared to naive implementations of manual memory management. GCs are not just a tool for lazy programmers. GCs can make allocation incredibly fast, and you get to defer cleanup work to another thread(s), which means less work in the critical path. Removing work from the critical path is how you make software faster. Every tool has tradeoffs, and GCs are a tool. GCs often use more memory as a tradeoff.

I like Rust well enough, but I do wish we had a language that combined the ergonomics of Rust with the dead simple concurrency model of Go/Erlang. I haven’t tried it, but Luantic looks promising: https://github.com/lunatic-solutions/lunatic

As it is, we’re fortunate to have quite a few great languages and platforms these days.

> I think a lot of Rust users would argue they don’t even care much about performance. They just enjoy all of the correctness guarantees the compiler can enforce

Aren't these correctness guarantees only for performance related factors though? (allocation/memory and concurrency). The rest of your program would be just as correct in any other language.

No. A ton of languages don’t support proper Sum Types, and Rust’s emphasis on errors-as-values helps you think about error handling, instead of only thinking about the happy path. Rust also doesn’t do implicit type coercion and a host of other things that can cause correctness issues. Rust gives you the tools to express more of what you’re doing to the compiler than a lot of languages, which lets the compiler help you more.

It’s natural that a lot of programs have some form of concurrency, so that’s an extremely common thing for Rust to help with, but it’s not the only thing.

Not really.

For me, the number-one Rust feature I love is that, by baking monadic optionality and error return in from the beginning (Option<T> and Result<T, E>), I can trust that, unless an author abuses panic! (in which case I never trust their code again), I can see all a function's return paths in its type signature. (Without having to choke down a pure functional language like Haskell with that currying-based function call syntax that I can never get used to.)

The runners-up are how fast Rust starts compared to Python or Java or similar when writing a CLI tool and how nice PyO3 makes safely writing libraries or backends for tools that need to be in Python for some reason like "nothing but PyQt, PySide and possibly QtJambi offers memory-safe QWidget bindings... and I've never found a Java app that didn't feel laggy and sluggish on X11".

interesting! The main reasons I like rust are

- Can compile to anything, you can use one language to write Cuda Kernels, backend services, distributed processing jobs, WASM apps, and native apps.

- Performance, comparable to better than C.

I like fast languages as it avoids headaches that come from slow languages. If rust wasn't fast, I'd probably just stick to a polyglot language portfolio and pass it by.

EDIT: I also just clicked through to lunatic, that does look very promising!

You should also check out Gleam! https://gleam.run/

It's almost like Rust and Elixir had a baby :D

As for the rest of the comment: totally. Almost none of the code I write in Rust needs C-like performance and I still choose Rust for it.

> in a typical language you can easily pass by reference between components and threads.

and that's when you usually get data races ;)

> In rust the unspoken rule seems to be to allocate, allocate, allocate - unless you are writing a special purpose library etc. Which makes me wonder, is rust actually faster than a GC'd language when doing heavy async work?

I think it's a bit more nuanced. `Arc` is still a "smart pointer", so while it's not a straight Rust reference, it acts as a pointer. Yes, it allocates and it needs to do a reference count, but the overhead is very small. So while in practice it is not "zero cost", it's usually negligible.

This isn’t quite accurate. It’s generally really easy in Rust to pass things by reference, and even inner async fns, this is easy. The issue with async and Futures, is that sometimes you need to capture the future and then pass that to something else to execute. In that context, shared references are hard, and just clone, or arc box like mentioned.

Fwiw i rarely allocate around these "issues" and i use all async. I think your comment could be tweaked to say:

> In rust the unspoken rule seems to be to allocate, allocate, allocate when you run into a lifetime issue

Lifetimes work fine with async, but some types of lifetimes can be problematic, for sure.

> in a typical language you can easily pass by reference between ... threads

Yeah. And that is almost always an error on those languages too.

It's often not. Many high- performance libraries use fine- grained locking within logical units (eg locking buckets within a hash table in the fast path rather than locking the table), which almost necessitates sharing references.

So, you keep the hash table read-only on a static context, and only mutates some internal references?

In rust you will have to declare it exactly like that. That's not really an example of passing mutable references between threads.

Reply on news.ycombinator.com