I don't think the government's goal in improving memory safety is because of Rust or any other particular technology.
The government buys technology from wherever, and until recently they never really cared where they got it from. If they need a USB Emulator, they buy the same Chinese Gotek from Ebay that you or I buy, and they get the same "Driver CD" full of buggy, broken English software, written by one person for $27 over the course of about 7 hours. Same thing with DVR systems, access controls, network appliances, access points. I've worked on government projects that were using 20 year old, broken, encryption libraries on active web servers. And when brought to their attention the people who use it don't care, and the people who are capable of doing something about it will never find out because it's too much work to replace and nobody wants to take that Zoom call.
I think the author is getting a little over-excited about Rust. Granted, they are a Rust developer. I'd love it if we could build everything in my favorite language. But the government doesn't want to replace everything with Rust. The government wants results. Period. It is the DOD, NSA, and CISA who need to become experts on how to realize those results. And they will probably release guidance that says "if you can't program securely in a memory unsafe language, don't use a memory unsafe language". The thing I think the author is missing is that nobody is going to mistaken "Made with RUST!" for "Impossible to cause undefined behavior!"
You can be a terrible programmer and still create undefined behavior, insecure code, data leaks, or any number of other problems in a memory safe language.
What the government is going to do is implement strict code import controls, similar to the export controls we already have. Purchasing departments will have to get software purchases signed off multiple times by qualified parties, and department leaders will have to prove that the technology they procure is adequately safe. In some situations I anticipate that means re-writing a bunch of code in Rust, and in other situations I'm sure that means hardening existing C. The majority of the government's security holes that need to be patched are coming from low quality unvetted imported technology, low quality self-written code, and code that should have been replaced 20 years ago. While it's exciting to think that this could mean a renaissance for the author's technology of choice, I just don't see it working out that way. If the government could write memory safe code, it would have. Rust isn't safe ENOUGH to save the government from itself alone.
> But the government doesn't want to replace everything with Rust.
To be clear, I don't think that they do. To be honest, I am mostly confused by your post, not because I disagree, but because I am unsure how you came to the conclusion that I believe these things.
Funny, because I came out with the almost opposite impression: that perhaps the legislators will require something stronger than even Rust to consider something "safe" because Rust still allows easy access to things like `unsafe` and FFI like most other languages - and true safety may require more than that.
I think our biases, together with the lack of a firm conclusion in this post, leaves the door open to vastly different interpretations.
Just like in every other kind of engineering, for software capability pulls the requirements.
The only reason everybody is complaining about lack of memory safety now is because there are alternatives for every use case. Before Rust existed, it was seen as an inevitable issue that one must work with, not as a problem to solve.
>Before Rust existed, it was seen as an inevitable issue that one must work with, not as a problem to solve.
There were many memory safe languages before Rust, Java and C# evangelized this a lot, though at that time the accent was on memory leaks not on safety. Rust offers an alternative for low level programming and might be faster in soem scenarios then managed languages.
My knowledge is probably outdated so I suggest to research this yourself, but mostly is about the maturity of JAva compilers that can perform advanced optimizations and the ability to optimize at runtime.
If you are interested into debating this with me and proving that Rust is the best I am not interested in a language war.
Just a small clarification here. The author isn’t just a fan of Rust. Steve was a member of the Rust Core Team for years and was co-author of the book “The Rust Programming Language,” which is the main recommended introductory text for the language.
I saw the authors credentials and I do respect them a lot. But to be fair, I'm sure the person who wrote the Go manual could have written the same blog post with the same outlook for the future only with Go in place of Rust. I'm trying to broaden the scope of conversation to a more holistic one, rather than just "this is our chance to take over the world!"
Like my Gotek USB emulator reference. The device costs $50, and it's pretty much the ONLY option you have for emulating a floppy drive with a USB stick in a bunch of obsolete hardware. The software that it comes with was written by a Chinese high school student in C++ during a study break and it is about as insecure and sketchy as you would expect it to be.
If you're the government looking to buy this, your choices are;
1. Buy this sketchy retroft device that is insecure and may be backdoored for a cost of $60.
2. Replace whatever needs the retrofit for a cost of $2m.
3. Write your own drivers for $100k.
Currently they just use the $60 device. The upcoming policy changes will take that option off the table for a lot of agencies, forcing them to make wiser purchasing decisions. It doesn't automatically mean Rust wins the day, or that rust deserves to win the day. It means intelligent conversations must be had and difficult decisions have to be made that used to get avoided.
Go has absolutely zero interesting properties here. It has a shitty, inexpressive type system, dangerous concurrency, brain-dead error handling. It is a managed language, which provided memory-safety for many many decades now.
The government buys technology from wherever, and until recently they never really cared where they got it from. If they need a USB Emulator, they buy the same Chinese Gotek from Ebay that you or I buy, and they get the same "Driver CD" full of buggy, broken English software, written by one person for $27 over the course of about 7 hours. Same thing with DVR systems, access controls, network appliances, access points. I've worked on government projects that were using 20 year old, broken, encryption libraries on active web servers. And when brought to their attention the people who use it don't care, and the people who are capable of doing something about it will never find out because it's too much work to replace and nobody wants to take that Zoom call.
I think the author is getting a little over-excited about Rust. Granted, they are a Rust developer. I'd love it if we could build everything in my favorite language. But the government doesn't want to replace everything with Rust. The government wants results. Period. It is the DOD, NSA, and CISA who need to become experts on how to realize those results. And they will probably release guidance that says "if you can't program securely in a memory unsafe language, don't use a memory unsafe language". The thing I think the author is missing is that nobody is going to mistaken "Made with RUST!" for "Impossible to cause undefined behavior!"
You can be a terrible programmer and still create undefined behavior, insecure code, data leaks, or any number of other problems in a memory safe language.
What the government is going to do is implement strict code import controls, similar to the export controls we already have. Purchasing departments will have to get software purchases signed off multiple times by qualified parties, and department leaders will have to prove that the technology they procure is adequately safe. In some situations I anticipate that means re-writing a bunch of code in Rust, and in other situations I'm sure that means hardening existing C. The majority of the government's security holes that need to be patched are coming from low quality unvetted imported technology, low quality self-written code, and code that should have been replaced 20 years ago. While it's exciting to think that this could mean a renaissance for the author's technology of choice, I just don't see it working out that way. If the government could write memory safe code, it would have. Rust isn't safe ENOUGH to save the government from itself alone.