Live data from Hacker News

Ada: a C Developer's Perspective

methodsandtools.com

141–150 of 157 posts

Re: Ada: a C Developer's Perspective

#141

Earlier quoted context omitted.

This idea that Rust and Ada are somehow alternatives continually pops up, and I still don't understand it. They each have their own ideas on what "safety" is, and how to address it. I'll admit I'm biased towards Ada, but I think it is pretty safe to say that "Rust safety" is a subset of "Ada safety" - but Rust does it's section and run further with it than Ada. Rust is obsessed with memory safety. That's it's thing.…

I don't really understand the "Rust is obsessed with memory safety" meme. When pitching Rust to others of course memory safety and thread safety get hyped a lot; because it's talking about something that most languages just can't do -- safety without compromise. But actually ... memory safety is a small part of the reasons why I like Rust, and there are plenty of other cool bits in the language. It stands out a bit b…

When things such as the borrow checker are so heavily built in to the language, I find it hard to to see how Rust isn't ultimately intended to do memory safety. Obviously it does other things, and I'm sure it has some cool ideas in there. But I have a hard time seeing how it's a mischaracterization of Rust to say that memory safety is kind of it's thing.

Re: Ada: a C Developer's Perspective

#142
post #93

Earlier quoted context omitted.

I don't really understand the "Rust is obsessed with memory safety" meme. When pitching Rust to others of course memory safety and thread safety get hyped a lot; because it's talking about something that most languages just can't do -- safety without compromise. But actually ... memory safety is a small part of the reasons why I like Rust, and there are plenty of other cool bits in the language. It stands out a bit b…

I don't understand why the public marketing effort is so focused on safety, either, but it is. When I see Rust mentioned, e.g. here at HN, I cringe a little because odds are it's in the context of how unsafe everything else is, or there is at least some connection made to safety. "Obsession" seems loaded. Rust is a very nice language with many useful and interesting features which may exist because of the developers'…

Again here the word "safety" starts to get rather muddy. What Rust calls safe is not what Ada calls safe. I'd rather be specific about what we're talking about.

Memory safety is not, itself, program correctness. It's just one way programs can go wrong.

Re: Ada: a C Developer's Perspective

#143
post #40

Earlier quoted context omitted.

This idea that Rust and Ada are somehow alternatives continually pops up, and I still don't understand it. They each have their own ideas on what "safety" is, and how to address it. I'll admit I'm biased towards Ada, but I think it is pretty safe to say that "Rust safety" is a subset of "Ada safety" - but Rust does it's section and run further with it than Ada. Rust is obsessed with memory safety. That's it's thing.…

What kind of semantics cannot be well expressed with Rust type systems, compared to Ada? The type system is algebraic, and pretty powerful.

As as been mentioned, integer bounds for one. Using aspects in Ada will also let you provide other assurances (at compile time or runtime, depending).

Additionally, the "newtype" in Ada is far easier to work with. The new type inherits the operations of the parent type. When it comes to this sort of thing, it needs to be as simple and easy as possible or it just doesn't get done consistently.

Re: Ada: a C Developer's Perspective

#144
post #37

Earlier quoted context omitted.

Ada is so stable and backwards compatible that old libraries will work just fine, unless they have external dependencies or depend on things that change fast in the outside world. For me personally Rust is not a good Ada replacement, because 1) it has the usual obscure syntax - maybe to attract C++ programmers, who seem to like obscurity -, 2.) many semantic tricks and borrower idiosyncrasies that makes it harder to…

If you start a project today that depends on a library that was last updated in 2002, then may God help you.

Welcome to VB6.

Re: Ada: a C Developer's Perspective

#145

Earlier quoted context omitted.

This idea that Rust and Ada are somehow alternatives continually pops up, and I still don't understand it. They each have their own ideas on what "safety" is, and how to address it. I'll admit I'm biased towards Ada, but I think it is pretty safe to say that "Rust safety" is a subset of "Ada safety" - but Rust does it's section and run further with it than Ada. Rust is obsessed with memory safety. That's it's thing.…

How does Ada address the problems that Rust's borrow checker addresses? Use-after-free in particular. As for not being alternatives, how do they mix in the same project? Does Ada have C-compatible FFI that lets both Ada and Rust see each other as C?

Ada addresses memory issues in a couple ways. In a general sense, the language is designed to prevent the need for explicit allocations and pointers as much as possible. The runtime uses a secondary stack to return dynamically-sized objects from functions. The low level parameter passing details are also compiler-controlled. The programmer specifies how an argument is used (input, output, or both) and the compiler deals with how to accomplish that. There are some other features (mostly related to types and bounds) that all combine to generally reduce the need for explicit memory management.

Once you do get to explicit memory management, Ada does a number of things. I'm going to a list here just for my own sanity.

First, all deallocations are essentially marked unsafe. You use Unchecked_Deallocation() to free memory.

More importantly, it provides memory pools, and subpools. Each pointer type can be associated with a pool (or subpool). Once the pool goes out of scope, all memory is freed. You can use this to avoid explicit deallocations yourself. Pools also control allocations and deallocations, and there exist Debug pools that can help ensure memory is accessed correctly.

