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. Unsafe code aside, it's memory safe. And it tackles some concurrency issues too.
Ada is more concerned with overall correctness, particularly in terms of types, where the types are semantically meaningful. And it goes further and dips into memory safety and concurrency. It doesn't such an extreme tact as Rust, but it does an awful lot to provide good options that allow you to avoid many issues. And it generally tries to make programs easy to understand. And more - some of which, as the article notes, are really quite wonderful for going really low level.
Personally I see the most value in the semantic type safety. That's really been, in my own experience, where Ada has helped me the most. Many of the other features are also great. I just don't see almost any of it in Rust. You can sometimes get stronger guarantees about a few things and you kind of lose everything else.
How is that an alternative or a replacement? Yet this idea is everywhere.
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 because it's different, but that doesn't make it the end-all goal.
But frankly, I doubt that you can. Others will say "operating system kernels", but people are happily writing OS kernels in OCaml, so <shrug>.
Yet others will say "safety-critical hard real-time tiny microcontrollers without an MMU" (one of Ada's domains), but on those systems you don't want to do dynamic allocation anyway, so the question of GC or not is kind of moot.
I've said it before, I'll say it again: Rust would be a better language if it had a GC and the possibility of marking certain program parts as GC-free (the way it allows you to mark certain parts as unsafe).
Here's PyPy's GC, implemented in Python: https://github.com/tycho/pypy/tree/master/rpython/memory/gc
(I haven't looked at it in detail.)
Anyway, even if you absolutely had to use a non-GC language to implement a GC, that would not preclude writing 99% of the browser in a GC language and only the GC in something else.
Also, why would implement GCs multiple times at different levels of abstraction in the stack, other than for something specific like PyPy which is specific like designing an interpreter to help test language features quickly?
But you're still wrong on this drop being necessary, I think. You can do it just fine in a language with GC that also allows you to allocate a block of memory that is not considered by the GC.
I think it's a bit disingenuous to say a "GC language compiled a GC language" when the compiler used non-GC portions of the language to do it. You're right, I should have said "A language which can work without a GC" instead of "a non-GC language;" but I think the spirit of my comment was clear.
That said I think what you said above is right, and non-GC code is really only necessary in the hot parts of an application (and applications that can't use dynamic allocation for whatever reason, but that's another discussion). Rust is even working on adding GC support [1] (albeit very slowly, as they should). That said non-GC languages (or at least the ability to write code that doesn't use a GC) is still necessary in many industries for many reasons; that isn't going to change for a long time, if ever.
[1]: https://manishearth.github.io/blog/2016/08/18/gc-support-in-...
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.
Personally, I interpret the focus on memory safety as a response to "memory issues aren't a big deal" or "memory issues only come from incompetence" viewpoints.
Memory safety is not, itself, program correctness. It's just one way programs can go wrong.
Could you elaborate what you think is cool there ("other cool bits")? Serious question, I'd like to hear a personal opinion.
I think the reason I like the language is the type system which is like the pascal one on steroids and I love Pascal, it was the language that taught me you could reason about a program by building up from primitives.
Server-side stuff is a big focus of the upcoming year, so maybe then? :)
(I've been doing more of it lately and found it surprisingly pleasant)
I'd love to be able to use it at some point and writing a web framework on top of it has been one of those fun if I ever have lots of spare time projects that sits in my queue.
http://www.electronicdesign.com/industrial/rust-and-spark-so...
And I've seen that before. Frankly I thought it overly nice to Rust by not spending any time at all considering the differences in user-defined types. That's really one of the biggest and most important differences to me, and a place I think Rust really falls short.
I agree. It's just a weird thing about these discussions that makes it necessary to bring up. The online forums typically divide between "system" languages you can write OS's or low-level code in versus "application" languages you write anything else in. Performance comes into play. GC vs non-GC, too. The kinds of benefits on safety and system side that people like about Rust are the categories Ada is designed to handle. It's behind on temporal safety but otherwise solid. So, we have to bring up the comparison due to how the local community might be mentally categorizing or evaluating things.
Also, many wanted something safer or better than C/C++ but never heard of Ada. That's worth addressing in and of itself. I think D language has a similar problem where it's a lot better than C++ in many ways but gets too little attention. Once upon a time, there were Delphi and Modula-3, too. Those times are past us. :(
I do think your parent isn't fully right about the relationship though, as first they call Rust a "subset" of Ada's guarantees, but then say that Ada doesn't go so far as Rust in some places. In general, when discussing language semantics, I see them as more of a large overlap with some differences on each side, rather than one being a subset of the other.
Hopefully Rust will get type-level numbers and stuff someday :)
> We believe that we can have an RFC accepted and const generics available on nightly by the end of 2017. :tada:
Additionally, the "newtype" in Ada is far easier to work with. The new type inherits the operations of the parent type. When it comes to this sort of thing, it needs to be as simple and easy as possible or it just doesn't get done consistently.
As for not being alternatives, how do they mix in the same project? Does Ada have C-compatible FFI that lets both Ada and Rust see each other as C?
It has a more limited way of writing safe programs (memory pools and sub-pools, no aliasing by default, etc). That said, for some programs you will have to go unsafe and then you're done; however, from my limited experience with Rust it's also true there (Doubly linked list ?) even though you can go further and check more things.
Some people are working on having something similar in Ada/SPARK FWIW :)
> As for not being alternatives, how do they mix in the same project? Does Ada have C-compatible FFI that lets both Ada and Rust see each other as C?
Ada does have a C-compatible FFI, and in theory you can interface Rust and Ada. I don't know if it has been done though !
But the next step down is to do the memory management in an isolated module of your code, which is then supposed to be vetted thoroughly.
Vanilla Ada (i.e. not the safest variant) does provide RAII for dynamic management of resources in general.
Once you do get to explicit memory management, Ada does a number of things. I'm going to a list here just for my own sanity.
First, all deallocations are essentially marked unsafe. You use Unchecked_Deallocation() to free memory.
More importantly, it provides memory pools, and subpools. Each pointer type can be associated with a pool (or subpool). Once the pool goes out of scope, all memory is freed. You can use this to avoid explicit deallocations yourself. Pools also control allocations and deallocations, and there exist Debug pools that can help ensure memory is accessed correctly.
Ada also requires that stack-based objects be declared as "aliased" before you may make a pointer to them, so it's always clear where there might be trouble.
Finally (I think), Ada has a concept of accessibility levels. Essentially a pointer cannot point to an object that is more deeply scoped than itself. This isn't the perfection of the Rust borrow checker, but it does quite a bit.
As for C FFI, Ada does that quite well. It's got a package in the standard library with C interface types, and aspects for marking things for C FFI.
For me personally Rust is not a good Ada replacement, because 1) it has the usual obscure syntax - maybe to attract C++ programmers, who seem to like obscurity -, 2.) many semantic tricks and borrower idiosyncrasies that makes it harder to write, read and maintain than idiomatic Ada, and 3) it's fast changing. The good thing about Ada is that it is self-documenting, it's almost impossible to intentionally or unintentionally obfuscate it, and once you've written a program it will continue to work 10-20 years later.
Rust's syntax is, like many new languages as they are invented, essentially a pick of the crop of the best syntax ideas from other languages. 'Best' is probably debatable but familiarity is certainly not. Type annotations are basically Scala syntax. Class::method(), ditching `return` in favour of last-line expressions and the || {} closure syntax are all pretty close to Ruby. Structs/enums are also basically Scala. `instance.method()`, and pretty much the rest of the language, is universal.
It's true, Scala syntax for types is the weirdest part, but once you know what it means it's not hard to decipher. Much easier than trying to figure out function pointers in C, if you ask me.
#2 is probably true, but that's the cost of staying close to the metal. Rust makes all your memory access very explicit, rather than bundling it up in the standard/GC or leaving it to you. But it's a model you can get used to, and it has value as a mental model aside from its application in Rust.
#3 – well. Ada was young once. Rust is incredibly stable for a project designed by a distributed community of Mozilla and a ton of volunteers.
How so? Scala class bodies are a mix of ordered constructor statements and unordered declarations/method definitions, while Rust structs can only declare fields (without any sort of initial value). Scala enumerations (both scala.Enumeration and the more common sealed class versions) look nothing like a Rust enum; if anything Rust enums look like ML/Haskell algebraic type definitions.
> It's true, Scala syntax for types is the weirdest part, but once you know what it means it's not hard to decipher.
The part of the type syntax that is like Scala (i.e. the colons and arrows) has its origins in the ML family IIRC. Rust's bootstrapping compiler was written in OCaml, so I suspect that was in fact the inspiration.
I did fail to mention the other very Scala thing: match expressions. Most complicated Rust match expressions could almost compile without errors in Scala.
That you think otherwise only shows that you've never seriously used Ada in a larger project.
Edit: which is apparently now called adelian.
I did consider doing all my projects using ADA. I really want to love ADA. I simply can't because some fundamental building blocks are missing. I am very disappointed over this.
Second - many solutions/libraries are purely commercial. You need basic open protocols support by default /free. Otherwise such great language will still be at it's niche.
Rust is on a good path to became XXI century successful Ada :)