The borrow checker is amazing! I hated it at first, but ownership and lifetimes don't just bring sense to multithreaded and concurrent programming, they also make your own data designs so much cleaner!

Rust, through ownership, effectively enforces the higher-level single responsibility principle that sometimes is a struggle to be consistent about in other languages. That alone is amazing.

But for me, what really gets me is how expressive it can be and yet it seems like we lose nothing in terms of security, reliability, predictability and efficiency. That's just a dream.

Rust makes it easier to write correct and readable code, and getting both at the same time is not a coincidence.

The very mechanisms of ownership/borrowing (a tight control over lifetime, aliasing and mutability) enforce a certain simplicity in the data-flow of the resulting software that you could get in other programming languages, but generally do not because the language was more lenient and you got away with a more convoluted flow.

Have you ever had to debug a ConcurrentModificationException in Java? This happens when you modify a container being iterated over. When you have a chain of callbacks/observers, it's incredibly easy to accidentally have a circular reference leading to this exception. In Rust, to get to this situation you have to use RefCell or equivalent, and it should make you pause.

Another thing I love with Rust is its balance between ease of use and fastness. Not only there are lots of high level features that are really cool in the language, but cargo/crates.io makes publishing a package very easy; while dynamically typed languages might seem easier sometimes I feel that if you are not rigorous (and I'm not, see the beginning of this comment :p) it's difficult to buy medium-scaled projects in them; and at the same time Rust is fast, and even when performances aren't critical, well, it's always good, plus in my experience some thing that isn't performance-critical can quickly become it (e.g. it doesn't matter if it takes 10ms or 100 when you run something as a command line, but then you're like "hey I could turn that into a webservice too" and it starts to matter).

There are a few languages I am quite familiar with, and some that I really like, but Rust is the one I found the most empowering. The problem with "safety" is that in programming when I read that word I tend to think that it's something for low-level stuff or things that can have security issues and I don't usually need that, but in the end I think that safety also leads to confidence: my code might not be best written, but with the compiler I can be confident that it's relatively correct (obviously it can't catch everything but well), which isn't the case with most other languages.

1. Fast program execution. Sometimes you just want the speed that a scripting language cannot provide. Although I have to admit that many times Python is fast enough. I also pick D sometimes to write fast "scripts".
2. Reliability. Rust is a language that puts an emphasis on correct and reliable programs. The compiler does a great job at pointing me at pieces of code that I should think about again. It is similar to Haskell in that "if it compiles, it is likely correct". You pay upfront for long "talk to the compiler" sessions, but from experience I'd say that it pays off.
3. A language that is a joy to use. There are some really great languages that I love to use. They include Clojure, Lua, Python and Rust. The first two languages are mostly the products from single inventors with good taste plus a couple of contributors. The last two are the product of their respective communities. The Rust community tries to bring together the best ideas and lessons from different programming languages and has a democratic development process that tries to create a language and an ecosystem that is nice to use and plays well together with Rust's goals.
4. A new language with stable releases. I like to try new programming languages from time to time. It is cool that you can pick between stable, beta and nightly, depending on your stability needs. Furthermore, you can count on Rust being around for longer because Mozilla is supporting the language.

It's really difficult for me to talk about rust without talking about safety. I write C++ for a living on a relatively large stack. It sucks to hunt down a sporadic double delete. So much.

One thing I don't think gets touched on enough is how much easier refactoring is because of the borrow checker. I think it's easier to see the lifetime of objects in rust, so it's easier to find blocks of code that can be extracted into a function or structure. It is very nice to be able to bang out some code (that works correctly, thank you borrow checker), and refactor it later on without too much of a hassle.

Concrete practical points that might interest a C programmer/engineer: (Those are obviously obvious to /r/rust regulars)

• The language is relatively small. -- That's rarely mentioned.
• No more wrapping std functions for safety and error-checking. Or banning some of the functions that are deemed dangerous. Or using a complete safe replacement library because you don't trust yourself or others.
• Abstractions are opt-in. Safe guards are opt-out.
• The language is not OOP-centric. You wouldn't be forced into a paradigm that never made sense to you. Or forced to use needless abstractions you never liked.
• You can use native performant libraries freely. You will never have to check if a library is shipped by all major distributions. You don't have to worry about the versions shipped. -- More maturity and completeness in the crate ecosystem is essential here.
• Static checking is (mostly) built-in. You don't have to depend on imperfect proprietary tools/services like Coverity anymore.
• A build tool is included. And the build process is unified and streamlined. No more autotools/CMake/(g|n|b|p|f|s|d)make/etc shenanigans.

