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

261–270 of 308 posts

Re: My negative views on Rust (2023)

#261

Post by estebank »

NoGravitas wrote: post #234
jerf wrote: post #56

Earlier quoted context omitted.

"I'm often thwarted by the fact that for anything requiring remotely decent speeds, python most of the time already delegates to C extensions and so any rewrite is not as useful" Be sure you verify this is the case for whatever you think it is, though. Pure Python is so much slower than compiled languages (not just Rust) that you don't have to do much percentage-wise in pure Python before you've badly fallen behind i…

It would be interesting to me to look at something written in Python and rewritten in Rust with a 40x speed-up, and then rewrite it in something like C# or Common Lisp, and see what the speed-up is. My gut tells me the Rust implementation would use significantly less memory than the CL one, but be only minimally faster, if at all. But my gut has been known to be unreliable in the past.

When comparing a networked service that wrote to disk (a-la magic wormhole) written in Java and in Rust, after 3 iterations of improvements on the respective implementations the throughput was the same for both, CPU utilization was comparable, but memory usage was orders of magnitude lower for Rust. I think that Java will have difficulty closing the gap until project Valhalla (value types in the JVM) is completed, but even then it'll be difficult to bring the ecosystem along to materialize all its benefits.

Re: My negative views on Rust (2023)

#262

Post by Const-me »

refulgentis wrote: post #253
Const-me wrote: post #192

Earlier quoted context omitted.

> 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://bevye…

> I don’t think animating 1000 things per frame gonna saturate a CPU core doing these computations Oh, my sweet summer child. :) > In modern games none of that bandwidth is processed on CPU. Games use GPU for that, which don’t run Rust. So is your claim that OP is making up stuff about running code on the CPU because its a 3D engine? Also, why mention megapixels if you think it's irrelevant? :) > Weak claim? "_all_ p…

> OP is making up stuff about running code on the CPU because its a 3D engine?

I’m not sure CPU-evaluated animations are often critical performance bottlenecks of game engines.

> why mention megapixels if you think it's irrelevant?

Count of screen-space pixels is a hard upper limit of count of simultaneously visible things on the screen. Animating occluded meshes is pointless.

> many memory-safe languages and runtimes and have performant data structures

Indeed, because people who designed these memory-safe languages wanted to support arbitrarily complicated data structures implemented using safe subset of these languages.

Safe Rust supports arbitrarily complicated code, but requires unsafe to implement most non-trivial data structures.

It’s possible to hide unsafe code deep inside standard library, possible to implement safe APIs over unsafe implementations, but still, for people who actually need to create custom data structures (as opposed to consuming libraries implemented by someone else) none of that is relevant.

Re: My negative views on Rust (2023)

#263

Post by Const-me »

almostgotcaught wrote: post #257
Const-me wrote: post #256

Earlier quoted context omitted.

> on targets that aren't in {x32, x86, ARM64}? I have personally shipped embedded Linux software running on 32 bit ARMv7 SoC written mostly in C#. The product is long in production and we’re happy with the outcome. > Does it target RISC-V? Not sure if it’s ready for production, but see that article: https://www.phoronix.com/news/Microsoft-dotNET-RISC-V > Does it target PTX? According to nVidia, the answer is yes: htt…

> Not sure if it’s ready for production, but see that article: https://www.phoronix.com/news/Microsoft-dotNET-RISC-V > It's coming from a Samsung engineer, Dong-Heon Jung, who is involved with the .NET platform team and works on it as part of his role at Samsung. answer: no > According to nVidia, the answer is yes: https://developer.nvidia.com/blog/hybridizer-csharp/ > Dec 13, 2017 answer: no > Not sure, probably not…

> Dec 13, 2017

OK, here’s a newer project which does about the same thing i.e. compiles C# to PTX https://ilgpu.net/ BTW, it supports OpenCL backend in addition to CUDA.

Re: My negative views on Rust (2023)

#264

Post by pjmlp »

almostgotcaught wrote: post #254
neonsunset wrote: post #252

Earlier quoted context omitted.

