Hacker News Reader

Comment by skyde | Hacker News Reader

Well when people say "Ada" they usually mean SPARK not old or feature limited version of Ada.

-Spark do verify contract using static analysis and proof. -While Ada is not as memory safe as Rust it's a lot more memory safe than popular languages. -Its one of the easiest languages to get compliance with safety standard DO-178C or DO-333 ...

View on HN

> Well when people say "Ada" they usually mean SPARK not old or feature limited version of Ada.

Having worked on several Ada projects professionally I can tell you that this is definitely not true.

DO-178C applies to the process and does not make assumptions about programming languages.

> -While Ada is not as memory safe as Rust it's a lot more memory safe than popular languages

Popular languages typically have garbage collectors and are memory safe. If a language is not memory safe, like Ada, then it's automatically one of the least memory safe languages, measured by amount of use.

> Popular languages typically have garbage collectors and are memory safe. I

Yes

And those languages are unsuitable for real time systems

Where Rust, and it seems Ada, excell

For hard real-time normal Rust (and I guess also Ada) is insufficient. This is such a niche of a sub-niche, that you no longer write the same language as for everything else, most OSs already preclude hard real-time by their very existence, etc.

Soft real-time is absolutely doable with a GC, depending on the required targets. Java’s low-lat GC (ZGC) has <1ms max pause times - you might not make the latest AAA game with it, but for the vast majority of popular games that is more than good enough.

Ada has inbuilt features allowing you to restrict yourself to a safe subset of the language for real-time computing.[0] It can be argued that this is not "normal" Ada since you are restricting the use of the entire language, but the restriction profile itself is a feature of the language.

[0]:https://learn.adacore.com/courses/Ada_For_The_Embedded_C_Dev...

> For hard real-time normal Rust (and I guess also Ada) is insufficient

Really? Expand on that please. I did not think so

> Soft real-time is absolutely doable with a GC

Some slippery definitions here. Clearly there is a middle ground (where I live) where rust works. GC languages do not

One GC pause, ever, is too many

You have 1ms pauses easily from simply the OS context-switching away from your program, so as I mentioned, unless you explicitly tune your OS, you have this kind of pauses, no matter the language, even if it’s hand-written assembly.

Regarding the non-normal language: with hard real-time you wouldn’t want to allocate willy-nilly and rust doesn’t yet have generics for allocators (correct me if I’m wrong on this, I am not up-to-date here), so careless usage of the standard lib, or other crates is a no-go. For illustrative purposes, this is the same with C++ and `noexcept`.

> Some slippery definitions here

I don’t see the slippery part - it is a slope, though. Depending on what’s the latency requirements and to what percentile should it happen, you can use Rust (and other low-level languages) on the lower end (audio processing), some managed languages in the middle (many kind of games are absolutely fine with that - a single drop of frame is more than fine, hence the soft rt), and pretty much any managed language on the high end.

>You have 1ms pauses easily from simply the OS context-switching

It is routine for Rust code to run without an OS (e.g., on microcontrollers).

A subset of Rust. You can’t just write ordinary Rust for microcontrollers.

It depends on what you call "ordinary Rust", I guess. You can use an allocator on embedded, but likely won't want to. There are static types that provide the same APIs as the allocating data structures you'd miss[1]. Granted, you're not gonna be able to take any random crate that isn't designed for such an environment, but that's a different problem, and there's a fledging ecosystem of no_std crates out there. Despite all those caveats, you can still write very high level code in embedded Rust, even async/await state machines![2]

1: https://docs.rust-embedded.org/book/collections/index.html

2: https://interrupt.memfault.com/blog/embedded-async-rust

Reply on news.ycombinator.com