Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My negative views on Rust (2023)

chrisdone.com

Post reply on HN
Print view View original

191–200 of 308 posts

Re: My negative views on Rust (2023)

#191

Post by tinrab »

delifue wrote: post #185
CryZe wrote: post #61

Earlier quoted context omitted.

> huge pain in the ass Maybe if you structure your code weirdly? I haven't encountered a major borrow checker issue that I couldn't easily resolve in many years.

It's not appropriate to say that "having trouble with borrow checker means code is wrong". Sometimes you just want to add a new feature and the borrow check force you to do a big refactor. See also: https://loglog.games/blog/leaving-rust-gamedev/

I hear this constantly but never see any examples of what they actually mean, or it's coming from misunderstandings of what the language is. I've seen people say how well the async code could be if Rust got a garbage collector. For the borrow checker specifically, I think it's important to understand smart pointers, Cell/RefCells, other primitives, and the fact that you don't have to solve everything with references.

Re: My negative views on Rust (2023)

#192

Post by Const-me »

refulgentis wrote: post #151
Const-me wrote: post #118

Earlier quoted context omitted.

> It is very high-performance, as animation evaluation has to be Are you sure evaluating these animations is performance critical? I doubt games have enough data to saturate a CPU core doing that. Screens only have 2-8 megapixels; animated objects need to be much larger than 1 pixel. If you animate bones for skeletal animation that’s still not much data to compute because real life people have less than 256 bones. Yo…

> Are you sure evaluating these animations is performance critical? Isn't this obviously true? A key part of UI work is avoiding "jank", which commonly refers to skipped frames. > I doubt games have enough data to saturate a CPU core doing that. Got a bit lost here: games? > Screens only have 2-8 megapixels. 4 bytes per pixel, 32 MB/frame. 120 frames / sec = 8 ms/frame. 3.84 GB/second. > animated objects need to be m…

> Isn't this obviously true?

To an extent sure, but we’re talking about low level micro-optimizations. Games don’t animate individual pixels. I don’t think animating 1000 things per frame gonna saturate a CPU core doing these computations, which means the code doing that is not actually performance critical.

> Got a bit lost here: games?

I searched the internets for “Bevy Engine” and found this web site https://bevyengine.org/ which says “game engine”. I wonder is there another Bevy unrelated to games?

> 3.84 GB/second

In modern games none of that bandwidth is processed on CPU. Games use GPU for that, which don’t run Rust.

> there's a weak claim that all performant data structures in Rust must use unsafe code

Weak claim? Look at the source code of data structures implemented by Rust standard library. You will find unsafe code everywhere. When you need custom data structures instead of merely using the standard ones you will have to do the same, because safe Rust is fundamentally limited in that regard.

Re: My negative views on Rust (2023)

#193

Post by tialaramex »

googh wrote: post #190
tialaramex wrote: post #189

Earlier quoted context omitted.

> Also, there are far more ways to cause UB in C++. As well as lots of Undefined Behaviour, C++ also has what its own experts call "False positives for the question is this a C++ program" the Ill-Formed No Diagnostic Required features, nothing like these exist in Rust, they're cases where you can write what appears to be C++ but actually although there are is no error or warning from the compiler your entire program…

Most (if not all) of your posts here on HN boil down to "C/C++ bad, Rust good". I wonder what you are trying to achieve by this, but I assure you that this does not do Rust any favor other than giving the impression that the Rust community is obnoxious.

> Most (if not all) of your posts here on HN boil down to "C/C++ bad, Rust good".

I haven't measured but it's easy to say categorically that it's not "all" unless somehow my posts about network protocols, aeroplanes, security and psychology among others fall into this vague category.

And yes, like Ignaz Semmelweis I can see an obvious improvement to how my profession does what it does and it's infuriating that the response from many other practitioners is "No, I don't like change, therefore you're crazy for explaining why I should change"