> very strongly implies that they're completely interchangeable Not completely but they are interchangeable. C# at its inception was as much inspired by C++ as it was by Java. Since then, it only further evolved to accommodate far more low-level scenarios and improve their performance. It provides the kind of capabilities you'd usually expect from C++, so this statement holds true. Calling C exports is one `static ex…

> Not completely but they are interchangeable ... I'll just ask you this extremely simple question: does C# compile/run/whatever-magic-you-think-it-does on targets that aren't in {x32, x86, ARM64}? Does it target RISC-V? Does it target PTX? Does it target AMDGPU? Are you getting the picture? Pre-empting the most low-brow dismissal: these are only niche targets if you've never heard of a company called NVIDIA.

Yes, NVidia has support for .NET on the CUDA ecosystem via partners, the only one that matters on GPGPU.

Yes, Linaro is doing work for managed runtimes on RISC-V, although it remains questionable how much RISC-V matters outside nerd circles.

Re: My negative views on Rust (2023)

#265

Post by pjmlp »

dartos wrote: post #239
hyperbrainer wrote: post #48

Earlier quoted context omitted.

> Rust is as complex as C++: ...no, it's not. Maybe not yet, but it is heading in that direction; and I only say this because of the absolutely giant pile of features in unstable that seem to be stuck there, but I hope will eventually make its way to stable at some point. > Async Rust really is fine I dunno. Always thought it was too complicated, but as another person pointed out avoiding Tokyo::spawn solves many iss…

> Maybe not yet, but it is heading in that direction I have little doubt that Rust will end up being as complicated as C++ eventually, but a big difference is how explicit and well documented the discusson of new features are. The Rust RFCs provide a ton of context to almost every feature of the lagnuage. I find that historical context extremely helpful when trying to figure out why something is the way that it is. T…

ISO Rationales and papers.

Re: My negative views on Rust (2023)

#266

Post by pjmlp »

lacker wrote: post #64

I like Rust but at the same time I agree with the points here. These things are indeed problems with Rust. Nevertheless, C++ has even worse problems. When your alternative is using C++, that's the time to consider Rust.

Still a non starter in many industries, other than for those that enjoy building ecosystems from scratch.

Re: My negative views on Rust (2023)

#267

Post by pjmlp »

tptacek wrote: post #102
DiabloD3 wrote: post #70

Earlier quoted context omitted.

I don't think the people that use it as a slur actually define it. They use it to mean the language they don't like because they think it has some level of enforced complexity that takes away from the language instead of being an important feature of the language.

Yes: it's about the distinction between global GC and programmer-defined memory management. GC is about as straightforward a tradeoff as you can make: remove a very large class of programmer concerns in exchange for a different performance envelope. It is not reasonable to argue that Rust's memory management doesn't represent a point on a tradeoff space --- that people suggesting GC languages are better fits for some…

Meanwhile there are companies doing just that, better let their management know how fool they are selling bare metal real time Java runtimes, Oberon, Go and C# based microkernels.

Even more so the fools that given them money for such products.

/s

Re: My negative views on Rust (2023)

#268

Post by neonsunset »

almostgotcaught wrote: post #254
neonsunset wrote: post #252

Earlier quoted context omitted.

> very strongly implies that they're completely interchangeable Not completely but they are interchangeable. C# at its inception was as much inspired by C++ as it was by Java. Since then, it only further evolved to accommodate far more low-level scenarios and improve their performance. It provides the kind of capabilities you'd usually expect from C++, so this statement holds true. Calling C exports is one `static ex…

> Not completely but they are interchangeable ... I'll just ask you this extremely simple question: does C# compile/run/whatever-magic-you-think-it-does on targets that aren't in {x32, x86, ARM64}? Does it target RISC-V? Does it target PTX? Does it target AMDGPU? Are you getting the picture? Pre-empting the most low-brow dismissal: these are only niche targets if you've never heard of a company called NVIDIA.

> RISC-V

The work is underway: https://github.com/dotnet/runtime/pulls?q=label%3Aarch-riscv

> Nvidia's PTX, AMD

https://ilgpu.net/ and even https://github.com/m4rs-mt/ILGPU/blob/c3af8f368445d8e6443f36...

While not PTX, there's also this project: https://github.com/Sergio0694/ComputeSharp which partially overlaps with what ILGPU offers

Arguably, even C++ itself - you are not using "full" C++ but a special subset that works on top of specific abstraction to compile to GPUs, and I was told that CUDA C++ is considered legacy.

The original context of discussion is performance and perceived issue of "having runtime", which is what my reply is targeted at. In that context, C# provides you the tools and a solution other languages in the class of Java, Go, TS and anything else interpreted just don't have. So you could reasonably replace a project written in C++ that requires assurances provided by C++ with C#, and possibly re-apply all the freed-up developer productivity into further optimizations, but you wouldn't be able to do so with the same degree of confidence with most other originally high-level languages. Another upcoming contender is Swift.

Re: My negative views on Rust (2023)

#269

Post by School-Cotton »

hollerith wrote: post #177
tptacek wrote: post #176

Earlier quoted context omitted.

No, I don't think so? I would have predicted games as a sweet spot for Rust. Most significant game projects are done in C++, and I look at Rust as basically obsoleting C++.

OK. Thanks. My guess was that since almost no one will pay more for a game's having fewer security vulns, there is less benefit to incurring the expense of Rust (takes longer to learn, development speed is slightly less)

Rust's value proposition has nothing to do with security vulnerabilities, except that security vulnerabilities are a type of bug.

The point of Rust is to be a language that competes in the same niche as C++ but makes it much more difficult to write large classes of bug, much broader than just "security vulns".

Re: My negative views on Rust (2023)

#270

Post by RandomThoughts3 »

tinrab wrote: post #191
delifue wrote: post #185

Earlier quoted context omitted.

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.

> it's coming from misunderstandings of what the language is

“You are just not holding it right.”

Rust borrow checker indeed does force you to make contorsion to keep it happy and will bite you if you fail to take its particularity into account. It’s all fine and proper if you think the trade-off regarding safety is worth it (and I think it is in some case) but pretending that’s not the case is just intentionally deluding yourself.

The people here implying that the BC forces you to use a good architecture are also deluding themselves by the way. It forces you to use an architecture that suits the limitations of the borrow checker. That’s pretty much it.

The fact that such delusions are so prevalent amongst part of the community is from my perspective the worst part of using Rust. The language itself is very much fine.

Post reply on HN