White House: Future Software Should Be Memory Safe

Depends on if you're coding for critical infrastructure (i.e. - electrical grid), or writing a high performance video game that can run on older hardware.

We should absolutely have specific licenses like Civil Engineers do for computer infrastructure that is required for any software written for specific purposes. It would be a nightmare to implement, but at some point, it's going to be needed.

let me feel sort of creative in the way I do things

🚩

I'm just glad to see the White House listening to people who understand technology for a change.

they don’t feel like your fighting the language

I really understand what you mean wrt Rust. I really do - I was there once. But it's a phase you grow out of. Not just that - the parts you fight now will eventually become your ally.

and let me feel sort of creative in the way I do things

I had the same experience with C/C++. But as the design grows, you start hitting memory-safety bugs that are difficult to avoid while coding - even after you learn how those bugs arise in the first place. Just a lapse of concentration is enough to introduce such a bug (leaks, use-after-free, deadlocks, races, etc). I've heard that C++ got a bit better after the introduction of smart pointers and other safety features. But, it comes nowhere near the peace of mind you get with garbage collected languages.

That's where Rust's borrow checker and other safety measures kick in. The friction disappears when you acquire system knowledge - concepts of stack, heap, data segment, aliasing, ownership, mutation, etc. These knowledge are essential for C/C++ too. But the difference here is that Rust will actually tell you if you made a mistake. You don't get that with C/C++. The ultimate result is that when a Rust program compiles successfully, it almost always works as you expect it to (barring logical errors). You spend significantly less time debugging or worrying about your program misbehaving at runtime.

The 'friction' in Rust also helps in another way. Sometimes, you genuinely need to find a way out when the compiler complains. That happens when the language is too restrictive and incapable of doing what you need. You use things like unsafe, Rc and Refcell for that. However, most of the time, you can work around the problem that the compiler is indicating. In my experience, such 'workarounds' are actually redesigns or refactors that improve the structure of your code. I find myself designing the code best when I'm using Rust.

Leaders in Industry Support White House Call to Address Root Cause of Many of the Worst Cyber Attacks

And it's called C/C++. It's gotten so bad that even the friggin' white house has to make a press release about it. Think about it, the place where that majority barely even understand the difference between a file browser and a web browser is telling you to stop using C/C++. Hell, even the creator and maintainers of the language don't know how to make it memory safe. If that isn't a wake up call, then nothing ever will be.

And this isn't the first call! The IEEE also says more clearly: GTFO C/C++.

If you want memory-safe, don't write C/C++. Trying to get that shit memory-safe is a hassle and a half. You're better off learning a language that isn't full of foot-guns, gotchas, and undefined behavior.

CC BY-NC-SA 4.0

What memory-safe systems programming languages are out there, besides Rust?

So that's why I've been hearing non-stop crab rave music!

Rust does memory-safety in the most manual way possible, by requiring the programmer prove to the compiler that the code is memory-safe. This allows memory-safety with no runtime overhead, but makes the language comparatively difficult to learn and use.

Garbage-collected compiled languages — including Java, Go, Kotlin, Haskell, or Common Lisp — can provide memory-safety while putting the extra work on the runtime rather than on the programmer. This can impose a small performance penalty but typically makes for a language that's much easier on the programmer.

And, of course, in many cases the raw performance of a native-code compiled language is not necessary, and a bytecode interpreter like Python is just fine.

The interpreter or compiler could also introduce memory issues into the code. Much less likely to happen, but it is not unknown.

C++ can have excellent performance without ever using a single pointer and avoiding unsafe functions like gets() - this isn't necessarily a judgment on language - it's a judgement on bad programming habits.

Pointers fucking suck, in a modern C++ codebase everything should be pass by value or const/mutable ref. To my preference I'd rather drop mutable refs to force everything to be more functional but whatever.

I'm learning c++ via exercism because I'd like to use it for game development and other high performance use cases, and because it's a good pip for the resume.

In fact, I mostly did this because so many job listings mention it, haven't even come up with a high-scale game dev problem to solve.

I'll probably continue because I find it interesting and no amount of practice is bad, but my question is how is everyone letting this affect their outlook on c++ in their career vs side projects, etc. Really, I'm having a hard time imagining why it was important for this to be said in this way instead of just changing internal policies and job listings.

I'm going to advocate for C here: the sheer simplicity, fast compile times, and power it gives you means it's not a bad language, even after all these years. Couple that with the fact that everything supports it.

Rust, while I don't actually know how to write it, seems much more difficult to learn, slower to compile, and if you want to do anything with memory, you have to fight the compiler.

And memory bugs are only a subset of bugs that can be exploited in a program. Pretending Rust means no more exploitation is stupid.

I’m going to probably be downvoted to Hell, but I disagree wholly that it’s the language’s fault that people can exploit their programs. I’d say it’s experience by the programmer that is at fault, and that’s due to this bootcamp nature of learning programming.

I’d also blame businesses that emphasize quantity over quality, which then gets reflected in academia because schools are teaching to what they believe business wants in a programmer. So they’re just churning out lazy programmers who don’t know any better.

There needs to be an earnest revival of good programming as a whole; regardless of language, but also specifically to language. We also need to stop trying to churn out programmers in the shortest time possible. That’s doing no one any good.

That’s my two cents.

Oh yes, improve security by mandating that everyone uses higher level languages that encourage importing libraries.

I hate to pull the AI card, but AI has a better chance of catching low level language type issues than forcing people to use tools they didn't want to has of accomplishing anything positive.