http://www.adacore.com/uploads_gems/07_safe_secure_ada_2005_...
https://en.wikibooks.org/wiki/Ada_Programming/Tasking
http://courses.cs.vt.edu/cs5204/sp99/Overheads/6UP/6UPCSPand...
http://www.adacore.com/uploads_gems/07_safe_secure_ada_2005_...
https://en.wikibooks.org/wiki/Ada_Programming/Tasking
http://courses.cs.vt.edu/cs5204/sp99/Overheads/6UP/6UPCSPand...
So i read documentation instead. Ada mostly seems like a pretty sensible language. Its story on memory safety, though, seems to be "don't use dynamically allocated memory", or at least, if you do, you're on your own. It doesn't have anything like Rust's safety guarantees, or those that fall out of having a garbage collector.
If it was 2007, and Ada was a bit more easily available, I'd be agitating for it. But i think its shot at the open source big time has passed.
http://libre.adacore.com/download/
You can download the 'GPL edition' of GNAT [1]. This is a complete toolchain for Ada 2005, with the same actual compiler as the commercial version, i think. The libraries are GPL'd, so if you distribute a binary built with it, it has to be GPL'd. So, no Ada 2012, and no way to distribute binaries willy-nilly, but certainly enough to explore the language.
I always puzzled why even C++ does not provide any facilities like that out of the box.
(2) Compiler and runtime licenses. I always feel like the version of Ada I get is either somehow not the "best" one or has some lingering license issue with the runtime library. I don't think this is necessarily true, but it's easy to get that impression.
(3) Packaging, libraries, and documentation. Many developers expect a tool like cargo to be available and have access to a wide variety of open-source libraries. They also expect lots of tutorial documentation and blogs.
"Memory Management with Ada 2012"
2) Unix, C is so fundamental to building software, that I think any language that doesn't share syntax with it is doomed. Having a common syntax helps in learning new languages, IMO, and can also be a launching point for differing semantics...
EDIT: I keep thinking a different language that acts as a front end w/ a better syntax might be a good idea. It outputs Ada that integrates with the tooling ecosystem. Also, a seemless FFI for C libraries like Julia's.
It certainly wouldn't hurt if people simply used a more literate programming style no matter what language they choose
Far too many people think code as below is acceptable.
This is C obviously, but pretty much equal horrors around in every language.
This isn't 1994 and the compiler really doesn't care how long your variable names are, plus EatWhite() is pretty damn fast.
const int to_pn = base_n ^ label_n;
const int from_p = _array[to_pn].check;
const int base_p = _array[from_p].base ();
const bool flag
= _consult (base_n, base_p, _ninfo[from_n].child, _ninfo[from_p].child);
uchar child[256];
uchar* const first = &child[0];
uchar* const last = flag ? _set_child (first, base_n, _ninfo[from_n].child, label_n)
: _set_child (first, base_p, _ninfoNo, that's C++.
struct {
int check;
int (*base)(void);
};You mean Rust I think ;)
So, Rust ain't the Ada makeover Im thinking about. It's also in a stability-oriented freeze of existing design right now. So, the makeover will need to be a different language.
I won't lie to you. It took me longer to produce good code in Rust than almost any other language I've recently learned. But it's worth it; it's quite simply amazing that it is capable of guaranteeing what it does, with nearly zero overhead. Also, I'd say in many ways it's simpler than C, because it has no undefined behavior; I don't need to concern myself with any of the nuances that I had to learn in C. I highly encourage you to give it two weeks, that's what it took me to become hooked.
There's also a penalty a language pays for following a C-like syntax and semantics but diverging in specific but significant ways. In this category, I present Perl, which much of whole generation of users decided to treat like C, and got very confused and upset when it didn't always behave like they expected (which I maintain is because they didn't actually understand the language as well as they thought). There's a penalty for being very like something else to the point that people can mostly ignore the differences, but occasionally those differences come out to bite them if they haven't actually learned what they are.