Hacker News

When rust ≠ performance. a lesson in developer experience

34 points by suriya-ganesh 6 hours ago | 22 comments

binhex 5 hours ago

> but because we have this data (file name, etc.) passed back and forth between different layers in the code. we were doing lots of .clone() and db.open() at different layers to fetch the same data. The interesting part for me was that, this change reduced our

Reduced your what? The article seems to be cut off.

taeric 5 hours ago

I'm assuming it was going to say lines of code. It is highlighting that more was deleted than added.

larpingscholar 5 hours ago

I agree. Though the line count is meaningless as the vibe coded diff has pointless formatting and whitespace changes.

suriya-ganesh 5 hours ago

I wrote that PR and can guarantee you that it was not vibe coded.

the reason why I thought this PR was interesting is that, it only needed ~ 4 lines of real change, everything else was cascades due to that change. and the performance did improve with that "pointless formatting and whitespace changes"

suriya-ganesh 5 hours ago

ah! sorry. I meant to say, "the interesting part for me was that we removed code to improve performance."

notorandit 4 hours ago

Of course rust is not performance.

Rust is a programming language. Performance is a mix of programmer's ability, clever design and compiler optimizations.

jvanderbot 4 hours ago

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.

But I'm glad to see the downturn on that hype cycle.

koakuma-chan 44 minutes ago

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.

pointlessone 5 hours ago

This is extremely sparse on details.

koakuma-chan 5 hours ago

It feels like a rage bait. It's clearly their own fault and has nothing to do with Rust.

LAC-Tech 5 hours ago

maybe Rustaceans shouldn't rage so easily?

bitexploder 4 hours ago

Rust is a general purpose systems programming language. There are very few situations where you cannot attain C like performance with Rust. Skill issue, most likely.

kykat 5 hours ago

algorithm design and managing memory is something you have to think about regardless of what language you use, that should be obvious. Using rust doesn't guarantee correctness or performance, that should also be obvious.

Rust has features that make it easier to make correct and performant software, I think most programmers would agree?

Please stop this rust clickbait nonsense.

9rx 5 hours ago

> Please stop this rust clickbait nonsense.

But then new content on HN would decline to nearly nothing.

themafia 4 hours ago

> Using rust doesn't guarantee correctness or performance, that should also be obvious.

Judging from the most vocal segment of their community it's very much not obvious to them.

> make it easier

Define "easier." It's harder to make mistakes. I'm not sure this equates to developer "ease" in any way. In fact, if it's meant to be effective, it should be quite the opposite.

> rust clickbait nonsense.

It cuts both ways. There is a huge volume of "I switched to Rust and got 1% additional performance over C" posts here.

LAC-Tech 5 hours ago

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)

nicoburns 4 hours ago

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.

Greduan 45 seconds ago

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.

LAC-Tech 3 hours ago

Rust also hides allocation, and both the standard library and community best practices encourage many smaller allocations, which makes it much harder to reason about performance characteristics of your code.

So what you say is definitely true if you do an allocation heavy, heap fragmenting, RAII style of programming. Which is the context Rust was born in, right? A kind of C++ app dev context where that was (is?) the prevailing meta.

You're also completely glossing over the incredible complexity you get in all thee weird intersection of rust features. And there are a LOT of features. Reasoning about those are not free from a mental overhead stand point.

nicoburns 2 hours ago

> 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 arena allocation (using crates like https://github.com/orlp/slotmap) and reusing of allocations. And for that matter a lot of stack allocation avoiding the heap entirely. And it's borrowing system is fantastic for working with shared pointers to data without having to worry that something might accidentally overwrite it.

> You're also completely glossing over the incredible complexity you get in all thee weird intersection of rust features.

I don't really buy that Rust is complex. More complex than C I suppose (but C just pushes all the complexity into making you write 5x more application code), but closer to something like Java than something like C++.

int_19h 2 hours ago

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

koakuma-chan 41 minutes ago

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.