Their "Appendix: Memory Safe Languages" lists: C#, Go, Java, Python, Rust & Swift
>Java
Java it's a pest fest for exploits.
From those, I'd choose Go, C# (and not totally sure because of AOT/JIT's) and Rust.
The Case for Memory Safe Roadmaps
111–120 of 427 posts
Re: The Case for Memory Safe Roadmaps
#112Isn't C++ with RAII reasonably safe? I tried to learn/like Rust but it's against how I use to think. If no friendlier safe high speed programming language appears, I rather use C/C++ and trade safety for friendliness.
If you have no users then go for it. However if you do then you are doing those users a disservice by exposing them to unnecessary risk. Maybe the risk is mitigated in other ways. Your software runs as a cli and not a service. It doesn't process outside input. It is run in an ironclad sandbox. But honestly, if you think the way C++ with RAII want's you to then you should already be following the rules that Rust want'…
so what you’re saying is proper C++ is fine?
Re: The Case for Memory Safe Roadmaps
#113Earlier quoted context omitted.
Next thing they'll be giving requirements for people building bridges, houses, and gas and electricity fittings. Seriously, I think the time has long since passed software needs regulating. It's a major part of modern society, and as far as I'm aware, most people aren't opposed to building standards in principle.
People figured out how to build buildings prior to creating building codes
https://en.wikipedia.org/wiki/Great_Fire_of_London
Building a building without regulation is easy. Building a city that doesn't burn to the ground every time someone knocks over an oil lamp is not.
Re: The Case for Memory Safe Roadmaps
#114Isn't C++ with RAII reasonably safe? I tried to learn/like Rust but it's against how I use to think. If no friendlier safe high speed programming language appears, I rather use C/C++ and trade safety for friendliness.
RAII is great (especially as a developer’s aid), but I don’t think it’s had a huge effect on memory unsafety: it’s still very easy to UAF in a RAII-only codebase, thanks to all of the flexibility C++ allows in constructors and destructors (and unintuitive behavior in moved-out-of objects).
Rust is generally perceived as having many of the same developer kindnesses as C++, while having same-class performance. Learning it has a bit of a curve, but I found that it eventually clicked (I have a C and C++ professional background).
Re: The Case for Memory Safe Roadmaps
#115Earlier quoted context omitted.
>Really, the only memory unsafe languages still in use are C and C++. Ada, Fortran, assembly?
Isn't Ada memory-safe?
the internet says "it tries to be".
http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-13-9-1....
https://old.reddit.com/r/ada/comments/mme3jk/is_ada_memory_s...
Re: The Case for Memory Safe Roadmaps
#116Confused about Python in particular considering a lot of powerful and common dependencies in the ecosystem starting out from numpy and friends all have C/++ components to them for performance improvements. Surely this is a vector to be considered?
Python itself is memory-safe, but you're right that a good chunk of the packaging ecosystem uses memory unsafe languages for performance and interop.
The Python Software Foundation noted this in our response to the US Government RFI on open source security. There are efforts to make using Rust easier as a systems language for Python packages and some security-critical packages like 'cryptography' have migrated to Rust.
Re: The Case for Memory Safe Roadmaps
#117Their "Appendix: Memory Safe Languages" lists: C#, Go, Java, Python, Rust & Swift
Will we one day be able to use AI to make code memory safe?
Re: The Case for Memory Safe Roadmaps
#118I advise training programmers instead of throwing them in front of a screen without any training. Companies these days provides no training at all. When I was hired over 40 years ago, I spent plenty of time being trained for my first 3 months. Now, nothing, and you if you want to train a new person, you do it on your own time.
Why train when they just leave the company in a year for 10%+ more money.
Obligatory: "what if they stay?"
Re: The Case for Memory Safe Roadmaps
#119But how are we going to trade stocks in nano seconds without C++?!
High speed fiance is mostly done in Java and Haskell, because mistakes are expensive. (And yeah, it's one of the very few fields that Haskell enters the list.)
Re: The Case for Memory Safe Roadmaps
#120"Undefined behavior" in general is a nightmare. After memory safety, the next target should be the enforcement of underflow/overflow trapping. With the exception of the intentional use to implement modular arithmetic, underflow/overflow should always be an error condition.
The main problem with signed overflow being UB is that it's an opportunity for compilers to blatantly do adversarial language lawyering against the programmer in order to enable optimisations. When it comes to unsigneds, there's no such problem (and this is in fact the real reason why anything that can be unsigned in C/C++ should be unsigned).
Yeah. Back when machine architectures were churning so fast that compiler flexibility allowed portability that otherwise wouldn't have happened, UB freedom was a net good. Now that those arbitrary architecture choices have stabilized, the good is no more, and the evil of optimization rules lawyering has replaced it. UB needs to go.