The official pitch is that Rust is a language empowering everyone to build reliable and efficient software.
Other pitches I've given people inlude:
C++ without C++
Modern programming language comfort with systems programming language control
(links to all of fasterthanlime's content)
One language that can comfortably target both application and systems concerns, with velocity and performance to match either
A powerful type system that helps guide development and program growth without getting impossibly in the way of expressing the design of the logic
A compiler that actually cares to help you, and ecosystem tooling to match
I personally think Rust has something for any audience, and that's it's greatest strength, but also a significant part of the learning curve, because there's a large surface area immediately exposed.
But if I had to give one single pitch for Rust, it's that it's made me a better developer. Just by the way Rust encourages you to structure programs, I understand how to organize code projects better, in any language.
I just had a revelation as to why I love Rust so much:
It can do things that other languages can't. An example of this is generics: I find Rust's trait model by far the most convenient and ergonomic among statically-typed languages with parametric polymorphism – my experience with such languages includes C++, Haskell, and Swift.
The design of the language as well as that of libraries is full of "aha!" moments, in the sense that "this is the only correct design, how come nobody was doing things like this previously?" Two examples of this are the ownership+borrowing model and Serde's zero-boilerplate, format-agnostic approach to serialization.
One thing I like about Rust is that it filters out lazy/sloppy thinkers. Even when I disagree with another Rust programmer, there is a certain level of respect that comes from knowing that they thought about the problem deeply enough to pass the borrow checker.
As to (3), Haskell's typeclass system is incoherent in the technical sense, i.e. you can end up with multiple implementations of a given typeclass for the same type, which is confusing.
However, there's an even worse kind of annoyance, which has bitten me far more frequently than incoherence: working with associated types is more cumbersome, because type definitions and typeclass impls with associated types that compile in Rust often simply do not compile in Haskell. Not to mention the requirement for several non-standard language extensions in order to perform seemingly simple tasks.
Regarding Swift, I simply feel that its protocol system is just weaker and has less features than Rust's traits, especially when it comes to expressing constraints. As a result, type-level metaprogramming is harder, or one can only provide fewer and weaker guarantees around not misusing a typed API.
Oh, yes, "private by default" is great especially when wrapping unsafe abstractions, or when writing abstractions with unsafe that relies on invariants being upheld. Public-by-default would make that a soundness nightmare. "Did I forget a private somewhere?"
The design of the hashing system is so much better than what you see in Java or C++. Separating the identity of the object -- define what fields participate, in what orders -- from the hashing algorithm is a genius idea.
entry is something I've never seen before. Java's collections have some "combination" methods like computeIfAbsent, C++ has nothing. entry just rocks.
One more thing that's good about that is hashing performance, as well as hashing "correctness" w.r.t combining hashes in a way that doesn't accidentally lose entropy: the object or its fields don't all have to produce a complete hash individually and initialize a new hashing state each time for that; they can just share one state instead.
Same here – AFAIK it was supposed to be a solution to some borrowck limitations, but it turned out to be immensely useful even when traditional control flow would pass borrowck.
Doing an elevator pitch is tricky because there are so many good things to mention. It's definitely contingent on the audience though.
I did one at work intended to generate interest in Rust for mostly Java and C# developers by showing zero cost abstractions for iterators: the lack of these in C# and Java can be super surprising.
If you're curious, the video is here: Rust: Zero Cost Abstractions - YouTube -- I filled it out a bit with some SIMD goodies when I presented it again for the Rust Dublin meetup. Somehow it got picked up by Coding Tech and seems to be a lot more popular than I would have imagined. And more admin/pain than expected too, due to some of the usual trolling in the comments.
Anyway, at work, I did a few follow up sessions for those interested. Some our devs use Scala and have experience with Haskell, so they really "get" the ADTs, option/result, strong type system, etc. They're quite keen on the derive macros too, especially for serde.
Interest faded a bit because I got really snowed in with some major deadlines, so I need to figure out what to do next: maybe we'll try building something small. I'm not exactly sure what though - I don't want to throw people in the deep end with async challenges immediately.
My elevator pitch has always been: (safe) Rust obsoletes dangling pointers, memory leaks, and race conditions, and furthermore, its steep learning curve highly rewards the persistent learner by promoting efficient software architectures. Your company no longer has to worry about random software crashes at 2AM on a sunday because of a memory leak.
Some other thoughts: unlike other languages, Rust forces the programmer to consider the lifetime of variables, meaning that unlike Go/Java, passing a reference to a function doesn't automatically heap-allocate the pointee (even if unnecessary), meaning you get WAY better performance in rust.
Having to go back to java/Go/Dart after spending time in Rust is a bit depressing seeing how much unnecessary heap allocation goes on under the hood. If only those language forced their users to consider the lifetime of variables, lazily heap allocating everything wouldn't be necessary
I’m curious and not wasn’t aware of this. Could you provide an example?
Also as to the type classes vs Rust’s traits comparison, IMO there’s still significant shortcomings around the fact that you can’t have type constructor classes (I don’t know what’s the right term, I’m talking about type classes with kind (Type -> Type) -> Constraint, type classes such as Functor, Applicative, Monad, Foldable, Traversable, etc).
If Rust supports this at some point in the future we can probably call it more strictly superior. I do like the coherence story in Rust a lot.