16
$\begingroup$

One of the most known ones is Rust, but what others implement this?

$\endgroup$
3
  • 10
    $\begingroup$ Almost all of them. It's much easier to ask the inverse question of "which programming languages aren't memory safe?". Rust makes a big deal about it not because it's rare, but because it's rare in the kinds of software Rust is aiming at being used for. $\endgroup$ Commented Oct 11, 2024 at 15:50
  • 1
    $\begingroup$ Depending on your use case, it may be important to distinguish between dynamic memory safety and static memory safety. $\endgroup$ Commented Oct 11, 2024 at 22:03
  • $\begingroup$ I would say Rust makes a big deal of it because it achieves it without being interpreted, with garbage collection, and without a VM. But it's true that many don't really understand that part. $\endgroup$ Commented Jan 12 at 15:26

3 Answers 3

Reset to default
60
$\begingroup$

Most programming languages are memory safe!

Memory safety is not a particularly unusual property for a programming language to have. The large majority of programming languages currently in common use are memory safe (ignoring explicitly unsafe features or operations). However, what most of those languages have in common is that they are garbage collected: if the programming language manages memory on behalf of the programmer, it is much easier to prevent certain types of memory safety violations that are otherwise easy to express when memory is managed manually, such as use-after-free.

The primary innovation of Rust is not that it is memory safe per se, but that it is memory safe despite not being garbage collected. Instead of having a centralized runtime that owns all memory, Rust’s borrow checker tracks memory ownership statically, and this static analysis determines precisely when memory may be shared and when it may be freed (though note that it does not always determine when it should be freed: unlike precise, tracing garbage collectors, Rust’s ownership model does not guarantee that unreferenced memory will never leak).

It would be much easier to list the set of memory-unsafe languages in common use than the memory-safe ones, since that list is arguably limited to C, C++, and not much else. Zig is an exceptionally rare example of a new language that is explicitly not aiming to be memory safe. Usually, memory safety is considered table stakes for any new programming language.

$\endgroup$
4
  • 9
    $\begingroup$ Perhaps this should be amended as "Most newer programming languages are memory safe". Few languages invented before about 1980 are memory safe. $\endgroup$ Commented Oct 10, 2024 at 20:40
  • 12
    $\begingroup$ 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". $\endgroup$ Commented Oct 11, 2024 at 7:41
  • $\begingroup$ Comments have been moved to chat; please do not continue the discussion here. Before posting a comment below this one, please review the purposes of comments. Comments that do not request clarification or suggest improvements usually belong as an answer, on Programming Language Design and Implementation Meta, or in Programming Language Design and Implementation Chat. Comments continuing discussion may be removed. $\endgroup$ Commented Oct 12, 2024 at 20:56
  • $\begingroup$ This answer wold be improved by mentioning that the presence of a Garbage Collector does not necessarily make a language implementation memory safe, using Go and its infamous racy fat pointers as an example of unsafe implementation despite a GC. $\endgroup$ Commented Oct 27, 2024 at 15:36
-4
$\begingroup$

Interestingly — and this is probably a controversial thing to say 2 — modern C++, when used idiomatically, is memory safe as well.1 There is no need to use raw pointers any longer, smart pointers prevent dangling references as well as memory leaks, range-based loops prevent out-of-bounds access, containers expand as needed etc.

1 This development is, of course, the response to the un-safety of C and early (which means the first 25 years or so, 1985-2011 ;-) ) C++ style memory management.

2 Indeed: The number of up- and downvotes are perfectly balanced! :-)

$\endgroup$
21
  • 16
    $\begingroup$ I don't think you can describe a language as memory-safe when it's opt-in safety. Yes, you can write C++ with no use of new/delete. And only using .at() rather than [] for accessing std::vector and the like. And quickly wrapping all those unsafe pointers you'll end up with from various sources (e.g. the actual command line arguments) in something safer. C++ has added lots of memory-safety stuff to their standard library, but the language is intrinsically memory-unsafe. You don't get to call yourself memory safe unless said safety is either absolute, or at least opt-out, not opt-in. $\endgroup$ Commented Oct 11, 2024 at 15:44
  • 17
    $\begingroup$ The important part of memory safety is the guarantee. Using a fully memory-safe language is in itself a proof that any program will be safe. In contrast, with "C++ used correctly", there is no easy way to be sure that a given program will really have been written 100% correctly. This is what makes C++ not memory safe. $\endgroup$ Commented Oct 11, 2024 at 17:08
  • 10
    $\begingroup$ @Peter-ReinstateMonica It is simply not comparable. In most languages, those “unsafe features” require lots of scary incantations that no normal user would ever even accidentally stumble into, and in many cases they even support features for disabling their use. What you are saying is that it is possible to write C++ code that does not trigger memory unsafety, but C++ is not a memory safe language, and no serious PL person would accept that it is. There is a gulf of a difference here. $\endgroup$ Commented Oct 11, 2024 at 20:45
  • 8
    $\begingroup$ Many of the neighsayers here seem to wilfully overlook the key phrase of the first sentence: when used idiomatically, or dismiss it out of hand. Sure, idiomacity is hard to be sure of without tooling to warn you, and there a few holes where it doesn't hold 100%, but "idiomatic C++" could be 100% safe if we choose the right idioms. Debating the selection of idioms would be much more useful than simply shouting down a straw-man by ignoring the prerequisite of the initial assertion.. $\endgroup$ Commented Oct 12, 2024 at 3:21
  • 13
    $\begingroup$ When someone writes a compiler for "C++ used correctly" which rejects programs which are not valid "C++ used correctly", then I will accept "C++ used correctly" as a programming language. Once a comparable number of people use that compiler, I will even accept it as a mainstream programming language. But "trust us, we know how to use the tool safely, so therefore the tool is safe" is not a convincing argument. $\endgroup$ Commented Oct 12, 2024 at 13:10
-14
$\begingroup$

C is a memory-safe language because it allows the programmer full and precise control over memory management. Provided that the programmer makes no mistakes, there can be no uncertainty about memory ownership and no risk of buffer overflows.

To guarantee safety the programmer can use the safe subset of C, avoiding unsafe features such as pointers and arrays.

$\endgroup$
6
  • 5
    $\begingroup$ Your argument makes no sense - memory-safe language doesn't allow a programmer to make these kinds of mistakes. And C without pointers or arrays isn't a usable language. How do you write hello world? A dozen putc calls? $\endgroup$ Commented Oct 12, 2024 at 11:32
  • 9
    $\begingroup$ All knives are blunt, provided you press your finger against the handle rather than the blade. $\endgroup$ Commented Oct 12, 2024 at 13:18
  • 3
    $\begingroup$ Taken to the extreme, machine code would be a safe language, too, because it offers even more control, right? After all, you never know what your malloc() is doing! :-). More seriously, the question asked for language support, which C offers only minimally. (C++, which I made a case for in my answer, by contrast does support memory safety, e.g. through smart pointers and range based loops.) $\endgroup$ Commented Oct 12, 2024 at 15:08
  • 4
    $\begingroup$ "Provided that the programmer makes no mistakes, there can be no uncertainty about memory ownership and no risk of buffer overflows." Doesn’t that apply to just about any language? A language would have to deliberately mess with memory to not qualify for this. $\endgroup$ Commented Oct 12, 2024 at 17:19
  • $\begingroup$ C is memory safe only if used by memory safe programmer :) $\endgroup$ Commented Oct 14, 2024 at 21:11

You must log in to answer this question.