How does Ada's memory safety compare against Rust?

> At this point I can't see us going back to the way things were. I can't imagine any new systems programming languages gaining traction that aren't at least as safe as Rust.

I see Rust being used in many context where it's safety features aren't really needed or even a hindrance like game dev.

Honestly the safety is overstated in importance. The amazing tooling, decent package manager, great error messages, the inclusive community, the type system that took the low hanging fruits from the academic functional programming world, are much more relevant for its success.

The problem with Rust is that it made using languages without automatic garbage collection acceptable again and I am not sure if this is good. The borrow checker is a neat solution and might be a good fit for certain niches but automatic garbage collection is just vastly more ergonomic to use.

We had Lisp Machines, we need to go back to future.

> I can't imagine any new systems programming languages gaining traction that aren't at least as safe as Rust.

I don't think safety is a 1 dimensional spectrum (say from 0% to 100%). I view it more as a multidimensional thing, and tradeoffs between these dimensions.

Rust invested a lot on _some dimension_ of safety, which is essentially static borrowing and aliasing. And the tradeoffs for this are numerous: Dynamic safety is either much harder in Rust (due to unsafe being vastly more dangerous and hard to get right vs say, a C program), or at the expense of performance (I.e. just Arc<Mutex<>> or copy everything). That also comes at the expense of an immense cognitive burden for the programmer.

I see a lot of space for different tradeoffs on different dimensions of safety.

That comment was great. It's so hard for me (raised on Windows and now immersed in Linux) to imagine something so foreign to the OS paradigms I'm used to. It just goes to show how much the things you are used to can limit your thinking.

> The history of computing has many examples of products and languages winning out over technically superior alternatives for non-technical reasons.

Unfortunately, the history shows that such technically inferior languages and products winning out are also because of outright market manipulation by their corporate backers, tons of money in ads, or attacks on competitors. The elephant in the room, is to look at what's generating or paying for the hype and marketing behind recent programming languages like Rust and Zig (for example).

> I think that the massive groundswell of interest around Rust...

A review of the groundswell, around Rust or Zig, is its not attributable to just grassroots or genuine interest, and can significantly be the result of outright astroturfing and artificial brigading. Sadly, many people follow along with the marketing or are bombarded into submission, "must rewrite in X" or "GC all bad and manual all good" foolishness, versus actual use case and legitimate examination of language tradeoffs.

> At this point I can't see us going back to the way things were. I can't imagine any new systems programming languages gaining traction that aren't at least as safe as Rust.

Zig seems to be gaining traction. Hard to predict whether it will succeed or slowly fizzle out after the initial excitement phase though.

> The history of computing has many examples of products and languages winning out over technically superior alternatives for non-technical reasons.

While this is undoubtedly true, i suspect that there are also many cases where people presume the reasons are non-technical but when examined closly turn out to have hidden technical issues.

I can't imagine any new systems programming languages gaining traction that aren't at least as safe as Rust.

Am I allowed to sigh here? It's a good thought, but this is humanity we're talking about here.

All it requires is some big-project, some big-corp creating some essential ecosystem with lame-language-A, and now it's got traction.

And frankly, look at rust and its weird crates. Weird as in "Let's make a super-safe language, then import random stuff from unknowns, unaudited, and just hope it all works out."

If rust was really serious about security, only signed crates from validated developers, with code review would be the norm. Oh but wait, that'd be "not easy".

ADA is really great. You can use it to safely blow rockets up in the air.

> ...'let memory leak and let the OS sort it out'..

I wouldn't be surprise to hear this from C or C++ folks, never heard this in Ada circles, there is always that missile meme going around, and I happened in the past to occasionally drop into FOSDEM Ada's rooms.

Speaking of which,

"Memory Management with Ada 2012 from FOSDEM 2016"

https://archive.fosdem.org/2016/schedule/event/ada_memory/

> Also, if I'd have written 'You can't leak memory in Ada if you stick to using collections', wouldn't that just be like saying 'You can't leak memory in C++ if you stick to using the STL'? The point of the article was to show what Ada and Rust do to outrightly prevent you from shooting yourself in the foot, at the core language level.

A programming language is seldom used without its standard library, I don't care what a plain grammar + related semantics check offer, if there is nothing on the standard library, IDE tooling, libraries to chose from.

Otherwise than you should also do a comparisasion using no_std against Ravenscar profile.

And yes, unless you are using a C++ compiler that offers the option to harden its standard library, you are going to some surprises, starting by having to use at() instead of operator[]() for bounds checking, and even with hardened one, stuff like use-after-free/move only when using a good IDE like VC++/Clion or static/dynamic analysis tooling.

To complete what you write, the people in the room during the design of Rust were all very much aware of memory-safe languages. Rust was largely designed by putting C++ developers (who were tired of undefined behaviors) and ML developers (who were aware that ML was not great at system programming) in the same room and have them negotiate a language together, in the hope of producing something that would convince C++ developers to migrate to something less risky.

I kinda vaguely remember Erlang being mentioned, but I don't recall Ada being discussed. To be fair, I didn't attend many of these conversations.

