I don’t know what strategic change happened at AdaCore, but this open source and PR blitz is amazing to watch.
To be so often written off and literally been laughed at for writing in “that dead DoD language”, I’ve been amazingly productive in Ada in only two months in what feels like a new and modern programming language.
I think Rust’s hype and the recent changes in C++1x revitalized the stagnant systems language space and added a focus towards safety - if watching CVEs didn’t do that to do you already.
Not everything’s peachy though. The unit testing solutions are needlessly verbose, so I’ve been relying on type constraints, pre/post conditions and type invariants, but the built-in support for this makes things go surprisingly well. I’ve had people literally laugh at me when I tell them I wrote X in Ada–there’s definite pressure to go back writing Rust (which I wrote for a while) and I’m only just now starting to stumble upon other people writing Ada. It’s a battle between “I’m wasting my time, I should go back to Rust” and “I’m enjoying being productive in what feels like a high level, heavily typed C with a bunch of opt-in features.”
Neat, that’s an interesting search tool, and the code is easy to read (at least on an initial skim of bits and pieces of it). You are definitely not wasting your time!
So, wait, Ada doesn’t currently have pattern matching, and it doesn’t check if you use the proper fields in a discriminated union? That’s somewhat disappointing… :-/
case... when is close and more powerful that C/C++‘s switch, but it doesn’t pull out the value into a nicely named variable for you.
it doesn’t check if you use the proper fields in a discriminated union
It does, variants (“discriminated records”) carry a tag saying what the thing is. If you want the C-like behavior (such as to interop with C code, and not carry the identifying tag), you mark your record with Unchecked_Union.
One of the most common request is to get more compile-time guarantees, in areas such as data initialization before use, access to discriminated fields […]
What’s the kind of compile-time guarantee on discriminated fields that this refers to?
Also that part is disappointing if it’s indeed the equivalent of sum types we’re talking about, since that’s the workhorse of languages with pattern matching (like ML, rust, Haskell…):
Matching composite types is currently only supported on records with no discriminants. Support for discriminants and arrays will come later.
It is seen as a strictly better way of accessing fields whose existence depends on a discriminant, because it cannot fail at runtime.
It seems like its referring to the fact that it’s a runtime guarantee, and they’re trying to make it a compile-time guarantee. I haven’t seen this being a problem in practice. Variants can exist as variables with either a known and unknown discriminant, i.e. you know that a variant has a specific type, or don’t know the discriminant value, and I think usage is compile-time checked for variants which known discriminants.
I don’t know what strategic change happened at AdaCore, but this open source and PR blitz is amazing to watch.
To be so often written off and literally been laughed at for writing in “that dead DoD language”, I’ve been amazingly productive in Ada in only two months in what feels like a new and modern programming language.
I think Rust’s hype and the recent changes in C++1x revitalized the stagnant systems language space and added a focus towards safety - if watching CVEs didn’t do that to do you already.
What kinds of things have you been building with it, out of curiosity?
Most of the first month was getting up to speed and trying to boil down the language. The big thing I’ve made is a code search tool I now use at work on multi-million line codebases – it’s alpha and rough. I also did a faithful port of the raytracer in a weekend from C++ to Ada, and going to clean it up and do a write up on it. Right now I’m using libadalang to parse Ada code to do code generation for some other things I’m working on.
Not everything’s peachy though. The unit testing solutions are needlessly verbose, so I’ve been relying on type constraints, pre/post conditions and type invariants, but the built-in support for this makes things go surprisingly well. I’ve had people literally laugh at me when I tell them I wrote X in Ada–there’s definite pressure to go back writing Rust (which I wrote for a while) and I’m only just now starting to stumble upon other people writing Ada. It’s a battle between “I’m wasting my time, I should go back to Rust” and “I’m enjoying being productive in what feels like a high level, heavily typed C with a bunch of opt-in features.”
Neat, that’s an interesting search tool, and the code is easy to read (at least on an initial skim of bits and pieces of it). You are definitely not wasting your time!
So, wait, Ada doesn’t currently have pattern matching, and it doesn’t check if you use the proper fields in a discriminated union? That’s somewhat disappointing… :-/
case... whenis close and more powerful that C/C++‘sswitch, but it doesn’t pull out the value into a nicely named variable for you.It does, variants (“discriminated records”) carry a tag saying what the thing is. If you want the C-like behavior (such as to interop with C code, and not carry the identifying tag), you mark your record
with Unchecked_Union.I’m curious about this sentence then:
What’s the kind of compile-time guarantee on discriminated fields that this refers to?
Also that part is disappointing if it’s indeed the equivalent of sum types we’re talking about, since that’s the workhorse of languages with pattern matching (like ML, rust, Haskell…):
It seems like its referring to the fact that it’s a runtime guarantee, and they’re trying to make it a compile-time guarantee. I haven’t seen this being a problem in practice. Variants can exist as variables with either a known and unknown discriminant, i.e. you know that a variant has a specific type, or don’t know the discriminant value, and I think usage is compile-time checked for variants which known discriminants.