What's New in Ada 2022
learn.adacore.com
learn.adacore.com
https://learn.adacore.com/index.html
Alire is a Cargo-like Ada package manager:
There has been increased interest in Ada as Rust has grown in popularity. There has even been some synergy and exchange of ideas.
Spark got Rust-style ownership of pointers:
https://blog.adacore.com/using-pointers-in-spark
AdaCore and Ferrous Systems are working together to help Rust get more formalized for future use in safety critical work.
Ferrous Systems recently released the Ferrocene Language Specification [2] to formally document the Rust subset that Ferrocene will use.
[1] https://ferrous-systems.com/ferrocene/
[2] https://ferrous-systems.com/blog/ferrocene-language-specific...
To be more precise, it has introduced affine types.
Rust happens to be the more well know mainstream implementation of them.
Vscode/emac has Ada plugins as far as i know
I did a few AOC problems in Ada and used it a lot.
[1] https://learn.adacore.com/courses/intro-to-ada/chapters/intr...
(Disclaimer: I have a soft spot for Pascal)
Looks are deceiving. Ada's verbosity and bureaucracy are mind-numbing. I would still choose it over C and C++, though.
I can even look up compiler messages if I need to, unlike my debugger state, which is nice.
I'm completely convinced it's worth it. What looks like pointless verbosity and sadistic pedantry at first turns into a comfortable security blanket that keeps you aware and in control of what the heck you're even doing.
I'd encourage anybody to try it out, just go into it knowing it's kind of similar to jumping into a functional language for the first time. You're going to need to adjust your paradigm a bit to really settle in. Ada is a bit deceptive if you're used to dropping into an imperative language and getting a decent feel for it in an easy afternoon.
On the bright side, even if you don't get as hooked as me on it, you might just get a new way to look at programs out of it. Never know when that'll come in handy.
Can you tell me more? I am not familiar with Ada
I will admit to not liking using '@' for notation much at all in any language - never mind Ada - but I'm really looking forward to having a solution for the problem it solves. I do love me some long names, probably even by Ada standards, so it really will be quite nice. I also can't really think of a good viable alternative beyond simply replacing it with a symbol I just happen to find more visually appealing. So... oh well. It'll probably fade into the background soon enough.
My_Data (To_Index (1)) := @ * 2 - 3.0 * @;
> In Ada 2022, you can define string, integer, or real literals for your types. The compiler will convert such literals to your type at run time using a function you provide.
The example is fun, showing type concatenation in Ada à la JavaScript https://learn.adacore.com/courses/whats-new-in-ada-2022/chap...
Dangerous, I can see it if it's not implemented reasonably. I'll admit to being less than a stellar ARM reader so I can't say for sure, but I'd bet this was well-considered when it was added. Considering these are literals conversions should be check-able at compile time with some reasonable limitations, and I assume those were added. If I'm wrong though, do let me know.
Hard to read? Maybe, but not really? It feels like a 'modern' feature to me in the sense that back in the old days it may have been a little too opaque and required a step more than is ideal to see through it, but with modern editor facilities it seems easily fine. And I don't think it's as bad as tagged types can be in that respect, so I don't see this being a problem.
And it will enable some much nicer to use interfaces for libraries, which is one of the few things I've really found myself still fighting in Ada. I don't think it's a general solution to the whole thing, but I'll happily take it.
A: I wouldn't know personally, but here's what the Ada people say about this:
https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Devel...
the main pitch point is that Ada is useful as a language you can validate code in, and thus more safe in scenarios where errors or bugs are critical and cost human lives.
Again, not sure if I buy this (especially w.r.t. to other languages with stronger safety features, not just C/C++).
Ada is a peer language of C++, which is still in use today.
I did a presentation at FOSDEM giving a high-level overview: https://fosdem.org/2022/schedule/event/ada_outsiders_guide/
Big picture:
- straightforward language, once you've read a few hundred lines, you've pretty much seen 90%.
- native, no GC, allows customized allocators and other low level control (e.g. alignment, layout)
- had a proper package (module) system since inception, which makes creating and using crates for the new Alire package manager very natural
- encapsulation and namespacing only at package, not at the type level - you put related types/operations in packages - it's more like writing strongly typed C with namespaces, than writing classes in C++.
- no preprocessor or macros
- bounds-checked arrays and strings are arrays, and not null-terminated
- "access types" instead pointers. Each access type is unique (e.g. you could make two incompatible types which point to the same type) and can be assigned its own allocator. In general, pointer arithmetic prohibited, but can be done (requires built-in library and conversions).
- built-in concurrency types
- easy binding to C
tl;dr
It's like a simpler, safer, and more verbose C++, but you get a lot of compiler and runtime error checking for free.
That might have been a tl;dr around 20 years ago. Now, C++ is very different having progressed along certain trajectories quite a ways. I would not characterize Ada as "An [XYZ]er C++" based on what you wrote.
As a C++ programmer, I find Ada very familiar in many ways, despite what would appear to be wild differences in surface syntax. A lot of things I do in C++, I can also do in Ada, though it's missing things like lambdas and move semantics.
I'm convinced that if the Ada designers had gone with a C-like syntax the language would've been more widely adopted and tons of bugs would've been avoided.
http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-E.html
(An annex in Ada is an optional portion of the language designed for a particular use case that a given Ada implementation may or may not implement.)
AdaCore tutorials about using the distributed systems annex:
https://www.adacore.com/gems/gem-84
https://www.adacore.com/gems/gem-85the-distributed-systems-a...
https://www.adacore.com/gems/gem-87-the-distributed-systems-...
https://www.adacore.com/gems/gem-90-the-distributed-systems-...
It is not exactly gRPC because it was designed before gRPC was created, but the purpose is mostly the same.
PolyORB might also be interesting:
For example, consider how Pascal/Lazarus (a different language, sure, but in similar circumstances to Ada) support MySQL 5.7 at the latest (TMySQL57Connection) and might have certain challenges when you attempt to use them for web development or anything of the sort (REST, SOAP, gRPC, connecting to RabbitMQ etc.).
A brief search doesn't turn up any gRPC support for Ada, it feels like using something like Go for components that connect over the network and Ada for actual data processing with interop inbetween might actually be a better setup. It might also just be an uphill battle outside of niche domains where Ada (or even Pascal/Delphi) are established.
FWIW, in my brief dalliance with Pascal, I got the impression it's a good bit more, uh, fossilized than Ada. I didn't try too hard to find a pulse there at the time, but I don't think I tried much harder with Ada. Yet here I am, shamelessly shilling.
This is an excellent point and will probably keep lots of similar languages out there viable for a bit longer.
For example, I wouldn't start a serious project in Prolog either, but if there's a really good use case for it and there's a way to integrate it with other languages/runtimes, be it C/C++ or anything else, then I might consider it.
> FWIW, in my brief dalliance with Pascal, I got the impression it's a good bit more, uh, fossilized than Ada.
It depends. It's still a good option for various native GUI software and the occasional bit of number crunching/utilities, especially when used with Lazarus: https://www.lazarus-ide.org/
That said, it's definitely showing its age and the whole Delphi/Pascal divide isn't helping much either. Generally .NET and Go do most of the things I would have considered it for 5-10 years ago, though, maybe only the GUI part isn't entirely solved just yet.
I'm not sure why, but most of the newer runtimes/languages don't really have strong built in GUI options, perhaps because developing those and supporting multiple platforms takes a lot of time. I can't stop wishing for something that's as stable as Java Swing or even OpenJFX for something like .NET: Avalonia UI seems like a third party project and using something like Qt/GTK binds isn't always easy to pull off.
Just give me a simple and easy to use language that has built in packages for doing most of the common stuff (working with different data formats, network interaction etc.) and has a built in cross platform GUI library, with an IDE that lets you use a designer with drag & drop functionality for laying stuff out, before you connect all of the components in code. Somehow the wisdom of RAD (rapid application development) seems to have waned in the last decade.
Racket does all of these afaik outside of the built in WYSIWYG editor for GUIs. There probably are 3rd party designers around though.
Yeah, that was definitely quite the bright spot. At the time GUIs weren't really what I was interested in, so ultimately I moved on. But for a long while since I'd fire up Lazarus again whenever I started thinking about native GUIs.
Never did much with it though, as I was never inclined to do everything in Pascal and it didn't seem worth the trouble to make it work with whatever I was wanting to use for the rest of it.
This hasn't been my experience (for Delphi anyway). There's a pantheon of various components for Internet protocols available that work well, I have used REST and SOAP amongst others. If there's a library with a c or C++ interface then you can connect it to Delphi. Lazarus I have less experience with, but likewise can interface to anything.
Clients, sure. But something like the Spring framework for Java or ASP.NET for .NET, or even Ruby on Rails or Django for Python? Not quite.
Closest that I could find was Brook: https://wiki.freepascal.org/Brook_for_Free_Pascal but it appears that it isn't in very active development at all (last release was 3 years ago: https://github.com/risoflora/brookfreepascal)
There is a nice page about web development on the Wiki: https://wiki.freepascal.org/Portal:Web_Development
But for the most part, even there you won't find the "one true way" to develop new enterprise apps or other larger projects.
There is fcl-web (https://wiki.lazarus.freepascal.org/fcl-web) and fpWeb (https://wiki.lazarus.freepascal.org/fpWeb_Tutorial) but both lean more towards writing your own web server and handling the lower level HTTP interaction, vs what something like Django would let you do, mostly thinking of what your app should do, not so much about how it will look on a per-request basis: https://docs.djangoproject.com/en/4.0/intro/tutorial01/
> But something like the Spring framework for Java or ASP.NET for .NET, or even Ruby on Rails or Django for Python
You've outlined a number of different things there and you could make your own with delphi, since again its just like C as to what it can do. You could, if you wanted, make a Django for delphi, though it's not something I'd do. Though your initial statement was Delphi couldn't do a lot of modern services either server or client. This isn't true. If it's all these other things, well, thats a matter of opinion, but there's no technical limitation with Delphi as far as protocols go.
Edit: There's this to which is interesting - a drag and drop web development set of components for SPA's https://www.tmssoftware.com/site/tmswebcore.asp which doesn't exist in other environments afaik. Though not sure I'd use it, I know of people who have and it works fine.