Perhaps this should be amended as "Most newer programming languages are memory safe". Few languages invented before about 1980 are memory safe.

This probably depend on what we mean by "memory safety", but it is easy to get Null-pointer exception, and also data-races in languages like Java and Go, while Rust has static checks for those memory-related issues.

@Heinzi reference counting is (one form of) garbage collection...

@Jonas Checked null pointer exceptions are an example of memory safety, not memory unsafety! They’re similar to bounds checks in that respect. Memory safety is a pretty specific concept, and memory unsafety is characterized by the ability to, say, trash the stack or compromise aspects of the runtime. Java and Go are quite memory safe. They may guarantee fewer properties statically, but memory safety is a dynamic property, not a static one—memory safety is not the same as type safety.

Lisp is certainly memory-safe

Fortran is still widely used in numerical computing, and I don't think it's memory safe (but I'm not an expert and I could be wrong). But maybe that doesn't count as "common use".

@ChrisDodd Even older and traditionally unsafe programming languages have widely used frameworks today which are memory safe. A prominent example is Qt for C++. If you use Qt data structures instead of C-style allocation with pointers or the std library, then you are perfectly memory-safe even while programming in C++, one of the scariest languages for those who grew up with garbage collected languages from the very beginning.

@vsz that's not how it works and it's not that hard to trigger memory safety issues with Qt (because it's not hard to trigger them without using any library really). Frameworks can't make an inherently unsafe language safe (and it never was Qt's aim, it's just a cross-platform GUI with batteries included).

@mbrig re "ref counting * gc": That's a grey area. Usually saying a language is garbage collected implies it to have a garbage collector ;-). Simply writing a library type like a smart pointer is a little less than that.

@ChrisDodd Plenty of older languages simply didn't have assignable references at all, so it was trivial for them to be memory safe. Others were simply too low level for "memory allocation" to be a feature of the language or environment.

@MartinKealey -- low-level languages (like assembly) expose memory directly, which arguably makes memory safety an even bigger problem, albeit one that is so directly in the programmer's face that they can't ignore it.

@ChrisDodd As you say, assembler with no MMU puts memory management squarely in the programmer's bailiwick. The program gets an empty slate that it can use as it sees fit; there's no "malloc" or "free", and therefore no "use after free". Sure you can write an allocator within your program, but then that's not part of the "language", and it's entirely normal to write a program in assembly with no allocations whatsoever. (It's equally possible to write an allocator that uses an array inside a memory-safe language, and then "use after free" using your own allocator; memory safety doesn't fix that

@MartinKealey: there's a lot more to memory safety that just malloc and free -- there's addressing calculations for indexed data structures, there's stack (mis)use and stack smashing and stack overflows and dangling stack pointers. An MMU (or not) makes little difference here.

@AlexisKing Regarding "table stakes", that's only true if you have no intention of using your language to work with any kind of hardware. If you ever need to talk to hardware registers, by definition you cannot be memory safe, because the language itself can't save you. The language can have features which let you be safe, but it needs to let you be unsafe when you need to be.

"unlike precise, tracing garbage collectors, Rust’s ownership model does not guarantee that unreferenced memory will never leak)." ─ a caveat here is that most garbage collectors don't actually guarantee to collect all garbage. A program might finish running before the garbage collector even gets invoked, for example.

@Graham I don't see why it shouldn't be possible for a language to allow writing to specific hardware registers (which are not used by the program to store program state) while not allowing unsafe writing to general-purpose memory (which is). In the same way a memory-safe language can allow other kinds of I/O.

@DanM. Of course Qt does not prevent you from using malloc. That was not my point.

@kaya3 I'm sorry to be rude, but you've never done any embedded or low-level work. Memory-safe languages simply do not allow this - or if they do then (like C#) they give you the option to make it memory-unsafe. Languages are by definition processor-agnostic, and hence by definition cannot ever have any idea of what's a hardware register and what isn't. Hardware registers are used to hold state - otherwise how would you get the results of multiples and so on? And when you add DMA, everything in your concept goes sideways.

@Graham "Languages are by definition processor-agnostic" ─ By which definition? Is x86 assembly not a language, for example?

Please also note that I made no claim along the lines of "hardware registers are not used to store program state", only that there can be specific registers which a language can be designed not to use for program state, so that the language could allow writing to those registers without sacrificing memory safety.

Also, in general rather than apologising for being rude, it is better to not be rude.

@Graham I agree with @kaya3; I don’t think this is true at all. There’s nothing stopping you from using unsafe operations to access addresses while otherwise being a memory safe language. Just look at PEEK and POKE from BASICs, for example. “Memory safety” doesn’t mean that the language cannot ever have any unsafe operations, just that it has a well-defined safe subset that is clearly delineated from unsafe operations, and that safety is guaranteed unless explicitly opted out of.

It's true that memory safety is table stakes for nearly all kinds of programming. But not all kinds. There are multiple very important kinds of software that absolutely cannot use a GC, and Rust is not an ideal match for all of them... And so, they have no choice but to use non-memory safe languages.

And that's a bit sad. I wish there would be more innovation in non-memory-safe languages, just so that these kinds of software could finally be written in something safer than C/C++.