I don't really understand the "Rust is obsessed with memory safety" meme.

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.

Safety without compromise doesn't exist. Rust does what it does well, but at significant cost in developer time. I'd rather use a garbage collector, it's much much simpler and fine for 99.9% of use cases.

Garbage collection does make things easier, prettier, and simpler. BUT there are many problem domains in which a GC can not be used. A browser being a prime example...

Maybe you can find a better "prime example" than browsers, which nowadays are mostly known as execution engines for JavaScript, a garbage-collected language.

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).

That's kind of his point, you can't write a GC language interpreter in a GC language forever, eventually you need a non-GC language to actually implement the GC in. So in this way writing a Javascript executor in a GC language wouldn't really make sense, you're just adding needless layers of abstraction (at a serious performance cost). So I think a browser is an excellent example of an application which can't really be written in a GC language. Other examples might be Databases and realtime applications.

> you can't write a GC language interpreter in a GC language forever, eventually you need a non-GC language to actually implement the GC in

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.

How do they compile/interpret PyPy's GC, is the compiler/interpreter written in a GC language? I said you can't do it forever, eventually you need to drop to a non-GC language (I feel very certain of this, so if I'm wrong I'd really like to know).

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?

PyPy is originally bootstrapped on the C Python interpreter, but it can then interpret and compile itself without relying on CPythob anymore. If you insist, then once PyPy is bootstrapped, the "drop to a non-GC language" is its process of having compiled the garbage collector's Python code to machine code.

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.

> 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-...

Of course you need to drop to some sort of non GC language, or you would need a hardware GC. However look at Iota [0], that can compile LLVM to Common Lisp. So you can run GC and non GC languages within, kind of, Common Lisp. Or look at all the projects that compile a language to javascript, and there is no reason why the reverse could not be done.

[0] https://github.com/froggey/Iota

"safety without runtime compromise", fine?

When things such as the borrow checker are so heavily built in to the language, I find it hard to to see how Rust isn't ultimately intended to do memory safety. Obviously it does other things, and I'm sure it has some cool ideas in there. But I have a hard time seeing how it's a mischaracterization of Rust to say that memory safety is kind of it's thing.

I don't understand why the public marketing effort is so focused on safety, either, but it is. When I see Rust mentioned, e.g. here at HN, I cringe a little because odds are it's in the context of how unsafe everything else is, or there is at least some connection made to safety. "Obsession" seems loaded.

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.

By "public marketing effort" do you mean "people talking about Rust"?

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.

Again here the word "safety" starts to get rather muddy. What Rust calls safe is not what Ada calls safe. I'd rather be specific about what we're talking about.

Memory safety is not, itself, program correctness. It's just one way programs can go wrong.

https://brson.github.io/fireflowers/ for example

>... and there are plenty of other cool bits in the language.

Could you elaborate what you think is cool there ("other cool bits")? Serious question, I'd like to hear a personal opinion.

I've always had a massive soft spot for Ada but I've never been able to find a use for it in actual work (not much call for it on the web).

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.

> (not much call for it on the web)

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)

The issue there isn't the language, Ada is lovely but that the surrounding infrastructure isn't there, it lacks widely used 'modern' libraries for a lot of stuff you take for granted in .Net/Java (even PHP) Land.

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.

Yeah there's a ton of web frameworks so far, but with the new tokio stuff landing soon, I expect a lot of change!

Ada was one of first, safer languages for system programming that also aimed to help with programming in the large, concurrency, maintainability, etc. Rust is the latest in that niche although without the embedded focus of Ada's common usage. So, of course we can compare them. Here's another on SPARK Ada vs Rust that's surprisingly fair from an AdaCore rep:

http://www.electronicdesign.com/industrial/rust-and-spark-so...

Of course you can compare them. I didn't mean we shouldn't ever look at the differences in how languages do things. We should. I meant I didn't understand how one could be seen as a replacement or straight alternative of the other. They have different goals.

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 meant I didn't understand how one could be seen as a replacement or straight alternative of the other. They have different goals."

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. :(

What kind of semantics cannot be well expressed with Rust type systems, compared to Ada? The type system is algebraic, and pretty powerful.

One example is integer ranges; they'd be a runtime check in Rust right now. We'll get there. That said, in general, Rust's type safety stuff is fairly powerful, and IIRC has some things that Ada does not.

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.

first thing that comes to mind are bounds on integer subtypes. classic example is to declare an array to be indexed with such a type, then all out-of-bounds errors can be checked at compile time.

GHC Haskell lets you implement that as a normal library: https://nikita-volkov.github.io/refined/

Hopefully Rust will get type-level numbers and stuff someday :)

See https://github.com/rust-lang/rfcs/pull/1931 and https://internals.rust-lang.org/t/lang-team-minutes-const-ge...

> We believe that we can have an RFC accepted and const generics available on nightly by the end of 2017. :tada:

As as been mentioned, integer bounds for one. Using aspects in Ada will also let you provide other assurances (at compile time or runtime, depending).

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.

How does Ada address the problems that Rust's borrow checker addresses? Use-after-free in particular.

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?

> How does Ada address the problems that Rust's borrow checker addresses? Use-after-free in particular.

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 !

The general mindset is "if you need high integrity, you probably also need to statically determine an upper bound on memory usage." The consequence is that the safest Ada variants do not allow dynamic memory management at all.

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.

Ada addresses memory issues in a couple ways. In a general sense, the language is designed to prevent the need for explicit allocations and pointers as much as possible. The runtime uses a secondary stack to return dynamically-sized objects from functions. The low level parameter passing details are also compiler-controlled. The programmer specifies how an argument is used (input, output, or both) and the compiler deals with how to accomplish that. There are some other features (mostly related to types and bounds) that all combine to generally reduce the need for explicit memory management.

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.