Ignaz Semmelweis died in an asylum. But on the other hand while Ignaz was correct and his proposals would have worked he couldn't explain why because germ theory was only confirmed after he died. Rust isn't in that situation, we know already exactly what the problems are with C++. So that means I can tell you not just that using C++ is a bad idea, but why it's a bad idea.

Re: My negative views on Rust (2023)

#194

Post by Const-me »

jltsiren wrote: post #120
Const-me wrote: post #109

Earlier quoted context omitted.

> Non-trivial data structures are often just a bunch of arrays/maps with additional semantics This might be fine for code which consumes data structures implemented by other people. The approach is not good when you actually need to implement data structures in your program. In modern world this is especially bad for a low-level language (marketed as high performance, BTW) because the gap between memory latency and c…

I used to think like that. Then C++11 arrived, and I realized I could get effectively the same performance with containers and move semantics, while spending less effort on writing and debugging the code. If you need an array for your custom data structure, a standard library vector is almost always good enough. Associative arrays are a bit more tricky, but you should be able to find a handful of map implementations…

> I could get effectively the same performance with containers and move semantics

When I’m happy with the level of performance delivered by idiomatic C++ and standard collections, I tend to avoid C++ all together because I also proficient with C# which is even faster to write and debug.

But sometimes I want more performance. An example from my day job is a multi-step numerical simulation which needs to handle grids of 200M nodes. When processing that amount of data, standard collections are suboptimal. I’m not using std::vector because I don’t need them to grow and I want to allocate these huge buffers bypassing C heap i.e. page-aligned blocks of memory zero initialized by the OS.

Re: My negative views on Rust (2023)

#195

Post by googh »

tialaramex wrote: post #193
googh wrote: post #190

Earlier quoted context omitted.

Most (if not all) of your posts here on HN boil down to "C/C++ bad, Rust good". I wonder what you are trying to achieve by this, but I assure you that this does not do Rust any favor other than giving the impression that the Rust community is obnoxious.

> Most (if not all) of your posts here on HN boil down to "C/C++ bad, Rust good". I haven't measured but it's easy to say categorically that it's not "all" unless somehow my posts about network protocols, aeroplanes, security and psychology among others fall into this vague category. And yes, like Ignaz Semmelweis I can see an obvious improvement to how my profession does what it does and it's infuriating that the re…

Most HN users already use languages with GC which are more memory safe than Rust. People still use C++ either because they are maintaining existing code, or they work in domains where memory safety is not really necessary (games, HFT, ML). Apart from these, C++ is rarely used in the real world.

> practitioners is "No, I don't like change, therefore you're crazy for explaining why I should change"

Who exactly are you referring to here? Your co-workers? LLVM maintainers? or the Linux kernel developers? Please be more precise.

Re: My negative views on Rust (2023)

#196

Post by almostgotcaught »

Const-me wrote: post #194
jltsiren wrote: post #120

Earlier quoted context omitted.

I used to think like that. Then C++11 arrived, and I realized I could get effectively the same performance with containers and move semantics, while spending less effort on writing and debugging the code. If you need an array for your custom data structure, a standard library vector is almost always good enough. Associative arrays are a bit more tricky, but you should be able to find a handful of map implementations…

> I could get effectively the same performance with containers and move semantics When I’m happy with the level of performance delivered by idiomatic C++ and standard collections, I tend to avoid C++ all together because I also proficient with C# which is even faster to write and debug. But sometimes I want more performance. An example from my day job is a multi-step numerical simulation which needs to handle grids o…

> proficient with C# which is even faster to write and debug.

I don't get it - why are we ignoring the fact that C# necessarily implies distributing CLR? NativeAOT doesn't work for everything.

Re: My negative views on Rust (2023)

#197

Post by Const-me »

almostgotcaught wrote: post #196
Const-me wrote: post #194

Earlier quoted context omitted.

> I could get effectively the same performance with containers and move semantics When I’m happy with the level of performance delivered by idiomatic C++ and standard collections, I tend to avoid C++ all together because I also proficient with C# which is even faster to write and debug. But sometimes I want more performance. An example from my day job is a multi-step numerical simulation which needs to handle grids o…

