What Rust Can Do That Other Languages Can't

I frequently witness this rush to judge Rust as too complex to be used for business applications based on a few hours of hacking. For this to be a valid judgment, I would think one of two things would need to be true: a) Rust remains this difficult to use once you have experience with it, or b) most business applications are worked on for only a few hours.

In my experience, neither of those premises hold.

I believe that the rules of Rust not only give you exceptional performance without memory issues (as this article tries to demonstrate), but also that its rules engender a higher degree of correctness and 'well-factoredness' than most languages. I believe Rust is an excellent language for writing applications at every level of the stack when 'craftmanship' matters.

My employer has a "line of business app" written in Rust. Here's what we're learned:

1. Rust does have a learning curve. It's easier to learn to use well than C++, in my opinion, but certainly harder than Ruby or Java. You really, really need to budget 2 weeks for turning an existing C++ developer into a productive and confident Rust developer. You can't take somebody who doesn't know the difference between "stack" and "heap", or who has never passed an anonymous function to "map", and expect them to bang out code rapidly in two days.

2. The library situation for business apps is just barely adequate. We need support for PostgreSQL, RabbitMQ, REST APIs, etc. In each case, high-quality libraries exist, but they're usually missing something. (For example: For PostgreSQL, we need to use both 'postgres' and 'diesel' to get the feature coverage we want. For RabbitMQ, we don't have heartbeat support. For REST APIs, we won't have good HTTP request mocking until the Hyper async stuff sorts itself out. And so on.)

3. The Rust code is just ridiculously fast. We're processing gigabytes of data, so we love this.

4. The Rust code is remarkably "trustworthy", and I'm not just talking about memory safety. If your program even compiles, it almost always works correctly (assuming you understood the spec). This has at least as much to do with Rust's 'enum' and 'match', which encourage people to enumerate and handle all cases, as it does with the borrow checker.

5. Rust code is very pleasant to maintain and refactor once written.

Overall, we like Rust, but we're mostly only using it where (a) we really want performance, or (b) we really want to make sure we handle lots of tricky corner cases correctly. Oh, or (c) for long-running jobs that take hours to run on real data, where compiler correctness-checks are a huge win. We'll probably gradually use Rust in more places as we get experience and the tools mature.

I mean, seriously, the book on unsafe Rust is called the Rustonomicon as if the memory model of the old default-unsafe-unless-you're-Dennis-Ritchie languages is some Lovecraftian horror brought on because of our thirst for the cursed FFI.

Meanwhile, Rust's damn near magic (at least for me, a non-functional systems mortal) affine type system, which can eliminate many logic bugs and massively increase code reuse, is all but forgotten. The type system is at the core of Rust's entire memory safety but you need to read dozens of scattered blog posts and projects, and the standard library docs, to start to get a feel for how to move from OOP to trait based composition and lifetimes. In aiming for simplicity, most docs fail to show in practical settings how you can use Rust's type system to redesign your architectures in natural ways that completely reframe the process of writing code, making it easier to port ways of thinking and love the borrow checker.

Sorry, that was a colorful rant. Teaching a new paradigm is tough and the Rust docs team have done a great job. As the language and community mature, better and better pedagogical practices will emerge and introductory material that approach the language from all angles will grow.

The dial is certainly turned up further than most businesses are accustomed to. But if that business is doing something involving my credit card number, I think the threshold of "too far" ought to be somewhere beyond Rust.

I hope that Rust does get some substantial adoption for line of business apps, if only to give us some data on how much it really costs to deal with your buffer overflows in advance, instead of suffering the embarrassing outages and hacks that make the national news.

I think there's much more to Rust than just a systems language. For anything that you need to have c binding for (say, a crypto library), it seems a very good choice.

I was also thinking of combining some high level, abstract language (Clojure/Haskell etc.) with perf-critical sections written in Rust.

For the same reason I also find it easier to dive into 3rd party Rust code and modify it. In general you don't have to worry about hidden side effects, global state, weird calling conventions and similar things with Rust.

Edit: With the caveat that the number of available libraries and SDKs is still low, but in the case of PHP that was the case until the last couple of years anyway after Composer and Packagist came along.

I came to Rust, from Java and I do remember Rust being hard, but not enough to quit. While I am no guru, the elision usually does job for me.

For most business apps GC is better option, than other memory-management options. I'm not seeing Rust in place of Python or Java, as well. But it could be used in some speed critical pieces, where C currently used, for example.

The same is true for Ada and Haskell. You point to a typical problem of people who are interested in Rust. They like the syntax and features but the compiler gets in their way to be productive in a short amount of time. That is frustrating.

The Rust community should not point so much emphasis on its beloved borrow checker like the Haskellers praise their monads. Both things are attractive only if their is real practical value in everyday coding. If devs need three to ten times more time than in C++ to develop something then they won't switch, even if C++ has no borrow checker. They could compensate this lack with verification tools, FramaC and the like.

I agree with Andreas Bergmeier's comment in the author's blog. Experienced developers may barely have problems with lifetime issues, in particular if they use a language with garbage collection which really makes sense for most business applications.

Rust would probably have much more convincing power if the community would go the way which Microsoft went to promote their C++ and C# compilers. They provided a very convenient Visual Studio IDE with excellent documentation.