This relates better, IMHO, to the pain points C users face, than general talk about safety design. Once a user dips their toes in Rust. They will start to grasp the bigger picture.

Rust, to me, has a number of things going for it beyond safety:

• If it compiles, it works: Rust and Haskell are the only languages I've seen where this has regularly been the case.
• Embedding: I think this is a killer feature. If you want to make a native extension for python, ruby, nodejs or erlang to get some additional performance or to integrate with native libraries rust is a great way to do it. The absence of a GC in rust lets it cooperate with other language runtimes without issues. This is an area where the only other competition has been C or C++.

• Dependency management: Rust doesn't just provide a better dependency management situation vs C and C++ but other languages too. I like working with cargo more than pip or npm and because it is the official tool it seems rust will be able to avoid the proliferation and fragmentation of tools that other languages have experienced.

If C is like playing with knives and C++ is juggling chainsaws, Rust is like parkour suspended from strings and wearing protective gear. It'll look ridiculous at times, but you'll be able to do all sorts of cool moves that would otherwise be damn scary or outright impossible. You'll have so much fun you'll start trying to do it in other languages, too. And many of us never look back.

Also you get new improved gear every six weeks, and between this and your newly built muscles, you start feeling like a super hero. This feeling is amplified by the community, which simultaneously does awesome feats and is really humble and open about it (you're by now accustomed to people being good at concurrency, and get slightly annoyed that your snake-charming friends insist on doing everything one step at a time).

You also met some folks you wouldn't have expected here, from a number of dynamic languages, braving the learning curve to descend into low-level programming, usually singing Rust's praises with unreal sounding benchmark comparisons.

You start looking with pity at your knive- and chainsaw-wielding friends. You see both their bruises and denial about said bruises. You'd want to offer them some of that awesome protective gear (by now you no longer feel the strings, because they seldom get taut), but you know the answer already. Poor folks.

A big non-safety selling point of Rust for me is a systems language with the tooling and ecosystem of a modern dynamic language. Dependency management and composition is a necessary part of complex programs, but a tedious, painful timesink in almost all systems languages. While CMake and similar tools improved the situation for C++, it's still an enormous pain and a barrier to sharing and reusing code. You are often forced to re-invent the wheel -- complete with your own bugs and maintenance obligation -- simply because getting a dependency to be built and detected cross-platform may be an even larger cost.

Cargo is a wonder. It's more limited in scope than something like CMake, but for the vast majority of use cases that are just pulling in a library or binding from the same language, it's spectacular.

Apart from big differences between Java and Rust like memory management (not just GC vs. lifetimes but also stack allocation), approach to threading, and Cargo vs. Maven, Rust is so much nicer in the seemingly little things like:

• UTF-8 everywhere instead of UTF-16 everywhere.
• Unsigned integers.
• Bytes from I/O being unsigned by convention.

• Ability to bake plain old data into the data segment of the executable with genuinely no run-time initialization.

I haven't developed this thesis fully, but I've been thinking that Rust's model is a better version of functional programming, and we lack a good term for it (since it's obviously not a pure functional language). The point of functional programming is to avoid shared mutable state by eliminating all side effects and using a rich type system that's hopefully easy for the programmer to use. Rust avoids unsafe shared mutable state, without requiring the avoidance of all side effects, and by using an even richer static-analysis system that tracks exactly what side effects are safe.

Of course, there are a lot of useful things a pure functional programming language gets you, like Haskell's implicit IO scheduling and threading, that Rust doesn't. But for many use cases where functional programming languages are great, they're great for specific reasons that Rust is also great at.

One of my favorite things about Rust is one of the practical applications of the safety. Specifically, it's that I can write multithreaded code without fear because the compiler won't let me get it wrong. It's far far far too easy to screw up multithreaded code if you're using any kind of shared data, and Rust is the only language I know of that truly makes it safe without compromising on performance.

As a trivial example, some time ago I fixed a subtle threading bug in fish-shell. The code used RAII and lock guards, which is good, but in this particular case the lock guard was created using the wrong lock. So it was locking, it just wasn't locking the correct lock, meaning the data it was mutating was subject to a data race. As I fixed that, I found myself wishing the program had been written in Rust, because that sort of bug simply won't happen in Rust.

