5 ms·

After four months, only 50% of the developers though they were as productive in Rust as other language. Given that the respondents are arguably a very capable

After four months, only 50% of the developers though they were as productive in Rust as other language. Given that the respondents are arguably a very capable group of engineers, this doesn't seem that great for any company looking to adopt Rust.

larsberg 3y ago
Gah! Typo there. It's over 50% (66.8%) in 2 months. And over 80% in 4 months. The chart is correct, not the text :facepalm: I'll see about whether I can push an update. Thanks for the catch!
- larsberg 3y ago
  Actually, it's complicated stuff pulling together two data points: 1) 2/3 of people are confident contributing in 2 months or less 2) And 50% of people are AS PRODUCTIVE IN RUST as they were in their other language within four months Given that #2 is talking about people who are all professional programmers and where only a small percentage of respondents previously knew Rust, that's pretty amazing to me.
summerlight 3y ago
I've been studying C++ over 15+ years and still don't feel very productive thanks to the fear of getting paged every releases.
- criddell 3y ago
  Does Rust give guarantees around paging? Is Rust similar to C++ in that respect?
  - summerlight 3y ago
    At least you won't get paged due to some weird memory bugs. Yes, this happens quite frequently. Worse, it's usually not something local to a single change but interaction across seemingly safe changes.
    - criddell 3y ago
      Is well written Rust code better with respect to paging than well written C++ code?
      - brigadier132 3y ago
        Rust code that compiles gives you certain guarantees that C++ code that compiles does not. The question isn't is well written code in one language better than well written code in another language. The question is, do I know this code is well written? In Rust you know, in C++ you don't without jumping through a bunch of other hoops.
        criddell 3y ago
        What I'm trying to get to is if the guarantees include better control over the heap and paging. Everybody wants to tell me C++ likely has bugs which I understand, but it's not what I'm asking about. Edit: I missed that the original person I responded to was talking about being paged when a problem arises and not about memory performance. I'm still curious though if Rust memory guarantees give the programmer better tools for dealing with memory paging.
        summerlight 3y ago
        Aha, I should've mentioned that it's about getting paged on weekend...
  - shepmaster 3y ago
    FWIW, I believe the person you are replying to means "paged" as in "an alert was sent to my pager at 3AM that the entire system is down and I need to wake up and fix it", not the paging in/out of memory.
    - criddell 3y ago
      Oh wow, I totally missed that. Thanks for clearing it up.
VWWHFSfQ 3y ago
50% seems pretty good to me
stusmall 3y ago
At a past job we generally saw about 6 months until devs hit their stride and worked that into our hiring plans. We usually had them committing small, targeted changes within a week or two. They could usually take on tasks relatively independently in one of our simpler code bases after about 2 months. So this checks out. Weird enough we saw more junior devs pick it up faster. They had less preconceived notions and practices to unlearn and more willing to trust rustc. It's just that when they hit their stride they are still less productive than the senior devs.
- wiz21c 3y ago
  As an older dev: > They had less preconceived notions and practices to unlearn and more willing to trust rustc. this is really what I experiences: rust told me a thing or two about coding I never realized. And it took me pretty long to accept that :-)
  - shadowgovt 3y ago
    I've found Rust useful to study while I'm doing my primary job in C++. A lot of the features Rust offers regarding traits and types can be emulated in C++ with templates, but the way C++ does it is far more obfuscated. Seeing the same thing implemented in Rust helped me wrap my head around what some complicated template nestings were doing ("Oh, this is implementing traits!") in our C++ code.
  - stusmall 3y ago
    Big same. I remember being not being able to share a reference to something allocated on the stack at the start of main to a background thread. I was like "come on, of course its safe. That was allocated before the thread was spawned. It's main. When it returns the application exits" But rustc's error messages helped it click that there might be a race condition on when the application returns from main and the background thread terminates. So it really needs to have the static life time to be safe. It's a small subtle thing but depending on the application it could lead to real bugs. I've definitely written variations of that bug in C before. A newer dev would have just accepted that flat out without arguing.
