In my experience, Rust puts many costs upfront, which makes it harder to do stuff when you aren't used to doing it the Rust way, but makes it easier to get it right if you are used to Rust. It basically gives you a relatively strong guarantee that if your code compiles and has no warnings, it's mostly collect - yes, that includes logic errors to some extent thanks to the type system. That also makes refactoring easier - chances are, the bugs you possibly added by refactoring will get caught by the compiler. Obviously, that's not a complete replacement for testing, but it does reduce the amount of tests you need to write to ensure correctness.

Frankly, I don't consider myself a particularly good programmer - but when I use Rust, I feel confident because of being backed by the compiler. That's something I can't say about any other language, and I only have less than a year of Rust experience compared to 5 years of total experience programming.

Imo Rust is easier to master than other languages, but it's definitely harder to do basic stuff in it because of the upfront costs I mentioned.

> That's an unusual claim :) Could you elaborate? How is the learning curve, especially for fresh graduates who have been trained only on languages like C, Java and Python?

One way to look at it would be that Rust forces you to conform to a specific ownership model, and makes you be explicit about resource management and how things are shared and accessed. Having to do all that can make certain patterns awkward or hard to write, especially for those new to Rust who haven't internalized what the compiler wants yet.

But on the other hand because so much is explicitly spelled out it can end up reducing the amount of things you need to consider or keep track of while reasoning about code, making it easier. Especially for code which is essentially bolting libraries together with a bit of data transformation.

I've noticed this kind of reply on rust threads often. Someone says something like:

> Rust moves many potential program problems from runtime to compile time; it has a high bar to meet, but once you meet it the program is rock solid

And then somebody replies with:

> Oh my favorite language doesn't make me do all that work up front, therefore easier (TM). Why Rust so hard?

But the reply misses the point: Make no mistake, you're still paying the cost (with FASTCASHNOW-interest rates), but the cost is just smeared out over days or weeks as you fix, debug, and tune it during use. You may choose whether to do that work up front or while the program is in active use, but avoiding the work is not a choice.

> That's an unusual claim

It's really... not. For people that have actually written big things in Rust. We keep repeating it, but we try to cautiously, tread carefully, lest we be accused of being part of this dreaded Evangelism Strike Force we keep hearing so much about.

Ease of use != ease of learning.

Rust is hard to learn (unless you have a deep ML/Haskell + C background). But once you're up the curve, it's a very expressive + productive language. Refactoring and maintaining large projects confidently is a breeze, and creating powerful abstractions that can be safely leveraged by large teams of programmers... just works.

A language being easy to write has no relation at all with it being easy to learn.

How would a fresh graduate be able to write safe C code when even experienced people are unable to?

I have worked with multi-threaded C++ code long enough to see that it's impossible to work in a team while keeping the code safe. Usually servers crash and canaries catch it in production, but if we have type system improvements that solve these problem, why not take advantage of it?