White House: Future Software Should Be Memory Safe

crimsonpoodle@pawb.social to Programming@programming.dev – 4 points –
PRESS RELEASE: Future Software Should Be Memory Safe | ONCD | The White House
whitehouse.gov

On the one side I really like c and c++ because they’re fun and have great performance; they don’t feel like your fighting the language and let me feel sort of creative in the way I do things(compared with something like Rust or Swift).

On the other hand, when weighing one’s feelings against the common good, I guess it’s not really a contest. Plus I suspect a lot of my annoyance with languages like rust stems from not being as familiar with the paradigm. What do you all think?

42

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.

We need legislators who aren't all literally older than cryptography. If they weren't bought and paid for by billionaires that would be nice too.

That requires a population willing to vote for such legislators.

Don’t blame the victims for a sham of a democracy. First-past-the-post (FPTP) is there to prevent anything outside of a two party system where primaries are filled with (fully allowed) election fraud and cheating.

“we could have voluntarily decided that, Look, we’re gonna go into back rooms like they used to and smoke cigars and pick the candidate that way. That’s not the way it was done. But they could have. And that would have also been their right.” - DNC Lawyer

FPTP does destroy a lot, I'll give you that, but municipal and regional elections have miserable turn-outs too and they have much more potential for perceptible change than state or national change.

In the USA things have to get way worse than they are now before they get better. A very very large percentage of voters would have to be fed up with FPTP to force change in that area. Also, they would have to be educated enough to understand that FPTP is a problem.

For one, FPTP doesn’t get enough credit for just how nefarious it is. And let me be clear: I am speaking of the presidential election specifically, though I’m sure this applies to many aspects of this “democracy” including state elections, etc that you mentioned.

Instead, the overarching establishment narrative likes to point the finger at the electoral college (which also quite heavily biases the power of votes toward voters in less populous areas and states).

Since the established oligarchs (who own the news outlets) tend to control information delivery in this country, how would you break through that wall? Would you engage in peaceful protest (or self immolation)? Well, they’ve got a playbook for that too. They will discredit you and make you seem unhinged. For proof of that, look at the way they’re delegitimizing the brave, selfless active duty Air Force member who engaged in peaceful protest by self immolation outside of the Israeli embassy against the Gaza war for just how easy it is. Most news watching voters probably already think he was crazy. It didn’t quite have the power that that act had during, say, the Vietnam war.


Since you’re here, I’m guessing you’re a software engineer. Do me a favor: Model the real world dynamics of a US presidential election using domain driven design, making sure to accurately represent the two objectively unfair stages:

Rule #1: All candidates must pass stage 1 to be eligible for stage 2.

In stage 1, feel free to cheat, commit fraud, and engage in any strategy you need to prevent anyone but the owners of the party’s preferred candidates from winning. After all, your party is a private organization that can engage in whatever unfair tactic they deem necessary.

In stage 2, (if you’re paying attention, you ALREADY have irreparably biased the possible outcomes by cheating in stage 1) because of FPTP, you can now simply choose between only two of the MANY, MANY parties.

If you designed a system like that as a software engineer, your colleagues would be at your throat about how flawed that design was. However, here in the US, that’s just the design of our dEMoCrACy oF tHa gReATeSt cOuNTry iN tHa wErLD! 🥴

Edit: That “much worse” statement seems to come from a place of privilege. Don’t forget that. RIGHT NOW, more people are homeless and destitute than any other time in MY LIFE (I was born in the late 70’s). And most people literally have no say in whether or not their tax money is being used to genocide Muslims overseas to make room for a puppet government. Remember: You’re an anti-Semite if you oppose genocide.

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.

Even the best programmers are going to make mistakes at times. Saying the solution is to just be perfect all the time is impossible.

Absolutely. The problem is, most programmers are mediocre. So sadly the protection of stupid people tends to take cultural precedence.

Please show me a single "good" programmer who is working with C/C++ and hasn't had a single memory bugs in a decade.

Check out Eskil Steenberg. He's mostly a game dev, but he has some really good talks.

And you know with 100% certainty he hasn't had a single memory bug in his last decade of developing?

He has written his own libraries and programs to ensure these things don't happen.

What you people need to understand is that these problems have been solved before Rust. They just weren't baked into the language. And so people made mistakes.

https://www.youtube.com/watch?v=pvkn9Xz-xks

I'm not saying Rust is not always the better choice. Of course not. I'm just oh-so-weary of this rewrite-the-world zealotry a lot of people have about it.

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.

writing a high performance video game that can run on older hardware

Unless it's some really exotic platform, I'd honestly still say no. Rust has shown that memory safety and performance doesn't have to be a tradeoff. You can have both.

