As an aside, I keep seeing people don't "get" this, and it is painfully unclear to me - why?. Perhaps the pool of people with 15-20 years that are still doing programming is very small, so they make very tiny noise.
I'm at 20 years of paid, professional coding, and 30+ if you count my Apple IIe/gs days and fooling around with C++ as an undergrad.
It took me about a week or two to make friends with the borrow checker, and mostly those were self-inflicted wounds from trying to write aggressive zero-copy code.
I think that Rust works very well for certain coding styles, but the learning curve is much higher for other coding styles. If you've been scarred by C++ and you're used to treating variables as mostly immutable, the learning curve is pretty reasonable. But if you work in a style with a lot of mutability and you've never wrested with "const char *" versus "std::string" in C++ (which both exist for a good reason in C++), there's more to learn. So I could legitimately see it go either way.
My handy litmus test: Do you utterly despise C++, or do you have a complicated love-hate relationship with it? If you fall in the latter group, you may fall in love with Rust on the first try. If you've never even used C++ enough to have an opinion, then it's possible you might not care about high-performance static languages and the prices they pay to go fast, and so Rust's trade-offs might not even be interesting to you.
Maybe I'll give Rust a go after all. No pun intended. ;)
[0] Unless that something is Rails templating because dang, that is some crazypants there.
I'm a pythonist most of the time, although I've done a not insignficant amount of work in C, but I like high level languages more, and C++ feels like the worst of all the worlds. It is complex and bloated (templates) and magical and all kinds of things. I think I summed it up one day by saying that, as a newbie to C++ my frustrations with the language were summed up by a 0 argument object constructor having no parenthesis if it was stack allocated, but heap allocation or arguments require parens, because the 0 arg constructor would conflict with a function prototype if it had parens.
There's so much bloat and cruft and oldness that the language has baked in inconsistencies and gotchas and so much stuff (which of the 12 different kinds of pointers should I use) that it is horrible to learn.
Rust on the other hand has complex semantics, but they are well defined, sensible, and logical. Sure I sometimes want to smack the borrow checker, but the reason why isn't "someone made it this way before I was born and now I'm stuck with the results".
Getting dependencies from the system is a big PITA and the build tools, as in cmake, seem to require as much knowledge as the language itself.
Having a C++17 with a tool like Cargo building static binaries and just the right versions of the libraries would make my life with the language much easier.
The most important tricks I've learned are:
- Return types should usually be owned values, input types should often be references (or AsRefs). "Be explicit in what you return, and general in what you accept".
- If I'm going to be pointing into an array, its often easier to just pass around indexes instead.
When I tried Go I just didn't get what it had to offer. It felt like the wheel, reinvented. I was like "That's it?". I can see how that's appealing but, for me, Rust is a stepping stone on what we should expect from programming languages of the future.
A new language with a new paradigm is going to take longer to feel productive in, especially when the tooling and libraries aren't quite there yet. I can see how that's not good for someone who wants results now.
Rust's ecosystem is very much in its infancy. I expect 2017 to be a great year in terms of both language ergonomics (e.g. see Rust Language Server) as well as stabilization/standardization of very important things like how to do concurrent I/O. If your niche is distributed computing (e.g. I/O bound servers), yes, Rust is currently not going to satisfy you.
I think comparing Rust and Go is not fair for neither of them and, even if both are advertised as "systems languages" they are actually very different beasts filling their unique niches.