albntomat0 3y ago
The article states, in the following sentence: “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”
Fidelix 3y ago
"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."
saulrh 3y ago
Consider an alternative reading: 50% of developers think they are as productive in a language they have four months of practice with as they are in a language they have fourteen years of practice with. 50% of developers think they are as productive in a high-performance bit-bashing-capable language as they are in a high-level glue language. The people in this statistic are switching from languages they have years or sometimes decades of productivity in, and they're switching from languages like python and go and java. I see a lot of programmers who do similar switches never reaching productivity parity with C or C++. 50% of devs getting there in 4 months is amazing.
- deleted 3y ago
  [deleted]
- PartiallyTyped 3y ago
  I am willing to bet that the type system and the opinionated way of doing things helps a lot here. Anecdata but I found myself very productive with Haskell when I was learning it for grad school, to the point where I knew that if it compiled, it was most likely right. I had similar experiences though not to that degree with Rust with very little time spent on it in comparison to Haskell. I feel a lot more comfortable sleeping at night over C or Python.
  - tasuki 3y ago
    > Anecdata but I found myself very productive with Haskell when I was learning it for grad school, to the point where I knew that if it compiled, it was most likely right. I recently told this to someone. The very next day my Elm code compiled just fine but it had three relatively tricky logical bugs which took me two hours to find and fix. This was a rare enough occurrence that I remember it. Higher cosmic powers took note of my praise of strong typing and decided to teach me a lesson.
    - PartiallyTyped 3y ago
      Those are always fun! I am a big fan of property based testing for this reason alone!
tensor 3y ago
The more relevant claim is that they don't observe a difference in learning rust vs learning other languages. There is always a learning cost when adopting a new language that few people always know. This sort of surprised me, because rust felt a lot harder for me personally to learn than Go. But data is far more valuable than an anecdote so there you go!
lawn 3y ago
Only four months to become as productive in a new language as in a language they have years or even decades of experience in? Sounds incredible.
tedunangst 3y ago
I don't think that's bad, but it's a big stretch to say 50% at four months debunks the myth of six months.
Kranar 3y ago
Four months to become as proficient in a memory safe, data race safe, and high performance language as in other languages seems like an astonishing accomplishment. In fact it's frankly unbelievable, I'd have to imagine these guys are coming from a C++ background.
- steveklabnik 3y ago
  Anecdotally, C++ developers often have a harder time coming to Rust than folks from a more scripty background. They have to unlearn things, and that can be harder than learning things. You can see similar opinions expressed in this thread, like here, for example: https://news.ycombinator.com/item?id=36496654 https://news.ycombinator.com/item?id=36496654
  - jsgf 3y ago
    Python programmers love Rust: - Lots of compilation errors, but then the code does what it says - Fast! That gives an immediate benefit that people coming from C++ don't see.
  - dureuill 3y ago
    Really? Coming from C++, learning Rust felt very natural and welcome because it put a name and a structure to the mental model I had been using to keep a semblance of sanity while doing C++. Maybe learning primarily with C++11 was a factor?
    - steveklabnik 3y ago
      It's a broad strokes kind of thing, not a universal thing. To be honest I think it has more to do with attitudes towards the language and compiler that tend to be more prevalent in C and C++ circles. That is, a lot of people expect that the compiler is a tool that must do what they say, not a collaborative partner. Back in the IRC days, people used to join, and be like "Rust won't let me do X. X is obviously okay. How do I get the compiler to shut up and do X?" and the reply would be something like "what if there was another thread? that's what Rust is saving you from" or "Rust's pointer rules are different than the language you're used to." Whereas folks from scripty backgrounds don't have preconceived notions of "I should be able to do this in this way," and so tend to trust the compiler more. Heck, that's why a lot of them are learning Rust instead of C; they know the compiler can help them out, and C's compilers cannot to the same degree. Now, that doesn't mean that scripty people don't struggle, or that C and C++ developers don't have their own advantages in learning. Just that I don't think it's straightforward to say who has the overall easier time. It's more of a "having learned something like C or C++ does not universally advantage you."

