Hacker News Reader

Comment by trott | Hacker News Reader

> I just wonder why Ada didn't get the credit it deserved as being absolutely bulletproof

It's not. All languages make trade-offs in the performance-convenience-safety-etc space, and Ada's choice is not "100% safety". It lacks memory safety and has holes in its type system: https://www.enyo.de/fw/notes/ada-type-safety.html

View on HN

I wouldn't say Ada lacks memory safety. It doesn't go for 100%-in-all-cases but neither does Rust. The main differences are that it doesn't do memory safety by default (which is significant), and also treats memory safety with less granularity.

Aside from simply making manual memory management less frequent (with things like variably sized arrays), it has memory pools and subpools to handle more large-scale memory safety issues. Essentially you can define the scope for all allocations of a type.

It's an interesting tradeoff, though unfortunately I haven't seen much discussion about it.

I think it’s time we start expecting 100% memory safety as table stakes, because any flaws are catastrophic. Moore’s Law has more than paid for it; Android could run an animated display and a Bluetooth stack in a wristwatch seven years ago.

For many attempts, like Rust, I don't think the problem is related to Moore's Law at all. It's more a matter of dev time, effort, and expertise.

And even then, I don't think Rust's mechanisms even can be 100% as they are now.

Ada's pools are probably the one that is most related to Moore's Law and actually capable of 100%, or so I'd expect.

One area where I think Ada has the edge is providing language constructs that make bare metal programming safer. Concepts like 'dangling pointers' and 'memory leaks' aren't relevant in a programming environment without a heap. In bare-metal programming on a microcontroller you're more likely working within a flat memory model where the 'memory safety' provided by some modern programming languages is less relevant. Arguably, this is the context within which safety-critical programming is actually happening.

You can absolutely cause a pointer to dangle without heap allocation. Pointers can point to the stack too. You also have stuff like iterator invalidation, which is sort of a special case of a dangling pointer.

You're absolutely right. Pardon me. I should have written the more specific 'use-after-free'.

I do bare metal programming. I have a macro + linker widget called stack_allocated_ptr(x)

So I can write guards like

   if(stack_allocated_ptr(thingie))
   { 
     exit_critical_error( "oopies");
   }

You can write massive programs without a pointer in sight. If you have to import any C, then it's made a lot worse. You're better off doing memory mapped register type stuff in Ada.

Reply on news.ycombinator.com