Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ada: a C Developer's Perspective

methodsandtools.com

Post reply on HN
Print view View original

91–100 of 157 posts

Re: Ada: a C Developer's Perspective

#91

Post by atilaneves »

Manishearth wrote: post #87
fghvbnvbnfe wrote: post #33

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…

Safety without compromise doesn't exist. Rust does what it does well, but at significant cost in developer time. I'd rather use a garbage collector, it's much much simpler and fine for 99.9% of use cases.

Re: Ada: a C Developer's Perspective

#92

Post by AstralStorm »

rcxdude wrote: post #55
sgift wrote: post #36

Earlier quoted context omitted.

1) and 3) are related as far as I remember - Ada WOULD have found the problem which was responsible for the Ariane 5 launch failure, but the section involved was speed critical, so the asserts were dropped to make the code run fast enough. Sad reality: The best security features in the world are useless if they are too slow for your use case.

Ironically, it's also Ada's asserts which contributed to the failure (though far from the root cause): The result of the erroneous calculation wasn't actually used, so just ignoring it like C would have would have been fine. It was the fact that the wrong cast caused the software to abort which resulted in the crash.

This is why static checking is better than runtime checking. Rust has some, but not enough. What is needed is something like Isabelle sledgehammer, quickcheck and metis logic and higher function correctness checkers. (Yes, Haskell has a bit more primitive version of Quickcheck.)

Re: Ada: a C Developer's Perspective

#93

Post by sidlls »

Manishearth wrote: post #87
fghvbnvbnfe wrote: post #33

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…

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' focus on safety but can very much be marketed without calling out safety all the time, and especially without the hints, suggestion, and innuendo that using a language without Rust's safety model is somehow dirty, dangerous, or worse irresponsible or unethical.

Re: Ada: a C Developer's Perspective

#94

Post by bitwize »

Puppy 1: And so, in conclusion, we have determined that Ada provides sufficient safety guarantees and features for our embedded system needs. Any questions?

Puppy 2: Yes, I have a question. Why didn't you use Rust?

Puppy 1: That's a good question. While Rust looks promising, we felt it was too immature for our needs and decided to go with the time-tested, standardized semantics and extensive tooling available with Ada.

Puppy 2: Rust has a borrow checker. That makes it 100% safe.

Puppy 1: Leaving aside the fact that no language is 100% safe, safety is a complicated topic and you can't make strong statements like that about it. Does Rust's borrow checker enforce arbitrary program invariants?

Puppy 2: ...Rust has a borrow checker. That makes it safe. Borrow semantics is the secret ingredient in the memory safety sauce.

Re: Ada: a C Developer's Perspective

#95

Post by AstralStorm »

oblio wrote: post #59
pavlov wrote: post #22

Earlier quoted context omitted.

To paraphrase JWZ... "Some people, when confronted with a dependency problem, think 'I know, I'll use Docker.' Now they have two problems." Unfortunately there's no single answer. Static libraries vs. dynamic? Global install or packages from a repo? Everything depends on the degree of control you have over the deployment environment.

True, C/C++ have it a bit more complex. But is it really an unsolvable problem? One would think that with the level of investment in C/C++ someone would be able to create something all the hipster languages have done in the last 20 years. I guess Gentoo's emerge would be the closest thing to a "good" C/C++ package manager we have today, which I find a bit funny :)

C++ standard committee is working on an intermediate step in the right direction: module support.

Re: Ada: a C Developer's Perspective

#96

Post by user5994461 »

dorfsmay wrote: post #77
andrepd wrote: post #70

Earlier quoted context omitted.

Well, why? Why would a library be bad just because it hasn't been updated in 15 years? Does it spoil? Maybe it doesn't need to be updated.