As someone who's been in the system programming space for a while and played with Rust for ~1.5 years here's my highlights.

1. I haven't written any multithreading code yet but I love the borrow-checker since it does a fantastic job of dealing with mutable state. I find I get better architected programs with single-ownership long before I start writing Rust and I love to see the compiler enforce it.
2. ADTs. Simply the best way to represent State + Data bar none. Combine with pattern matching and it's just sublime.
3. Iterators. Never seen a language do them so well with so little overhead. The focus on zero-cost abstractions really shines here.
4. Cross platform support. This is a huge one. Having dealt with MSCV/GCC/LLVM/custom compiler toolchains I can't stress to wonderful it is to have a consistent compiler that can build other targets on a different host.
5. Cargo, other people have covered it, enough said.

6. The community. Truly one of the better ones out there who not only want to help but also provides releases like clockwork with clear semantics on stability and APIs.

I think "fearless concurrency" is a better pitch for Rust than "memory safety." The former is "Hey, you know that thing that's really hard for you? Rust makes it easy." The latter is, as Dave says, "eat your vegetables."

I would argue that if the Rust project would have just one mission statement, it wouldn't be "create a safe systems programming language". It would be "move towards a world where safe systems programming is the norm".

What's the difference? Both of the statements have the premise that Rust is – and ought to be – a safe systems programming language. However, the latter captures not only the REAL goal, but also the nuances and tensions: while safety is indispensable, we must do something else too, for the programming society to accept the safe tools we are trying to promote. That means ergonomics, that means performance, that means ease of use, that means wide availability – and that might also mean advocation of visions of a better world, which is what this blog post of Graydon's does.

Talking about the safety is fundamentally not so attractive to many of our potential users -- they're either C/C++ people who have evolved coping strategies to deal with all the pitfalls, or they're dynamic language people who get the safety, too, just at a performance cost.

So, I really like the "fearless" part. For me personally, the "concurrency" part isn't as interesting; really, how much of the code you write on a day-to-day basis needs to reckon with concurrency issues? I would think that's a tiny percentage for most developers. One could argue that this is exactly because concurrency is so bothersome/failure-prone in most existing advantages, but then we're back to the "eat your vegetables" argument.

So maybe it would be better to talk about "fearless performance", or "fearless zero-cost abstractions", or "low-level control without the hazards".

Rust gives you fearlessness in all the things, but it does mean learning new style and discovering new solutions to old problems. To fully understand 'Send' vs. 'Sync', for example, means really groking the Rust type system. Once you get the type system, then fully utilizing it with the expressive generics becomes unlocked, and then at that point you've transcended from Rust dabbler to fully fearless Rust user.

Once this world of development is unlocked to you it is mind-blowing, but it is a journey to get there, and not everyone will have the heart to make it. It comes in stages, is wonderfully rewarding, will make you a better programmer in you other favorite languages, but I think we should be careful with statements like 'Rust makes it easy'.

It does make hard things easy, but only after you've fully embraced Rust. This feels more accurate: "Hey, you know that thing that's really hard for you? Rust makes it fun."

I'm a lowly ancient Java programmer and I think Rust is far far more than safety.

In my opinion Rust is about doing things right. It may have been about safety at first but I think it is more than that given the work of the community.

Yes I know there is the right tool for the right job and is impossible to fill all use cases but IMO Rust is striving for iPhone like usage.

I have never seen a more disciplined and balanced community approach to creating PL. Everything seems to be carefully thought out and iterated on. There is a lot to be said to this (although ironically I suppose one could call that safe)!

PL is more than the language. It is works, community and mindshare.

If Rust was so concerned with safety I don't think much work would be done on making it so consumable for all with continuous improvements of compiler error messages, easier syntax and improved documentation.

Rust is one of the first languages in a long time that makes you think different.

If it is just safety... safety is one overloaded word.

One very important thing that isnt emphasized enough is that Rust makes systems programming accessible.

With C and C++ the barrier of entry is harder.

This is huge. This means more devs can become systems programmers. More people writing systems software. I think this is why rust has more success recruiting new devs from higher level languages and newbies than C/C++ devs.

In that sense, the fire flower makes systems programming accessible. And fire mario are devs who can write system programs.

Instead of going back and forth with blog posts I think the whole thing should just be settled next month at the Royal Rumble.