DoD tried to do this in the 90s and failed. The CS program I was in used Ada for most of the lower division foundational courses because of the DoD mandate that all software developed for them be in Ada. DoD gave up in 2000 and said Ada was recommended because they got tired of processing waiver paperwork. My 1st 2 jobs Gov't contractor jobs '98-'99, 2001-2004 were in C/C++.
Would Ruby, Java, Go, and other gc’ed languages really be considered memory safe? I’d think you have to re-write the Ruby interpreter and the JVM in rust in order to achieve their stated goal here. Someone with deeper system’s knowledge please correct me if I’m wrong.
Rust isn't completely safe, it's just a lot safer than C.
And it's unsuited for many roles because it has eschewed reverse compatibility. Sure, you can write an operating system in Rust, but you'll have to re-write it (and possibly introduce new bugs) in five years or so.
I'm not the world's biggest C fan, but there are programs I wrote in the late 70s that still compile and do what you think they should do.
This is one of the good things about C. I could write something in C99 and, in 10 years, it will likely still compile without changes!
Can we say this about Java, C#, D.. and ESPECIALLY Rust??? You might still be able to download the specific version, but you then have to cater to package manageers, or the IDE/editor you are using, etc.
C does not try to cram in "Cool Feature A" and "Cool Feature B" because it is the cool thing of the time.
I think the only other languages to come close is Odin and, perhaps, Zig. Both have not had a production release (yet) so I am still expecting there to be some changes at this point. However, once mature, I would expect very little changes if left for 10 years. Of course - they are young languages but Odin (especially) makes it very clear what they will and won't add to the language, and keeps it pretty close to C in a number of ways.
> I could write something in C99 and, in 10 years, it will likely still compile without changes! Can we say this about Java, C#, D.. and ESPECIALLY Rust???
I think you could say this about Java. The others, I'm unsure about.
I would agree that Java, of all those I listed, is likely to be better supported. I do wonder if a Java version from 10 years ago would still be officially supported (or recommended) - and encouraged to use the later Java release... meaning (likely) code changes.
This is not entirely the case for C. I guess.. it depends.
If I use gcc (std=c99) for a project I wrote today... this will likely work in 10 years time, with the latest gcc version... without changes.
C# dev here, you can compile applications from any time period very easily as long as you have the correct .NET SDK version, which is specified in the .csproj file.
It's the same with Java, where to compile old applications you also need to use the same JDK version, however with Java it's a bit harder cause there is no file that says which JDK version should be used to compile this. At least I think so, correct me if I'm wrong.
> And it's unsuited for many roles because it has eschewed reverse compatibility. Sure, you can write an operating system in Rust, but you'll have to re-write it (and possibly introduce new bugs) in five years or so.
That's okay. Most rust devs get an erection at the idea of rewriting a massive codebase. For them the required rewrite every 5 years is a feature, not a bug.
Those languages have safe interfaces (the programming languages themselves) over a runtime that has to use unsafe code at some point (e.g. to write the garbage collector). If that's not memory safe, then Rust wouldn't be considered safe either, because its standard library is built on unsafe code with safe interfaces, too.
He's talking about the fact that many of these language and vm implementations are written in C and C++, and that C and C++ are supposedly to be avoided.
That is not relevant to the question of “is this a memory safe language or not.” The language used as the implementation language does not dictate the semantics of the language being implemented, which is the thing being discussed.