This post is more interesting than most because of the data they collected:
Based on our studies, more than 2/3 of respondents are confident in contributing to a Rust codebase within two months or less when learning Rust. Further, a third of respondents become as productive using Rust as other languages in two months or less. Within four months, that number increased to over 50%. Anecdotally, these ramp-up numbers are in line with the time we’ve seen for developers to adopt other languages, both inside and outside of Google.
Overall, we’ve seen no data to indicate that there is any productivity penalty for Rust relative to any other language these developers previously used at Google. This is supported by the students who take the Comprehensive Rust class: the questions asked on the second and third day show that experienced software developers can become comfortable with Rust in a very short time.
In some sense the large percentage of Google developers are “writing Rust without compiler support” (and use reviewers as compiler replacement).
Of course when you introduce Rust in such environment people are both able to quickly understand how everything works and are relived that compiler now is doing work that they were doing before manually.
If your company doesn't use C++ at all or uses a very different C++ style… situation may be different.
That's just how modern C++ is. It's not "Google pushing". The C++11 smart pointers were introduced exactly for the purpose of structured (no, it's not "rigid") memory management, and using them is the recommended approach.
"Your company" shouldn't just ignore the smart pointers and new/delete everything. Guess why.
Also, not all of those developers came from C++. Here's the very quote from the article:
most of them are coming from C/C++, Python, Java, Go, or Dart.
If Python, Java or Go aren't different enough from C++ and Rust, I don't know which languages are.
You still have to choose to use Modern C++. Back in the days when I was doing C++ (pre-Modern C++) I found that most of the C++ code I encountered was basically C-style C++. They didn't even take advantage of what was provided in the STL, as it was at that time.
But also I think what is significant is the comment by @user16251
1,000 programmers employed by Google are probably more skilled than 1,000 programmers selected at random.
And this is probably just not true as-is, at least certainly not to the extent people might assign significance to it. There are a lot of beginner, mediocre, lazy, or downright bad programmers even at places like Google or Apple; the top 1% are the top 1% there as well. A big corporate environment can accomodate many kinds of people, including those who haven't been fired only because nobody really understands how they perform due to multiple layers of bureaucracy, and/or because of inertia. I recall reading a blog post by a former Apple engineer describing how exactly these processes cause a lot of pain internal to the business, and how such a firm is not the "everyone is top rocket scientist" kind of thing that people picture.
The data has proven people screaming "Rust is hard" wrong. We can now stop demonizing the language for that and move right on to more useful discussions.
Yes. I'm pretty sure these exist. But you have to remember that these people cheat and lie literally every quarter. They, somehow, pass performance reviews, all these estimations and comparisons, they cheat left and right and then… they truthfully answer all these questions about Rust ramp-ups?
This logic makes no sense to me, sorry.
If people are cheating and hiding their [lack of] skills from their managers then they would hide their [trouble with] Rust rampup, too!
My point about choosing Modern C++ is that in my experience the average developer ignores what is receommended so even many C++ devs might find it harder than expected to move to Rust.
The data has proven people screaming "Rust is hard" wrong. We can now stop demonizing the language for that and move right on to more useful discussions.
??? I thought you were arguing the opposite! I.e., the article was arguing that moving to Rust wasn't that hard and you seemed to be saying that it's harder than the article makes out!
But, in my own experience, coming from .NET over the past several years, I've found Rust fairly hard in comparison to, say, Python or Go which I've also dabbled in. But it's not super hard.
This is an interesting perspective that's a little sobering to read. I genuinely have never meant "Rust is hard" in a demonizing way.
I belong to the group of people who gave Rust a try, found it was too difficult and gave up, then returned to it thinking "I have never failed to learn a language before, and I'd be damned if I started now". I genuinely think Rust is more difficult, initially, than any other language I've learned. With that said, it's worth the investment (time/energy), and not by a small margin.
When I've said that "Rust is hard", it's meant as an encouraging "Don't worry; plenty of us struggled in the beginning -- some of us even gave up one or two times before it all clicked.". But if people think I'm demonizing it, then I should clearly not be using that particular phrasing.
Like I said; sometimes it's sobering to read someone else's perspective on these things.
No doubt some people mean it that way. I don't myself.
I found similar with F#. Here it was partly the change of paradigm to functional. Having said that I still haven't done very much with it. Ditto Rust so far, as my day job is generally C# and the Microsoft ecosystem (F# barely used).
This is an interesting point - it's certainly possible that "my manager is telling me to do it" is all the motivation most people need to push over those difficulties!
Nope, it's different story. It's just incredibly valuable to have some Rust guru on your team.
Many highly disruptive and discouraging problems don't happen all too often, but if even one such trouble is between you and successful finishing of your first task… it's easy to give up.
If you look on this forum and elsewhere XY Problem is raised in huge percentage of topics. And it's really a big issue: many approaches which look natural for many other languages just don't work with Rust.
If you have someone who knows both Rust and your project it's not a problem at all since such person can always offer design that would work. But if you are restricted to URLO and other such forums… it may take many days before you would even find the level at which your actual problem becomes tractable.
The traditional response to this claim (which I'm not sure is accurate) is that learning Rust from nothing is not harder than learning any other language from nothing. There's good reasons to think this is not true [1], and it's also hard to square with the blog post, saying that programmers already experienced in mainstream languages didn't have more trouble than with other languages.
My best guess is that Google has good support and resources to help onboarding new developers with Rust, something that is implicitly available in most companies with mainstream languages by your coworkers knowing the language already. That implies that it's a problem that will eventually solve itself, but that Rust could perhaps do better at pushing early support resources at new developers; or at least letting them know they should look for them!
[1] primarily for me that in my experience, both personally and seeing the questions being asked here, Rust strongly encourages doing things the hard way where the less performant option is what you would use without blinking in many other languages.
We’d like to particularly thank one of our key training vendors, Ferrous Systems,
Heck even having a 1000 colleagues on the same road of discovery must help move things along a bit.
Contrast to me learning and using Rust all alone. After three years I'm still a Rust neophyte. Still, stuff I made as a Rust noob three years ago has been working reliably in production since. Even if it is basically my C style forced into Rust. Or even my Javascript style forced into Rust.
So basically zero to production did not take me any longer than any other of the many languages I have had to use over the years. Of course none of it is "idiomatic" Rust (how I hate that description), and many Rust features were not used. But so what? It works, it's proved robust and performant.
The big problem here is not that answer is like this, but the fact that you don't understand it you can, actually, create a struct Person that has references to parents, spouse and children!
And then you can write fair amount of useless code going deeper and deeper into the rabbit hole with lots and lots of lifetimes before you finally give up in disgust!
And without any Rust “guru” who may stop you most likely outcome would be not “I was trying to create crazy, useless, data structure and need to rethink my design” but “Rust is just crazy hard… I almost solved my problem but this stupid compiler just doesn't want to accept my solution”!
Can you elaborate on that requirement? Especially the "live" part? Or perhaps show an example in Javascript or Python?
I ask because perhaps there is a way to achieve the effect you want that is not like using pointers or references as in other languages, but is basically as simple in Rust.
I recall back in the day programmers whined like mad about not being able to use GOTO, hating the restrictions imposed by having to use structured loops in high level languages. One can see Rust's restrictions on borrowing and lifetimes in the same way.
class: the questions asked on the second and third day show that experienced software developers can become comfortable with Rust in a very short time.
