When rust ≠ performance. a lesson in developer experience • Hacker News Board

Re: When rust ≠ performance. a lesson in developer experience

#21

Post by koakuma-chan » Wed, Feb 04, 2026, 12:56 AM UTC

jvanderbot wrote: post #17

notorandit wrote: post #15

Of course rust is not performance. Rust is a programming language. Performance is a mix of programmer's ability, clever design and compiler optimizations.

For a long time, Rust == performance because a _lot_ of people moved into Rust that had never really done programming with a concurrency-sane compiled programming language. For them, Rust was synonymous with performance! Many supporting crates reinforced this. Rayon, Tokio (though not "performant", it was an improvement over naive impl), etc made jumping from hello world to parallel/concurrent execution pretty simple…

What is not performant about tokio? Do you know a better async runtime? I also heard tokio's "multi-thread" scheduler had some performance issues.

Re: When rust ≠ performance. a lesson in developer experience

#22

Post by koakuma-chan » Wed, Feb 04, 2026, 12:59 AM UTC

int_19h wrote: post #20

nicoburns wrote: post #19

Earlier quoted context omitted.

> Rust also hides allocation. Does it? In Rust you allocate by calling a function. That's exactly the same as C. Are there any langauges that don't allow you to hide allocation behind a function call? > So what you say is definitely true if you do an allocation heavy, heap fragmenting, RAII style of programming. I don't think Rust encourages lots of small allocations. Most of the Rust code I work with does a lot of a…

It's significantly more complex than Java due to the borrow checker and lifetimes in generics.

I don't think Rust is all that complex. On the other hand Java has many obscure features like serialVersionUID. For that matter, even fucking JavaScript is more complex than Rust with its var vs let, == vs ===, how, e.g., an empty array is false, parsing Date, how to make a "deep copy," etc, and TypeScript's type system can run Doom.

Re: When rust ≠ performance. a lesson in developer experience

#23

Post by Greduan » Wed, Feb 04, 2026, 1:39 AM UTC

nicoburns wrote: post #16

LAC-Tech wrote: post #7

I wonder to what extent the complexity of the rust language hurts performance. We all only have so much mental capacity, if much of it is spent on the various different intersections of rust's features, that reduces how much we can spend on making things fast. (I like Rust btw)

The alternatives with the potential to be as fast (C, C++, D, zig) are more complex in this regard because they make memory safety and lifetime tracking something that you have to keep track of in your head. Rust's biggest win is removing that mental overhead while allowing you to achieve the same performance as those other languages.

Other languages remove lifetime tracking by making you track it in very limited spots. Instead of "for each individual object", you track it for "this particular kind of object in this part of my application".

I.e. don't need to keep track of the memory for each allocation in my HTTP request and make sure I clean it up before closing the connection, I can just allocate some memory _per request_, put stuff in it, and at the end it gets cleaned up, whether I used the memory or not.

Some languages have the idea of "memory allocators" as a native construct, so that you can actually start thinking about managing memory in more sensible terms than "everything individually", e.g. Odin lang.

Re: When rust ≠ performance. a lesson in developer experience

#24

Post by nicoburns » Wed, Feb 04, 2026, 2:59 PM UTC

int_19h wrote: post #20

nicoburns wrote: post #19

Earlier quoted context omitted.

> Rust also hides allocation. Does it? In Rust you allocate by calling a function. That's exactly the same as C. Are there any langauges that don't allow you to hide allocation behind a function call? > So what you say is definitely true if you do an allocation heavy, heap fragmenting, RAII style of programming. I don't think Rust encourages lots of small allocations. Most of the Rust code I work with does a lot of a…

It's significantly more complex than Java due to the borrow checker and lifetimes in generics.

The borrow checker definitely adds complexity over Java. But Rust also removes complexity that is in Java. For example, inheritance and exceptions. Overall I do think Rust is a bit more complex than Java, but I don't think the difference is all that great.

Re: When rust ≠ performance. a lesson in developer experience

#25

Post by jvanderbot » Wed, Feb 04, 2026, 7:56 PM UTC

koakuma-chan wrote: post #21

jvanderbot wrote: post #17

Earlier quoted context omitted.

For a long time, Rust == performance because a _lot_ of people moved into Rust that had never really done programming with a concurrency-sane compiled programming language. For them, Rust was synonymous with performance! Many supporting crates reinforced this. Rayon, Tokio (though not "performant", it was an improvement over naive impl), etc made jumping from hello world to parallel/concurrent execution pretty simple…

What is not performant about tokio? Do you know a better async runtime? I also heard tokio's "multi-thread" scheduler had some performance issues.

Nothing is wrong with tokio, actually. I chose the wrong word

async != performance

async == concurrency

Unless you face a specific kind of slowdown, concurrency, and therefore async (and therefore tokio) is not a panacea. Many do face that slowdown, so for many it is.