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

251–260 of 308 posts

Re: My negative views on Rust (2023)

#251

Post by tialaramex »

burntsushi wrote: post #230
tialaramex wrote: post #220

Earlier quoted context omitted.

Sure, and there would probably be some value in a tool which can walk them through the easy stuff before they show a real human code which it turns out just wasn't tested with release optimisations or whatever. Still, as I understand it CTRE means if you just "use" the same expression over and over in your inner loop in C++ (with CTRE) it doesn't matter, because the regular expression compilation happened in compilat…

IDK how we jumped to CTRE. Python doesn't do CTRE. It's doing caching. In Rust, you use std::sync::LazyLock for that. I don't get what the problem is to be honest. I assume by CTRE you're referring to the CTRE C++ project. That's a totally different can of worms and comes with lots of trade-offs. I wish it were easy to add CTRE to rebar, then I could probably add a lot more color to the trade-offs involved, at least…

I jumped to CTRE because it's another way that you can get the better results. The programmer need have no idea why this works, just like with caches.

I agree that there are trade-offs, but nevertheless compile time regex compilation is on my want list, even if a long way down it. I would take compile time arithmetic compilation† much sooner, but since that's an unsolved problem I don't get that choice.

† What I mean here is, you type in the real arithmetic you want, the compiler analyses what you wrote and it spits out an approximation in machine code which delivers an accuracy and performance trade off you're OK with, without you needing to be an expert in IEEE floating point and how your target CPU works. Herbie https://herbie.uwplse.org/ but as part of the compiler.

Re: My negative views on Rust (2023)

#252

Post by neonsunset »

almostgotcaught wrote: post #250
pjmlp wrote: post #224

Earlier quoted context omitted.

As usual the typical argument that if it doesn't cover 100% of everything it isn't good enough. There are plenty of use cases where NativeAOT works perfectly fine, and is getting better with each .NET release.

> As usual the typical argument that if it doesn't cover 100% of everything it isn't good enough. This text > 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. very strongly implies that they're completely interchangeable. They're not. It's as simple as that. Some…

