Why you should, actually, rewrite some of it in Rust

The biggest problem is that distributions have their own build systems and cargo just doesn't fit in a variety of different ways (not to mention projects that pin nightly compilers).

Distributions such as Fedora and openSUSE need to have a package for everything installed on the system (and everything required to build said packages). Now take into account the you can have multiple versions of the same library in a single rust project. While you could handle all of this on paper, automating it and putting it all into every distributon's build system is a very big task.

Ruby has similar problems, NodeJS is even worse than Ruby in this respect but I believe that Rust might make this the hardest for distributions. Personally I've never liked cargo that much as a user either, but as someone who works on openSUSE and was thinking about packaging rust packages I decided against it. It's just far too difficult and I'm not convinced it's worth the effort, since it feels like people have forgotten the reason why distributions exist in the first place (to provide a cohesive experience and provide you seamless management of your software). Having a shiny new package manager for every language just makes life difficult for everyone involved.

Not as much as rust, but still. I'm not sure whether it qualifies as memory safety for you but using Controlled types alleviates a large part of the problems of dynamic memory allocation. http://www.adacore.com/knowledge/technical-papers/the-gnat-i... might be of interest for the underlying implementation.

I also find that 'not null' access types, typed pointers and in general the in/out/in-out parameter passing mode help making ownership clearer... And there's also the limited types in the toolbox, to 'hide' ugly pointers/resource ids, etc.

Spark2014 still excludes pointers and aliasing, but I think some work is in progress. Previous HN thread : https://news.ycombinator.com/item?id=14346032

I am a fan of rust, but this article overstates the simplicity of C/rust integration.

A few examples:

* You may need to use PhantomData in your struct definitions to properly track lifetimes. Not sure I fully understand.

* C functions don't always return. Sometimes they longjmp (c.f. PostgreSQL). Calls into C code need to prepare for this and it's not trivial nor does it generalize to all projects.

* Integrating with the memory management scheme is probably possible but not trivial. For instance, Postgres memory contexts (regions/arenas) can hold any kind of object, and code can switch between them and create/destroy them at will. You could rely on rust to manage it's own memory, with circular references an Rc that might leak.

* Postgres has its own calling convention for SQL-callable functions and conventions for loadable modules. Integrating with this is a pain because macros are hygenic and can't make up new symbols. Maybe procedural macros will help when they arrive.

* Rich APIs that rust supports don't always translate well to C. When integrating with a large application that pushes you toward the lowest-common-denominator APIs.

* A lot of C macros don't translate well to rust and just including a C header in rust is a lot of work. Hoping procedural macros will help here too.

But you do realise that pressuring distributions in that way (when there are still issues with integrating cargo and crates into our existing build systems) won't result in Rust being properly supported right? There will be some hack to get Rust to work "well enough" to build Firefox, and if someone wants to start packaging more Rust stuff then all of the work would either need to be redone or started from scratch.

I'm saying this as someone who has started writing their projects in Rust and has plans to ship said projects as part of openSUSE and eventually SLES. If you cannot satisfactorily maintain a Rust package inside OBS then it's a non-starter. I imagine that many other distributions feel this way. We were burned with Ruby (and continue to be burned by it) and I doubt that anyone is going to jump on the "just auto-generate an RPM for every version of every crate we need" solution.

It's great that Firefox will have Rust code, but I'm not convinced that will make the situation better for distributions. It'll just make the packagers more stressed out.

> That dynamic memory exception is big enough to drive a truck through. Dynamic memory is so pervasive in today's programs that (I would argue) a language that's "memory-safe except for dynamic memory" has no business advertising itself as memory-safe at all. Maybe it was different in the past.

1. Many embedded applications do not use dynamic memory at all.

2. The runtime cost of a tracing garbage collector is largely a red herring. In a well-designed imperative program, all the cost involved with GC should not typically exceed 10% or so and manual memory management can only avoid part of that. On top of that, Rust's fallback option for shared ownership (Rc and Arc) are very expensive and can be worse than tracing GC. As I noted elsewhere, Rust is a very poor option when you have to deal with shared ownership (such as with persistent data structures).

3. Tracing GC does raise genuine issues in other situations (stack scanning in a multi-language environment, for example), but it's not the only established automatic memory management technique. There's no reason why you can't have a compiler switch to change to a different implementation.

4. Conversely, tracing GC can also have advantages, such as avoiding fragmentation for long-running processes (assuming the GC supports compaction).

> I'm not sure how I feel about Swift's ARC; it seems like a bit of a hack compared to Rust's lifetimes and I worry that it makes memory leaks too easy, but I haven't worked with it.

There's nothing hackish about Swift's ARC. It's basically bog-standard reference counting, which has very well understood semantics, and then the compiler optimizes away reference count updates that aren't needed. The primary downside of the approach is that it can't handle cycles automatically, but then, neither can Rust. Other than that, it ticks off pretty much all the boxes that Rust does.

> I don't think I count techniques that aren't available in any language less obscure than Cyclone.

I'm not sure why, nor why you would tie it to languages. After all, MLKit is Standard ML, hardly a language more obscure than Cyclone; deferred reference counting was first implemented for Java (lots of memory management techniques have actually used Java as a testbed).

> You might want to anyway, if you're writing such an application—the language is designed pervasively to eliminate as many sources of program incorrectness as is practical, and this comes through in more areas than just memory safety—but it's not the same kind of critical advantage that memory safety is.

If you want to go into a more detailed discussion of Rust with respect to software engineering, then we'll also have to discuss the software engineering costs that Rust creates, and that becomes a fairly large topic.