But sure, if whatever you're targeting doesn't have a Rust compiler, then of course you have no choice. But those are extremely rare cases these days I'd say.

I don't even think we really need to eek out every MHz or clock cycle of performance these days unless your shipping code for a space vehicle or something (But that's an entirely different beast)

We've got embedded devices shipping with 1GHz+ processors now

It's just time to move on from C/C++, but some people just can't seem to let go.

That is the mindset that gives us text editors using 100% cpu to blink a cursor because their css triggers a bug in the web browser they ship to render the text editor.

You can be memory save without shipping a whole browser, but disregarding power and memory efficiency will just make performance gained by hardware evaporate in overhead.

Battery life is a reason. I've had clients come to me complaining their solution from another vendor didn't last very long. Turns out it was running Java on an embedded device.

It’s just time to move on from C/C++, but some people just can’t seem to let go.

The Rust community has 2 websites that I keep periodically checking: Are we game yet? and Are we GUI yet?. The answers on those sites are respectively (as of February 2024, when this comment is written) "Almost. We have the blocks, bring your own glue" and "The roots aren't deep but the seeds are planted". I've seen the progress in Bevy and Slint, but it's still the same, those websites don't change, and my situation WRT to making a Rust project for fun or work it's the same.

I'll be happy to start doing Rust projects whenever I get the chance (which will be when it's a sufficient tool for my use cases). But I'm tired of smoke sellers.

Have you actually tried making a GUI or a game? I don't think you can summarize the state of the whole ecosystem in a sentence that doesn't change in years. I've made perfectly functional GUIs with iced, and imgui. Haven't tried slint yet.

Godot is a very popular game engine and it's written in rust, so you probably can use it in rust.

I've wanted to start a project in Rust, but for the ideas that I have (and the time that I have for a hobby project, as for work it's rarely starting a new one, but continuing and existing one), Rust seemed a viable, but not ideal alternative to just doing it all in C++, for which I already have enough knowledge and very well proven libraries. I will look again soon, and I will keep looking because eventually something will surely click, it's just that so far, the time has not been right.

Note that my point is not that it's unusable for everyone. Just that it's false that "some people just can't seem to let [C or C++] go", as the previous comment said. I can't let go something that works well for something that doesn't, given the projects that I have to work on.

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.

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

This is facile.

According to Microsoft, about 70% of security bugs they see are memory safety issues.

Yes: if you introduce memory safety, there's still those 30% of security bugs left. But, well, I'd rather worry about 30% of issues than 100%...

Similarly, I use libraries that eliminate SQL injections unless you really go out of your way.

I've written quite a bit of Rust and a lot of C and C++ code. I'll take Rust over C or C++ for any task, including ones where memory safety isn't a concern. Yes, there's a learning curve, but overall it's just more pleasant to use. Now that I'm used to it, writing C++ code feels just as much like fighting the compiler as Rust ever did.

In cases where bugs have been counted they tended to make up the majority of vulnerabilities. Chrome, Firefox, and Windows reported that around 70% of security vulnerabilites were memory corruption. Yes a subset, but the majority of the worst subset.

I've also heard that unsafe Rust is even more dangerous than C. I guess that's probably something to do with the fact that you're always on your toes in C vs Rust? I don't know. But if you need to do any sort of manual memory management you're going to need unsafe Rust.

No, rust is stricter because you need to think a lot more about whether weird edge cases in your unsafe code can potentially cause UB. For ex. If your data structure relies on the Ord interface (which gives you comparison operators and total ordering), and someone implements Ord wrong, you aren't allowed to commit UB still. In C++ land I'd venture to guess most any developer won't care - that's a bug with your code and not the data structure.

It's also more strict because rusts referencing rules are a lot harder then C's, since they're all effectively restrict by default, and just turning a pointer into a reference for a little bit to call a function means that you have to abide by those restrictions now without the help of the compiler.

Unsafe code should be a very, very small part of any Rust codebase. Lots of major libraries have a policy against including any unsafe code at all, because 99.9% of the time you can do just as well with safe cost. The major exception is when you need to call C code.

The thing is the whole c program is unsafe. In rust individual parts are marked unsafe. This means auditing should be easier. Also being always on your toes isn't really viable. Breaking down the program into safe vs unsafe is probably an improvment

I've also heard that unsafe Rust is even more dangerous than C.

Utterly Untrue :
It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked.

Way to necro a thread. This point was made months ago.

Zig is a pretty interesting alternative to C

Pretending Rust means no more exploitation is stupid.

I guess? Are you alluding to someone or something in particular?

Mainly those who imply we should rewrite absolutely everything in Rust.

Except RIIR is a meme, not a real thing to be taken seriously.