larsberg 3y ago

Gah! Typo there. It's over 50% (66.8%) in 2 months. And over 80% in 4 months. The chart is correct, not the text :facepalm: I'll see about whether I can push an update. Thanks for the catch!

larsberg 3y ago
Actually, it's complicated stuff pulling together two data points: 1) 2/3 of people are confident contributing in 2 months or less 2) And 50% of people are AS PRODUCTIVE IN RUST as they were in their other language within four months Given that #2 is talking about people who are all professional programmers and where only a small percentage of respondents previously knew Rust, that's pretty amazing to me.

summerlight 3y ago

I've been studying C++ over 15+ years and still don't feel very productive thanks to the fear of getting paged every releases.

criddell 3y ago
Does Rust give guarantees around paging? Is Rust similar to C++ in that respect?
- summerlight 3y ago
  At least you won't get paged due to some weird memory bugs. Yes, this happens quite frequently. Worse, it's usually not something local to a single change but interaction across seemingly safe changes.
  - criddell 3y ago
    Is well written Rust code better with respect to paging than well written C++ code?
    - brigadier132 3y ago
      Rust code that compiles gives you certain guarantees that C++ code that compiles does not. The question isn't is well written code in one language better than well written code in another language. The question is, do I know this code is well written? In Rust you know, in C++ you don't without jumping through a bunch of other hoops.
      - criddell 3y ago
        What I'm trying to get to is if the guarantees include better control over the heap and paging. Everybody wants to tell me C++ likely has bugs which I understand, but it's not what I'm asking about. Edit: I missed that the original person I responded to was talking about being paged when a problem arises and not about memory performance. I'm still curious though if Rust memory guarantees give the programmer better tools for dealing with memory paging.
        summerlight 3y ago
        Aha, I should've mentioned that it's about getting paged on weekend...
- shepmaster 3y ago
  FWIW, I believe the person you are replying to means "paged" as in "an alert was sent to my pager at 3AM that the entire system is down and I need to wake up and fix it", not the paging in/out of memory.
  - criddell 3y ago
    Oh wow, I totally missed that. Thanks for clearing it up.

VWWHFSfQ 3y ago

50% seems pretty good to me

stusmall 3y ago

At a past job we generally saw about 6 months until devs hit their stride and worked that into our hiring plans. We usually had them committing small, targeted changes within a week or two. They could usually take on tasks relatively independently in one of our simpler code bases after about 2 months. So this checks out. Weird enough we saw more junior devs pick it up faster. They had less preconceived notions and practices to unlearn and more willing to trust rustc. It's just that when they hit their stride they are still less productive than the senior devs.

wiz21c 3y ago
As an older dev: > They had less preconceived notions and practices to unlearn and more willing to trust rustc. this is really what I experiences: rust told me a thing or two about coding I never realized. And it took me pretty long to accept that :-)
- shadowgovt 3y ago
  I've found Rust useful to study while I'm doing my primary job in C++. A lot of the features Rust offers regarding traits and types can be emulated in C++ with templates, but the way C++ does it is far more obfuscated. Seeing the same thing implemented in Rust helped me wrap my head around what some complicated template nestings were doing ("Oh, this is implementing traits!") in our C++ code.
- stusmall 3y ago
  Big same. I remember being not being able to share a reference to something allocated on the stack at the start of main to a background thread. I was like "come on, of course its safe. That was allocated before the thread was spawned. It's main. When it returns the application exits" But rustc's error messages helped it click that there might be a race condition on when the application returns from main and the background thread terminates. So it really needs to have the static life time to be safe. It's a small subtle thing but depending on the application it could lead to real bugs. I've definitely written variations of that bug in C before. A newer dev would have just accepted that flat out without arguing.

albntomat0 3y ago

The article states, in the following sentence: “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”

