News White House urges developers to avoid C and C++, use 'memory-safe' programming languages

[gamerk316]

Are games and gaming drivers targets for exploits? 30% is not an acceptable loss, no. But what is the gain supposed to be?

The gain is not eating a 30% performance loss due to the choice of language.

 

[snemarch]

Oh boy, are we *Seriously* going to compare sorting performance as a metric now? I wasn't aware the vast majority of code execution was doing sorting algorithms.

Also, as you yourself admitted: In *practical* workloads, Rust is about 30% slower. Which is, again, why C reigns supreme at the HW/Driver layer. But hey, lets make a Rust NVIDIA driver; I'm sure nobody here will mind a 30% performance loss in games; it's not like everyone here spends a grand plus every year for smaller performance improvements. [sarcasm heavily implied]

You're complaining about sorting algorithm benchmarks, but basing your "30% slower" on another microbenchmark? 😉

It's my impression that Rust is usually about on par with C/C++, and when not you can drop to unsafe if needed... but hey, benchmarking can be deceptive and performance optimization is not trivial. Rust comes out pretty favorable in the Debian benchmark-game scores, but again: you gotta be mindful of what is being compared...

C is certainly more exploitable then modern C++, but that's by design. Drivers/embedded code have maximal performance requirements, and all those extra memory safety checks bleed performance. That's why it's not only not going anywhere, but is actually *gaining* usage again as the alternatives fall out of favor.

I very much prefer having low-cost safety in most of the codebase, and the ability to eschew it when necessary, as determined by profiling...

 

[palladin9479]

Sadly, even companies that do have experienced engineers tend to surround 1 experienced engineer with 10 low quality resources from lowest bidder in a 12 hour different timezone. This makes it very difficult for the 1 experienced engineer to be able to police the entire product.

This, this so damn much.

I'm not sure if people realize how much modern code is written by low paid contractors out of some Indian body shop. Companies will have one or two senior developers who may or may not actually have skills, then contract out mass amounts of work to remote contractors from low cost countries. And here is the real kicker, those contractors are all double or triple dipping. Meaning each one of them is working for two to three companies simultaneously, selling the exact same hours to all three and collecting multiple paychecks. That is why they do shoddy work, they don't have time to properly implement a function or service because they have to write two other ones for the other companies.

Ohh and I see the Rusters have arrived. Not a bad language for what it does, but we gotta treat the evangelicals the same way we treat the iFaith people.

 

[JamesJones44]

At the risk of being "one of those annoying Rust people" *,

A lot of people do this. It took several PoCs of existing products with heavy performance counter instrumentation to show that Rust in MOST workloads is pretty darn equal to C/C++ for our own company to at least consider Rust. For the areas where Rust under performs, the Rust community has been improving the compiler and the nightly of their up and coming 1.77 looks promising at closing more of those gaps.

https://programming-language-benchmarks.vercel.app/rust-vs-c

 

[bit_user]

Oh boy, are we *Seriously* going to compare sorting performance as a metric now? I wasn't aware the vast majority of code execution was doing sorting algorithms.

It's just a baseline. If it couldn't do that much, we'd probably be having a different discussion.

Also, as you yourself admitted: In *practical* workloads, Rust is about 30% slower. Which is, again, why C reigns supreme at the HW/Driver layer.

You're conveniently ignoring the part where unsafe was virtually the same speed. If need be, one can drop to unsafe mode in just the limited hotspots where necessary, which is usually a tiny subset of the code. Everywhere else, you can exploit the additional safety it provides. And everywhere, you can benefit from its richer abstractions.

BTW, I just spent a day debugging a random utility written in C, about 15 years ago, that wasn't doing anything fancy and had zero justification for not being written in C++. The bugs it had were all memory bugs, of the sort you'd never find in decent C++ code (thanks to STL).

But hey, lets make a Rust NVIDIA driver; I'm sure nobody here will mind a 30% performance loss in games;

I presume this is a disingenuous argument, since you don't seem so clueless as to think that 100% of the a game's critical path is spent burning CPU cycles in the GPU's driver code. Either way, it's not a good look for you.

If about 10% of the time in a game's critical path is spent in the driver, and all of that time is CPU time (i.e. not blocking on bus transfers or waiting on the GPU to do something, which seems unlikely), then running 70% as fast would equate to that piece of the pie taking 1.43x as long, which works out to only about a 4.2% performance loss as it relates to FPS.

On the flip side, a language like Rust gives you access to better algorithms and data structures, which might enable better algorithmic optimizations than one would attempt in plain C.

Finally, we can presume that driver developers know how to use profilers to find hotspots, which they can optimize by using unsafe mode, plain C, or asm, as the situation demands.

We shouldn't forget the opportunity cost that comes from using a more labor-intensive and error-prone language. By having the bulk of the code in a higher-level language than C, they should have more time to pursue both algorithmic and code optimizations.

The Linux kernel devs clearly get it. That's why they started using Rust in driver code. By volume, the drivers are probably the majority of the kernel sources and most of the time in them tends to be waiting on the device, itself.

it's not like everyone here spends a grand plus every year for smaller performance improvements. [sarcasm heavily implied]

The topic is emotive enough. I think the discourse isn't helped by sarcasm.

 

[bit_user]

Companies will have one or two senior developers who may or may not actually have skils, then contract out mass amounts of work from remote contractors from low cost countries. And here is the real kicker, those contractors are all double or triple dipping. Meaning each one of them is working for two to three companies simultaneously, selling the exact same hours to all three and collecting multiple paychecks. That is why they do shoddy work, they don't have time to properly implement a function or service because they have to write two other ones for the other companies.

Funny story: my employer hired a remote developer in another country where we had an office, but no other developers on my specific project. Over time, evidence mounted that this guy was pretty clueless and must've been subcontracting his work. He made too many slip-ups on calls and was too ignorant for it to have been his own work. I have no idea who interviewed him, as he was loaned to us by another team.

Ohh and I see the Rusters have arrived. Not a bad language for what it does, but we gotta treat the evangelicals the same way we treat the iFaith people.

Yeah, um, maybe not everyone in the world is either a hater, evangelist, or unifromed? Can someone be open-minded and interested in having an intelligent and informed discussion about a subject?

Rust was on their list, so it's entire on-topic. I only tried to bring some focus to it, because I got the sense that it was being dismissed out of hand, by some in this thread. I don't care if people don't like it, but I believe the arguments about it should be rooted in data and sound logic, rather than religion or people who are too set in their ways and therefore feel threatened by it. I'm not experienced with it, myself, but I'm definitely interested.

It's funny to me how the field of tech has changed and evolved so massively, in the past 5+ decades, yet some seem to cling to C as if nothing better can be created. Really? ? C was a product of its time, when computers simply weren't fast enough and capacious enough to compile a language like Rust. How does it make sense to claim that we can't use the power of modern computers to improve low-level languages?

 

[USAFRet]

 

[Eximo]

Financial world, no, it is scarier. A lot of the major institutions never moved away from mainframes. They've just virtualized them and people use terminal emulators to access them. All the people who actually know how they work are at retirement age.

 

[russsaidwords]

The article included JavaScript in it's list of memory safe languages, but in no way would anyone consider JavaScript a "safe" language. Searching elsewhere I can't find where the NSA might have recommended JavaScript.