I'd agree it's largely the human factor, but maybe from a different angle. Rust has got the "there's a crate for that" factor, like JavaScript, which helps onboard people who are afraid of getting stuck writing everything from scratch.

For example, serde (and serde_json, toml, etc.) is a gamechanger, as is tracing, reqwest, and many others.

So, maybe less about the language itself for many people, but more about the human factor of overcoming fear of being stuck on an island

I clearly remember sighing deeply back in 2002 realizing I have to introduce yet another array type so my code could compile in Object Pascal. And this is just one example of many.

Rust is objectively better than what I tried before, in several ways.

From where I was standing several years ago, there was almost zero "human factor" in adopting Rust for many companies (and devs). People simply saw the better features, performance and security and got excited and wanted to work with that language. And then many mistook that for hype. Yourself included apparently?

Sometimes things get popular just because they are good, you know. Not super often historically, mind you, but it does happen. IME Rust is one of these outliers.

The human factor doesn't just come out of nowhere.

I'm not sure what point you're trying to make. Do you think Object Pascal is as good as Rust?

In rust dynamic allocations usually just end up with runtime asserts from your ref counting gc implementation though.

> Rust is the first (yes, first) mainstream language that offered reasonable and composable memory safety, without compromising on speed.

Is that true, though? Many memory-safe languages are very fast (fast enough for the vast majority of use-cases). Feels like mostly they compromise on memory, don't they?

Rust seems to be a good replacement for those use-cases where C++ is needed. But given the popularity of Rust, it seems to me that many people use Rust where they don't actually need it.

(Disclaimer: I do like Rust)

Maybe for those that have to use Rust. But borrow checker was sole reason why I wanted to learn Rust. And at that time (~2018) it was also reason why people were recommending it.

And people like C in spite of the segfaults. It's the same disliked thing, Rust just moves it to compile time instead of production. Which many people prefer, since it avoids security issues, data loss, and mysterious crashes.

> a mistake of the 1983 Ada standard ... which has been removed

The article was written in 2011, and the trick still seems to work in a 2024 version of GNAT.

> Both "unchecked" Ada and "unsafe" Rust

But the `Conversion` function isn't using `Unchecked_*`. That's the point of the article. The type safety hole is in "safe" Ada.

I've never done it myself, but I know it's possible! The GetIntoGameDev Youtube channel has recently done a few videos on the subject[0].

0: https://www.youtube.com/watch?v=HZSvlaQ2uHI

I think there's a roguelike on steam maybe that is written in Ada.

Well godbolt doesn't think so.. 1) this example has an aliasing, no compiler error. https://godbolt.org/z/hzWfj37ef

2) The output value depends of the size of IntArray!

>> with Ada.Text_IO; use Ada.Text_IO; with Ada.Integer_Text_IO; use Ada.Integer_Text_IO;

procedure Text is type IntArray is array (1 .. 500) of Integer;

   type MyStruct is record
      Value : Integer;
       A : IntArray := (others => 0);
   end record;

   function Compute (Value1 : MyStruct; Value2 : in out MyStruct) return Integer is
   begin
      Put_Line ("1 value1=" & Integer'Image(Value1.Value) & " value2=" & Integer'Image(Value2.Value));
      Value2.Value := Value2.Value - 1;
      Put_Line ("2 value1=" & Integer'Image(Value1.Value) & " value2=" & Integer'Image(Value2.Value));
      return Value1.Value * 2;
   end Compute;

   Value1 : MyStruct := (Value => 10, A => (others => 0));
   Value2 : MyStruct := (Value => 20, A => (others => 0));
   Result1 : Integer;
   Result2 : Integer;

I think you’ve skipped important words that I’ve said:

> Rust has *almost* no competitors when it comes to the very robust safety guarantees it makes and *none when you combine with the performance niche it services*.

The almost is doing important work in that statement and the none is referring to systems programming. As another commenter noted, SPARK is more than just a cost thing - it fails to scale to non trivial sized projects.

I’m not saying there’s nothing to learn from Ada. All I’m saying is that Rust offers significantly stronger protection and memory safety out of the box than Ada and no language has managed to deliver such memory safety with the performance profile of C and able to target all the same variety of use cases in terms of systems programming (but then also scaling to web services which C/C++ can’t really reach unless you like trivial memory exploits)

> I have not noticed yet anything innovative in this aspect of Rust.

Innovation often times can be subtle like packaging up existing ideas in a friendlier package that can get more mass adoption. If you fail to see the innovation Rust has done with the borrow checker (which afaik is truly novel) and then making the entire language be able to scale from embedded to web services in a cohesive way and also making it a legitimate replacement to C++ in ways that other languages have tried and failed, I think you’ve been too dismissive.

AIUI, SPARK does not use a Rust-like borrow checker: it's based on formal verification which is a lot more difficult to program for, i.e. not really feasible except for smaller programs. This seems to be in sharp contrast to Rust - the safe subset of Rust enforces a set of rules that can actually scale up to larger programs while still preserving safety.