Fidelix 3y ago

"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."

saulrh 3y ago

Consider an alternative reading: 50% of developers think they are as productive in a language they have four months of practice with as they are in a language they have fourteen years of practice with. 50% of developers think they are as productive in a high-performance bit-bashing-capable language as they are in a high-level glue language. The people in this statistic are switching from languages they have years or sometimes decades of productivity in, and they're switching from languages like python and go and java. I see a lot of programmers who do similar switches never reaching productivity parity with C or C++. 50% of devs getting there in 4 months is amazing.

deleted 3y ago
[deleted]
PartiallyTyped 3y ago
I am willing to bet that the type system and the opinionated way of doing things helps a lot here. Anecdata but I found myself very productive with Haskell when I was learning it for grad school, to the point where I knew that if it compiled, it was most likely right. I had similar experiences though not to that degree with Rust with very little time spent on it in comparison to Haskell. I feel a lot more comfortable sleeping at night over C or Python.
- tasuki 3y ago
  > Anecdata but I found myself very productive with Haskell when I was learning it for grad school, to the point where I knew that if it compiled, it was most likely right. I recently told this to someone. The very next day my Elm code compiled just fine but it had three relatively tricky logical bugs which took me two hours to find and fix. This was a rare enough occurrence that I remember it. Higher cosmic powers took note of my praise of strong typing and decided to teach me a lesson.
  - PartiallyTyped 3y ago
    Those are always fun! I am a big fan of property based testing for this reason alone!

tensor 3y ago

The more relevant claim is that they don't observe a difference in learning rust vs learning other languages. There is always a learning cost when adopting a new language that few people always know. This sort of surprised me, because rust felt a lot harder for me personally to learn than Go. But data is far more valuable than an anecdote so there you go!

lawn 3y ago

Only four months to become as productive in a new language as in a language they have years or even decades of experience in? Sounds incredible.

tedunangst 3y ago

I don't think that's bad, but it's a big stretch to say 50% at four months debunks the myth of six months.

Kranar 3y ago

Four months to become as proficient in a memory safe, data race safe, and high performance language as in other languages seems like an astonishing accomplishment. In fact it's frankly unbelievable, I'd have to imagine these guys are coming from a C++ background.

steveklabnik 3y ago
Anecdotally, C++ developers often have a harder time coming to Rust than folks from a more scripty background. They have to unlearn things, and that can be harder than learning things. You can see similar opinions expressed in this thread, like here, for example: https://news.ycombinator.com/item?id=36496654 https://news.ycombinator.com/item?id=36496654
- jsgf 3y ago
  Python programmers love Rust: - Lots of compilation errors, but then the code does what it says - Fast! That gives an immediate benefit that people coming from C++ don't see.
- dureuill 3y ago
  Really? Coming from C++, learning Rust felt very natural and welcome because it put a name and a structure to the mental model I had been using to keep a semblance of sanity while doing C++. Maybe learning primarily with C++11 was a factor?
  - steveklabnik 3y ago
    It's a broad strokes kind of thing, not a universal thing. To be honest I think it has more to do with attitudes towards the language and compiler that tend to be more prevalent in C and C++ circles. That is, a lot of people expect that the compiler is a tool that must do what they say, not a collaborative partner. Back in the IRC days, people used to join, and be like "Rust won't let me do X. X is obviously okay. How do I get the compiler to shut up and do X?" and the reply would be something like "what if there was another thread? that's what Rust is saving you from" or "Rust's pointer rules are different than the language you're used to." Whereas folks from scripty backgrounds don't have preconceived notions of "I should be able to do this in this way," and so tend to trust the compiler more. Heck, that's why a lot of them are learning Rust instead of C; they know the compiler can help them out, and C's compilers cannot to the same degree. Now, that doesn't mean that scripty people don't struggle, or that C and C++ developers don't have their own advantages in learning. Just that I don't think it's straightforward to say who has the overall easier time. It's more of a "having learned something like C or C++ does not universally advantage you."