Rust certainly was not the first "systems programming" language that was memory safe, ADA was aiming for the same title and I think achieved it way before Rust.
While Ada is a great and sadly underused language, if my memory serves, it's not out-of-the-box memory-safe by today's definitions. I seem to recall that it takes Spark to make it memory-safe.
SPARK is practically just a restricted version of Ada with a few added features for formal verification. You can write a program primarily in SPARK but disable said restrictions based on circumstance by setting the `SPARK_Mode` pragma/aspect to `off` on a package, procedure, function, etc. Mixing Ada and SPARK is trivial.
I guess it is similar to Rust code that uses `unsafe {}` as the other poster mentioned (maybe `unsafe fn` for a closer analogy). My knowledge of Ada/SPARK is much greater than what I know about Rust, so I might be guessing wrong.
So in Rust an unsafe block and an unsafe function mean two different things. An unsafe block allows you to do things that are unsafe, such as dereference raw pointers, access union fields, calling unsafe functions, etc.
Unsafe functions mark that the caller is responsible for upholding the invariants necessary to avoid UB. In the 2021 and earlier editions, they also implicitly created an unsafe block in the body, but don't in 2024.
Or, in a more pithy tone: an unsafe block is the "hold my beer" block, while an unsafe function is a "put down your beer" function.
What are todoay's definitions? If Ada simply had more thorough rules but introduced an "unsafe {}" construct, then what would the practical difference actually be? Compiler defaults?
I disagree. SPARK is all about using formal methods to statically prove software properties. Clippy seems more comparable to parts of AdaCore's other static analysis toolset (gnatsas). See https://docs.adacore.com/live/wave/gnatsas/html/user_guide/f...
That depends on your definition of systems programming. Go and java are not fit for low level OS or embedded development. They are too memory hungry. A lot of software runs on hardware other than servers. iot, auto, tvs, phones, watches, etc all have much tighter requirements on acceptable software overhead from languages employed. Also, the more memory and CPU you use in systems layers, the less that is available for higher level layers, which are often written in higher level languages and desire the majority of the devices resources.
There are entire kernels and userlands written in go that are used in production today, in rather constrained environments no less. Technically sim cards run a kind of Java derivative too. I dislike both languages but that doesn’t mean they can’t be used to build foundational systems.
I'm aware of java being used for embedded, but that wasn't really proper java and it requires specialized hardware. You can't just expect to run java on an arm microcontroller and expect it to work out. I'm curious to learn more about production quality golang kernels. I've never heard about this before. Personally, if a language doesn't give you the flexibility required to run it on microcontroller grade hardware, I find it difficult to ascribe it systems programming language status. Anything with a large runtime makes that difficult without some sort of hardware assistance to offload the runtime (eg javacard).
PTC and Aicas JVMs and AOT compilers are proper Java, there is nothing on the standard regarding what kind of GC or real time constraints are required.
Additionally, real time Java is an industry standard.
Sure, those languages are not suited for all systems programming tasks. Just like application programming languages are typically not suited for every kind of application, or database management systems are not suitable for any kind of database. But there isn't a big disagreement about terminology in the field I think. And of course Go was launched specifically as a systems programming language.