> proficient with C# which is even faster to write and debug. I don't get it - why are we ignoring the fact that C# necessarily implies distributing CLR? NativeAOT doesn't work for everything.

On AMD64 Windows, .NET 8.0 runtime takes 31.7 MB to download, and 70.7 MB on disk. On ARM64 Linux, the numbers are 28.4 MB and 75.0 MB, respectively.

For that amount of data, both internet bandwidth and disk space are rather cheap these days?

Re: My negative views on Rust (2023)

#198

Post by Ukv »

googh wrote: post #190
tialaramex wrote: post #189

Earlier quoted context omitted.

> Also, there are far more ways to cause UB in C++. As well as lots of Undefined Behaviour, C++ also has what its own experts call "False positives for the question is this a C++ program" the Ill-Formed No Diagnostic Required features, nothing like these exist in Rust, they're cases where you can write what appears to be C++ but actually although there are is no error or warning from the compiler your entire program…

Most (if not all) of your posts here on HN boil down to "C/C++ bad, Rust good". I wonder what you are trying to achieve by this, but I assure you that this does not do Rust any favor other than giving the impression that the Rust community is obnoxious.

I found their comment an interesting contribution to the discussion, pointing to a couple of specific pitfalls in C++. It's not just an empty "C/C++ bad, Rust good", and I don't see why it'd give the impression of an obnoxious community.

Re: My negative views on Rust (2023)

#199

Post by tmtvl »

Animats wrote: post #11

My big problem with Rust is too much "unsafe" code. Every time I've had to debug a hard problem, it's been in unsafe code in someone else's crate. Or in something that was C underneath. I'm about 50,000 lines of Rust into a metaverse client, and my own code has zero "unsafe". I'm not even calling "mem", or transmuting anything. Yet this has both networking and graphics, and goes fast. I just do not see why people see…

I don't use Rust and I've bounced off trying to learn it 3 times so far, so take this with a mountain of salt, but...

I think that Rust having unsafe is fine as there will be edge cases where the compiler can't quite work out whether some code will work fine or not and where the programmer can vouch for it. That's no problem.

The issue I have with it is that the unsafe block then gets kinda swallowed by the supposedly safe wrappers around it. And there's no clear auditable trail back to it. I find that a bit surprising as I'd expect it obvious to have some kind of 'uses unsafe' declaration (annotation? I don't know what Rust calls those statements with a number sign and square brackets in front of a subroutine) which would then propagate upwards. A bit like how in Java (the most elegant and refined of all programming languages) you can use an annotation to state that a function 'throws XYZException' which then needs to be propagated up to a point where it can get handled.

Not having such a mechanism feels a bit icky to me. It's like if there's spiders crawling out of your ears it's useful to know that they're coming out of your ears so you don't have to wonder 'are those spiders creeping out of my ears? Or out of my nose? Or out of my eyelids?', which would be a bit inconvenient.

Re: My negative views on Rust (2023)

#200

Post by hyperbrainer »

googh wrote: post #195
tialaramex wrote: post #193

Earlier quoted context omitted.

> Most (if not all) of your posts here on HN boil down to "C/C++ bad, Rust good". I haven't measured but it's easy to say categorically that it's not "all" unless somehow my posts about network protocols, aeroplanes, security and psychology among others fall into this vague category. And yes, like Ignaz Semmelweis I can see an obvious improvement to how my profession does what it does and it's infuriating that the re…

Most HN users already use languages with GC which are more memory safe than Rust. People still use C++ either because they are maintaining existing code, or they work in domains where memory safety is not really necessary (games, HFT, ML). Apart from these, C++ is rarely used in the real world. > practitioners is "No, I don't like change, therefore you're crazy for explaining why I should change" Who exactly are you…

What is "more memory-safe than rust" supposed to mean? Rust is completely memory-safe.
Post reply on HN