Hacker News Reader

Comment by peppermint_gum | Hacker News Reader

I noticed that many people praising Ada on the internet don't actually know the language.

It's odd. Why advocate for a language you don't use?

Here are some common giveaways:

- "Ada has a garbage collector" - It's optional part of the specification, in practice most compilers don't implement it.

- Confusing SPARK (the formal verifier) with Ada, or even claiming that SPARK is now part of the Ada spec. This is simply not true.

- Not knowing that contracts are enforced at runtime and they're typically disabled in release builds.

- Claiming that Ada is memory safe. Ada doesn't have a borrow checker. Ada doesn't have smart pointers out of the box (unique_ptr is actually unimplementable due to lack of move semantics). Typical non-embedded codebase is full of "new" and "Unchecked_Deallocation", usually wrapped with controlled types, much like C++ RAII.

View on HN

>>Ada doesn't have smart pointers out of the box

I am a novice-intermediate Ada user (and I started with SPARK before moving to just Ada), but a lot of the arguments in favor of Rust mention that "there is a crate for that". I would say you need to compare vanilla Rust "out-of-the-box" with Ada for a fair comparison.

Another reason I prefer Ada is because I find it boringly simple like Pascal even though it is verbose, whereas I find Rust very obtuse, and I have a personal bias for array languages and ML languages. I wish Rust were more F#-like.

> but a lot of the arguments in favor of Rust mention that "there is a crate for that". I would say you need to compare vanilla Rust "out-of-the-box" with Ada for a fair comparison.

Smart pointers are vanilla rust shrug.

But also, it's pretty fair to mention the availability of crates, because they're easy to integrate, liberally used by the project itself (go browse https://github.com/rust-lang and you'll see a number of projects for libraries distributed as crates rather than part of the stdlib), and there's a large breadth of available packages.

The internet tells me Alire is a (the?) package manager for Ada, its listing has 373 entries right now (https://alire.ada.dev/crates.html).

Simple odds say you're more likely to find a crate for that than an ada package.

> But also, it's pretty fair to mention the availability of crates, because they're easy to integrate, liberally used by the project itself

Yes

This is a strength and a weakness in Rust

The crate ecosystem is broad an deep. It is seemless to integrate crates if you are connected to the internet. That is a strength

But it is also a weaknesses. "seemless to integrate crates if you are connected to the internet" but of unknown provenance and varying quality.

There are steps you can take, tools you can use to ameliorate the issue, but it is a real danger

It depends what you are working on. For systems which must be secure and reliable -weapons, flight control, banking, maybe Ada is a better choice

For me I make musical instruments, and I will stick with Rust for that

I know Rust, not Ada. A very interesting discussion for me to

For the case of "smart pointers", and the larger point of "safety": rust has that included out of the box: Box, Rc, Arc, RefCell are all smart pointers included in the standard library. On safety of the language: the borrow checker exists, move semantics are the default (ie: included in the language) and copy is explicit, and real programs that isolate unsafety effectively (ie: so it doesn't need to be known outside of the module it exists in) are common.

Basically unique_ptr is the default in Rust. I also like to say that Rust is “just” the compile-time enforcement of C++’s smart pointers, which is technically not 100% correct, but gives a good mental image for the uninitiated, I guess.

edit: actually not RefCell. That's more Mutex like. Which is another place rust solves: the tooling for eliminating data races at compile time is mature and pretty complete. The race elimination in Ada appears to rely on using SPARK (as noted elsewhere: not universally used from others experiences), but I'm not too familiar, possible I'm wrong there.

>I noticed that many people praising Ada on the internet

Not seen that anywhere, on Reddit or HN. I mean Ada is rarely even mentioned. On HN, Ada sometimes is hated by many. And this is speaking as someone who gets all the fingers for bringing up Ada whenever someone said Rust is the only PL for safety critical applications.

I am actually rather surprised this Submission gets some many people commenting.

And to be honest I think most of those point aren't because they dont know the language, it seems to be more like lacking in context. ( Which is often the case in any online discussions )

Your last point is the largest thing I noticed in the one large codebase I looked at. Ada with a borrowchecker and linear types (aka austral) would be great. Rooting for austral, though I actually prefer obtuse dense syntax to verbose simple syntax. Not sure why. I think I may have a mental cache size related to the number of characters on a screen vs the number of tokens.

I figure the preference in syntax is a trade-off between how hard it is to learn and how hard it is to read day-to-day.

More regular and verbose syntax is easier to learn, but requires more actual reading when you use it.

More concise but complex syntax takes longer to internalize, but then you can see more at a glance, so it lets you do more visual pattern matching and puts less strain on working memory.

More about Ada and SPARK:

https://docs.adacore.com/spark2014-docs/html/ug/en/usage_sce...

For example: "SPARK builds on the strengths of Ada to provide even more guarantees statically rather than dynamically."

---

For people who want to read more about pointers in Ada:

https://www.adaic.org/resources/add_content/docs/craft/html/...

http://archive.adaic.com/tools/CKWG/Reference_Counting_Point...

https://learn.adacore.com/courses/intro-to-ada/chapters/acce...

https://www.adacore.com/uploads_gems/03_safe_secure_ada_2005...

https://blog.adacore.com/using-pointers-in-spark

---

Memory safety in Ada / SPARK:

https://www.adacore.com/uploads/techPapers/Safe-Dynamic-Memo...

C++03 had no move semantics either, it got added in a later version of the standard. Controlled types/RAII is also the basic building blocks of smart pointers, and it's quite normal that they be implemented with unsafe code under the hood.

A garbage collector was also part of C++ spec from C++11 to C++23.

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 ...

> 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