Ada also requires that stack-based objects be declared as "aliased" before you may make a pointer to them, so it's always clear where there might be trouble.

Finally (I think), Ada has a concept of accessibility levels. Essentially a pointer cannot point to an object that is more deeply scoped than itself. This isn't the perfection of the Rust borrow checker, but it does quite a bit.

As for C FFI, Ada does that quite well. It's got a package in the standard library with C interface types, and aspects for marking things for C FFI.

Re: Ada: a C Developer's Perspective

#146

Earlier quoted context omitted.

This idea that Rust and Ada are somehow alternatives continually pops up, and I still don't understand it. They each have their own ideas on what "safety" is, and how to address it. I'll admit I'm biased towards Ada, but I think it is pretty safe to say that "Rust safety" is a subset of "Ada safety" - but Rust does it's section and run further with it than Ada. Rust is obsessed with memory safety. That's it's thing.…

Ada was one of first, safer languages for system programming that also aimed to help with programming in the large, concurrency, maintainability, etc. Rust is the latest in that niche although without the embedded focus of Ada's common usage. So, of course we can compare them. Here's another on SPARK Ada vs Rust that's surprisingly fair from an AdaCore rep: http://www.electronicdesign.com/industrial/rust-and-spark-so…

Of course you can compare them. I didn't mean we shouldn't ever look at the differences in how languages do things. We should. I meant I didn't understand how one could be seen as a replacement or straight alternative of the other. They have different goals.

And I've seen that before. Frankly I thought it overly nice to Rust by not spending any time at all considering the differences in user-defined types. That's really one of the biggest and most important differences to me, and a place I think Rust really falls short.

Re: Ada: a C Developer's Perspective

#147

Earlier quoted context omitted.

Good point. I'd rather pick the one that hasn't needed an update in 20 years unless they're assuming it is bitrotten.

How do you distinguish between "hasn't needed an update" and "was abandonded by the developer"?

Probably isn't always easy.

Re: Ada: a C Developer's Perspective

#148
post #85

Earlier quoted context omitted.

Why? Ada libraries from 2002 without outside dependencies work perfectly fine. I'm using that old libraries all the time. Ada has been designed specifically for that, it's been used in the aviation industry that runs the same code for 20+ years minimum. That you think otherwise only shows that you've never seriously used Ada in a larger project.

The last version of DOS also works really well for the things it was designed for. You still wouldn't start new projects targeting DOS if you could help it, even if it would satisfy your current requirements.

Actually, I would, if my needs were simple enough. Rarely is it necessary to have much more in embedded fields. Have a look at MDOS, a modern reimplementation of DOS used in many modern embedded cases.

Edit: which is apparently now called adelian.

Re: Ada: a C Developer's Perspective

#149

Earlier quoted context omitted.

Ada was one of first, safer languages for system programming that also aimed to help with programming in the large, concurrency, maintainability, etc. Rust is the latest in that niche although without the embedded focus of Ada's common usage. So, of course we can compare them. Here's another on SPARK Ada vs Rust that's surprisingly fair from an AdaCore rep: http://www.electronicdesign.com/industrial/rust-and-spark-so…

Of course you can compare them. I didn't mean we shouldn't ever look at the differences in how languages do things. We should. I meant I didn't understand how one could be seen as a replacement or straight alternative of the other. They have different goals. And I've seen that before. Frankly I thought it overly nice to Rust by not spending any time at all considering the differences in user-defined types. That's rea…

"I meant I didn't understand how one could be seen as a replacement or straight alternative of the other. They have different goals."

I agree. It's just a weird thing about these discussions that makes it necessary to bring up. The online forums typically divide between "system" languages you can write OS's or low-level code in versus "application" languages you write anything else in. Performance comes into play. GC vs non-GC, too. The kinds of benefits on safety and system side that people like about Rust are the categories Ada is designed to handle. It's behind on temporal safety but otherwise solid. So, we have to bring up the comparison due to how the local community might be mentally categorizing or evaluating things.

Also, many wanted something safer or better than C/C++ but never heard of Ada. That's worth addressing in and of itself. I think D language has a similar problem where it's a lot better than C++ in many ways but gets too little attention. Once upon a time, there were Delphi and Modula-3, too. Those times are past us. :(

Re: Ada: a C Developer's Perspective

#150

Earlier quoted context omitted.

I've always had a massive soft spot for Ada but I've never been able to find a use for it in actual work (not much call for it on the web). I think the reason I like the language is the type system which is like the pascal one on steroids and I love Pascal, it was the language that taught me you could reason about a program by building up from primitives.

> (not much call for it on the web) Server-side stuff is a big focus of the upcoming year, so maybe then? :) (I've been doing more of it lately and found it surprisingly pleasant)

The issue there isn't the language, Ada is lovely but that the surrounding infrastructure isn't there, it lacks widely used 'modern' libraries for a lot of stuff you take for granted in .Net/Java (even PHP) Land.

I'd love to be able to use it at some point and writing a web framework on top of it has been one of those fun if I ever have lots of spare time projects that sits in my queue.

Post reply on HN