> 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 extern ...` method away, you can define explicit layout for structs (that satisfy 'unmanaged' constraint), you have fixed arrays in structs, stack buffers, pointers and ability to do raw or abstracted away manual memory management, etc. You can mmap device-shared memory and push data into GPU. You can accept pointers from C or C++ and wrap them into Spans and pass those to most standard library methods.

Re: My negative views on Rust (2023)

#253

Post by refulgentis »

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

Earlier quoted context omitted.

> 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://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_ performant data structures in Rust _must_ use unsafe code" is a long tail reading of the original comment. If that was the intent, it is a weak claim, because we can observe many memory-safe languages and runtimes and have performant data structures. (minecraft was written in Java, years and years ago!)

> Look at the source code of data structures implemented by Rust standard library.

This is the bailey, which was directly covered in the previous comment.

The motte was "all performant data structures in Rust must use unsafe code"

Here, the bailey, steelmanning as strongly as possible, is "data structures with unsafe code are more performant than ones without", which was directly said in the comment you are replying to.

In addition to the swapping, this is a picture-perfect replication of the bomber with holes on it meme, as the other reply notes.

Re: My negative views on Rust (2023)

#254

Post by almostgotcaught »

neonsunset wrote: post #252
almostgotcaught wrote: post #250

Earlier quoted context omitted.

> As usual the typical argument that if it doesn't cover 100% of everything it isn't good enough. This text > 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. very strongly implies that they're completely interchangeable. They're not. It's as simple as that. Some…

> 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.

Re: My negative views on Rust (2023)

#255

Post by punkbit »

awesome_dude wrote: post #73
DiabloD3 wrote: post #3

I've read this before, it's been passed around the Rust community a few times. The annotated tl;dr is: Chris doesn't want to learn how hardware works, they don't want to learn how to write optimal software, they don't want to write safe software, they just want to write in a language they already know because they're not comfortable with learning other languages because their home language is a functional language (H…

So, we should be focused on attacking the author, not the points raised in the article?

The author predicted it.

Re: My negative views on Rust (2023)

#256

Post by Const-me »

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.

> 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: https://developer.nvidia.com/blog/hybridizer-csharp/

> Does it target AMDGPU?

Not sure, probably not.

Re: My negative views on Rust (2023)

#257

Post by almostgotcaught »

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

Earlier quoted context omitted.

> 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.

> 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.

correct, the answer is no.

again: this isn't politics, this is software, where the details actually matter.

Re: My negative views on Rust (2023)

#258

Post by s17n »

johnnyanmac wrote: post #126
s17n wrote: post #43

Earlier quoted context omitted.

> Fetishization of Efficient Memory Representation: ... I don't understand what the point is here. Some people care about avoiding heap allocations? They're a tool just like anything else The point is that dealing with the Rust borrow checker is a huge pain in the ass and for most Rust applications you would have been better off just using a garbage collected language.

Yeah. I wouldn't use Rust as a scripting language for that reason. But some critical applications want that enforced correctness and (hopefully) proper performance to be guaranteed if you pass the compiler. I want to eventually join the "50 engines for every game" race that is rust gsme engineer development, but I'm sure not going to have the fast iteration part of design be done in Rust. The renderer and all the man…

Enforced correctness is great. Manual memory management isn't appropriate for most applications (games of course are an example of where it is!)

Re: My negative views on Rust (2023)

#259

Post by estebank »

SkiFire13 wrote: post #206
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…

> You do need efficient data structures, which often implies developing custom ones for specific use cases. You are assuming you can't do this with those vecs/maps. But you can! That's what the "additional semantics" are. They will be slightly slower due to often using indexes instead of raw pointer, which requires a bound check and an addition to get the pointer, and sometimes a reallocation, but they won't be that…

> They will be slightly slower due to often using indexes instead of raw pointer, which requires a bound check and an addition to get the pointer, and sometimes a reallocation, but they won't be that slow.

This is not a fundamental requirement, though. Assuming arena-like behavior, the index will be constructed/provided by the arena itself, so the bounds check can be safely ellided by-construction. Reallocation cost of the entire arena could be expensive, but if that is a cost you'd want to ammortize down to a new allocation, the arena could be implemented as an extensible list of non-growable arenas: every time an arena is full, you append another. This can be an issue if you don't keep track of deletions/tombstones or can't afford a compaction step to keep memory usage down, but in practice having all of these requirements at once is not as common.

Re: My negative views on Rust (2023)

#260

Post by spease »

pjmlp wrote: post #246
spease wrote: post #245

Earlier quoted context omitted.

I’ll try to keep this comment shorter. :) The thing about Rust abstractions is that they’re a lot more useful and forgiving than C++. Eg: In Rust, I cannot accidentally use an option incorrectly and have the program compile. When it fails to compile, there’s a good chance the compiler will suggest how I could do what I wanted to do. In C++, if I dereference an optional without checking it, I’ve triggered “undefined b…

Use the C++ clippy version, plenty of variants to chose from. Which by way is a good point, even Rust needs its clippy, so not everything is so perfectly designed to make clippy superfluous.

> plenty of variants

Aaaand you’ve lost me.

I don’t want to waste my time either setting up multiple linters or having to drill down into the pros and cons of each. If the C++ community cannot even reach a consensus on which linter it endorses, I imagine it can’t reach a consensus on what it lints, which involves even more decisions.

Secondly, both times I’ve tried to roll out or use a linter, I’ve encountered passive or active resistance from the other developers on the team.

This resistance went deeper than the linter. On one team they didn’t want to use new language constructs from the last decade, on the other team they explicitly complained about me doing things differently than 15 years ago. In both cases they rejected what I understood to be the core C++ guidelines in favor of writing their own codebase-specific coding guidelines so they could pick and choose the constructs they understood rather than trying to adhere to what might be idiomatic for a particular edition.

Unless something is 100% endorsed by the C++ community, it’s absolutely not something that I’m even going to try to champion. I’ve already been flat-out told “no one cares about your opinion” trying to explain how type-safety in C++ can improve readability in code reviews, which I thought was completely noncontroversial.

To your second point, the point of linters is to guide code to be more idiomatic; it’s not an issue of language design, but of educating humans in mostly non-functional readability and best practices.

Post reply on HN