Environment rot, yes (protocol changes, bug that weren't found yet by the time that library come out, etc...).

There are environment and protocols that don't change much. Typically the places where Ada is used.

Re: Ada: a C Developer's Perspective

#97

Post by Hasknewbie »

pavlov wrote: post #8
flukus wrote: post #4

So how does Ada go speed wise (real world not micro benchmarks)? Were/are there legitimate reasons to opt for c over Ada?

On early PCs, Pascal and C were pretty much tied in popularity. Both were free to implement, and small enough that you could make a fast compiler on a typical PC with only 256-640 kB RAM. C won because it was more flexible and was chosen by Microsoft, but Pascal definitely had a strong following (it was the original Mac's API language, and on PC it was a major contender thanks to the nice and fast Turbo Pascal IDE).…

> Ada was a complicated and rigid language designed by a Department of Defense committee

Ada was designed by Jean Ichbiah, and although there was a committee he did override them on multiple occasions. So not really a design-by-committee.

The reasons it got no traction were: it was too complex/heavyweight, and too dissimilar to C to warrant a change (businesses waited for C++ instead, since it was around the corner at that time); due to its complexity it took a while for certified compilers to show up, and when they did they were quite expensive.

Since it was properly established in high margin markets, the community (mainly AdaCore, since they are the main compiler vendor) did little to improve its standing -- the only open-source projects they have pushed are all under GPLv3, which is not going to help with its popularity (not a judgement on GPLv3, it's just that basic lib are almost always under more liberal licenses, e.g. Boost). It really feels as if these OSS projects were pushed only to attract new programmers, while trying to prevent[1] an actual independent community from springing up. Odd behaviour. Every 6 months or so someone on HN or Reddit posts an Ada article that get people's interest, and then they discover they cannot write their project with it due to its licensing.

[1]: "...it is the intention of the GPL distribution of GNAT to restrict your freedom" in: http://libre.adacore.com/tools/gnat-gpl-edition/faq/

Re: Ada: a C Developer's Perspective

#98

Post by monocasa »

flukus wrote: post #72
pavlov wrote: post #8

Earlier quoted context omitted.

On early PCs, Pascal and C were pretty much tied in popularity. Both were free to implement, and small enough that you could make a fast compiler on a typical PC with only 256-640 kB RAM. C won because it was more flexible and was chosen by Microsoft, but Pascal definitely had a strong following (it was the original Mac's API language, and on PC it was a major contender thanks to the nice and fast Turbo Pascal IDE).…

Was anyone building things like operating systems or drivers in pascal? AFAIK that was always the realm of c. Turbo pascal was the first language I was taught, I have a soft spot for it but I think it had largely faded away by then.

Apollo built a whole Unix-like in Pascal that ran on their workstations.

https://en.wikipedia.org/wiki/Domain/OS

Re: Ada: a C Developer's Perspective

#99

Post by kqr »

aamederen wrote: post #2

I had a strange internship topics involving Ada. I tried to run a huge program (a simple stdio wrapper around a huge library actually) on an Android machine (Android 2.3, ARM). At that time, the only ADA compiler for ARM was available on BSD so I had used a Windows machine for development and a OpenBSD laptop for compiling the wrapper. The subtyping feature I love the most. You see the benefit when you need to call a…

Important terminology nit: subtypes and derived types are two different things in Ada. A "subtype" is essentially a local new name for an existing type (it makes little sense to export subtypes). A derived type is a new type that is based on another type, but can be restricted to a subset of values of the original type, and cannot be interchanged with the original type.

Re: Ada: a C Developer's Perspective

#100

Post by nickpsecurity »

fghvbnvbnfe wrote: post #33
sp0ck wrote: post #6

It's not only a language that is key to success. Libraries. I searched for LDAP support for ADA (old protocol used by many companies). I found library ( http://savannah.nongnu.org/projects/adaldap/ ) with latest news from 2002 and CVS repo :) Then I search for SNMP (another dinosaur still in wildly use) - similar result. Second - many solutions/libraries are purely commercial. You need basic open protocols support by…

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

Post reply on HN