While the post gives the example as a simple struct field thing, that example itself isn't where it actually becomes important. It becomes important when you have structs holding pointers to the interiors of other structs, and more complex reference-returning semantics. I illustrate this in a particularly complex situation in http://manishearth.github.io/blog/2015/05/03/where-rust-real...

But yeah, D is getting there :)

It's not about returning a pointer to a struct. It's about the pointer being _safe_.

What if x was not allocated on the stack, but on the heap? y is part of x (not another independent object) so if x is freed/deleted then all references to y become invalid. Does D have a guarantee that this won't happen? (I think the answer is no).

This was noted in the post itself:

> Most other languages simply prevent you from giving away

> an interior reference, or require y to refer to a distinct

> heap object from the X.

    class X {
      public:
        Y* getY(void) {
          return &y;
        }
      private:
        Y y;
      };
    }

Rust has a resource ownership model (borrow checker) that allows it to check at compile time that references do not outlive the data.

   class Foo {
      int bar;
      int& getBar() { return bar; } 
   }

    vector<int> foo;
    int& bar = foo[i];
    foo.push_back(1) 

Are you are familiar with the substring problem in Java? Before 1.7.0_06, substrings where created using an offset into the buffer of the original string. Nice O(1) substring creation, the textbook example for benefits of immutability. Unfortunately, if you have long-lived, but short substrings taken out of short-lived, but long parent strings, the garbage collector won't find much to collect, since the substrings keep references to their parent buffers. This was no showstopper, but without immutability or in an environment with unmanaged memory it might very well be.

This Rust snippet is about similar cases of subcomponent sharing, just on a shorter timescale: the subcomponent is exposed in a way that allows the compiler to enforce that nobody keeps a reference for longer than it is guaranteed to be valid. You may look, you may even touch, but if you want to look again you have to ask again.

Other languages get by without this by garbage collection, by excessive precautionary copying or by simply hoping that the caller won't do anything stupid. Rust is unique in achieving the same runtime behavior as the latter but without the uncertainty. As a bonus, those un-keepable references cannot escape across concurrency borders so that in-place mutability becomes a lot more manageable.

As I understand it, if you have a structure that has a pointer to something (like a User struct pointing to an array of permissions or some such), and the memory pointed to will be freed when the structure is freed.

There is a case where code can keep a reference to this pointer around longer than the user struct it belongs to, so when code tries to use it it references an invalid pointer. This is bad. Rust takes care of this in some clever ways, so you cant have a pointer/reference that outlives it's parent.

https://golang.org/doc/faq#stack_or_heap

However, this

- requires additional input from the programmer, such as lifetime parameters in Rust.

- C and C++ don't have ADTs which help working with lifetimes A LOT (e.g. having Option<Box<T>> as nullable pointer).

- will reject 99.9% of useful libraries and programs written in C.

- would be equivalent to using Rust.

99% of the C++ code out there wouldn't compile anymore and a lot of it would require significant re-architecturing in order to work with the new paradigm.

Or more likely the vast majority of the codebase would keep working in "legacy" mode which wouldn't play nice with the safe portions of the code (since you'd have to consider all calls to the rest of the code as unsafe). Same thing with any external library not updated to be "safe". It's like the python 2 -> 3 transition, except a lot worse because it's significantly more complicated and probably can't be automated easily.

The reason C++ was so successful is because of its backward compatibility (all the way back to C). I'm not sure it'd make a lot of sense to introduce such radical changes now. Especially given how incredibly huge the language is already.

Microsoft and Google are working on static analysis tooling for this, regarding C++, but the tools require you make use of the right types.

Also, like any tool not part of the language standard, its use is optional.

This is why writing data structures in Rust is considered an 'advanced' topic.

[1] https://ricardomartins.cc/2016/06/08/interior-mutability

I agree, "people want to write code that runs and thats it" but there's a subset of folks who like to write their code in C/C++ and crank up the warnings, turn on ASan/UBSan, valgrind+electric fence, etc.

To be successful, Rust doesn't have to obsolete C and C++. It just has to attract a critical group of the next generation of systems programmers.

Rust has very little competition in this space (newly designed languages that can be used to write ISRs, bootloaders, OS kernels, etc). Many of the other popular languages strive to find some middle ground between C/C++ and Java/C#/Python.

At the end of the day, many of us are paid to ship features. For many industries, correctness and safety just can't compete with new features. It's the reason Lisp, Python, Ruby, and Go are so popular - you can quickly write programs which are both fast enough and memory safe.

The gaming industry, one of the bigger C++ consumers, will also probably not move to Rust for similar reasons: hitting a schedule is much more important than not crashing or not having memory leaks. You can always patch a game.

1. Allocate both X and Y in the same block of memory, maybe on the stack, perhaps in a heap. In inner loops, making calls to malloc is pure performance poison. Most common garbage collected languages are completely unable to do this, with the admirable exception of the C# and the other .NET languages (and possibly some others).

2. You want to access Y by reference, so that you can work with it without needing to make a copy. Again, this is very common in performance-critical code. You can do this in C, C++ and other existing "systems" languages.

3. You don't want to accidentally keep using Y once X (and hence the underlying storage for Y) is destroyed. This is a subtle and vile bug that can memory corruption, once-a-week crashes on production, and week-long debugging sessions, among other headaches. This is where C and C++ fail, and where Rust nails it.

You're absolutely right that there are much more interesting examples, e.g. https://t.co/HJV7G4n0PD. Doesn't fit in six lines though :-)