Every time I see something on Ada, it seems like a really nice language. Easy to read, easy to write, performance seems to be there with C++, easy (?) to interface with C, multi-threading seems to be somewhat easy too...<p>So, what's the deal, where's the catch? Why people aren't jumping on it like they do with, I don't know, Rust?
(Reposting from lobste.rs)<p>It's a shame there wasn't more information on the tools Ada provides for concurrency - I haven't seen another language which gives you as much flexibility and power to write safe concurrent code. It's much more heavy weight than some other languages in some ways, but gives you very strong guarantees you don't get elsewhere.<p>It also would've been nice to talk a bit about some of the features which make it particularly well suited for embedded systems:<p>* things like the ravenscare profile which give you a safe subset of the language using statically allocated never terminating threads<p>* the ability to select the scheduling algorithm (including ones with task priorities which are used to avoid the possibility of deadlocks completely - see the priority ceiling protocol for more details)<p>* the ability to address specific memory locations being built into the language, not just casting ints to pointers like you would in C<p>* full control over how elements on records are laid out, including endianness, this is essential with the previous feature when you're dealing with memory mapped IO registers for controlling hardware<p>* the ability to define that certain data types can only be used at certain specific memory locations (see <a href="https://cs.anu.edu.au/courses/comp4330/Lectures/RTES-03%20Interfaces.01.pdf" rel="nofollow">https://cs.anu.edu.au/courses/comp4330/Lectures/RTES-03%20In...</a> "pages" 314 - 332)<p>For anyone who's had to write code to interface with hardware on micro controllers, they're probably wetting themselves with excitement by now, doing this in C relies on the compiler doing what you think it will, which there's no guarantee of because the ability to use many of the features is implementation defined, if defined at all.<p>ANU's COMP4330, which these slides come from, is an excellent resource for learning more about both Ada and real time systems in general: <a href="https://cs.anu.edu.au/courses/comp4330/1-Lectures-Contents.html" rel="nofollow">https://cs.anu.edu.au/courses/comp4330/1-Lectures-Contents.h...</a>
Another cool thing in Ada world: SPARK.<p><a href="https://en.wikipedia.org/wiki/SPARK_(programming_language)" rel="nofollow">https://en.wikipedia.org/wiki/SPARK_(programming_language)</a>
This really makes me want to try Ada, if I could find a good fit for its low-level features (game development, maybe?)<p>The biggest thing that would make it annoying to write in is the verbose syntax--it's like the worst of Java, VB, and Standard ML. And yet, that same verbosity makes it kind of nice to read.<p>I think there's an inherent friction between "write-friendly" and "read-friendly" languages. It would be nice to have a language with a few different "dialects" (the way Ruby often has several equivalent ways to write certain constructs), such that a programmer could write the initial code in an extremely terse language, then run a formatter and get back a beautifully-formatted, much more verbose form of the same code.
I haven't learned Ada yet, but I've heard praise and eulogies from HN a few times it has been mentioned in recent years.<p>At first pass, it appears to have a lot of unnecessary keywords, and the semicolon terminator (at first pass) seems arbitrarily required.<p>Is it really that great of a language? What does it provide that FORTRAN, C, and/or Julia don't provide in terms of speed, or Python in terms of readability?
Quick note others may find useful. I found this offputting: the idiomatic mixture of upper/lower case and underscores in the syntax. Unnecessary cognitive overload. I've just done a quick test with current gnat and this works: you can just write everything in lower-case.
this is a really good feature that i've never seen elsewhere:<p>> For extra robustness you can name blocks and use the name when closing them. In the above example, I could end the procedure with end Program.