[bigyikes]

> Rumor 5: Rust code is high quality – Confirmed!

> The respondents said that the quality of the Rust code is high — 77% of developers were satisfied with the quality of Rust code.

Well, that’s exactly what I’d expect Rust developers to say. Nobody loves Rust more than Rust adopters. Would be interesting to see more objective measures of code quality (e.g. defect rate)

Also, the type of person to work on a Rust codebase might also be more likely to write high quality code in any language, as compared to the average developer (or even average Googler).

[steveklabnik]

People used to say "when people are forced to use Rust at their job, they'll start hating it, only hobbyists use it and that's why it's so beloved." Do you really consider people learning Rust on the job to be "Rust adopters" who are partisan? Is anyone who ever uses Rust a "Rust adopter" who is unable to give an unbiased opinion? Who would be able to give that opinion, in your view?

[izacus]

People who are adopting Rust now at their jobs are in most majority people who are so keen on using Rust to push it into organizational adoption. Most companies don't yet have legacy Rust codebases on which people are told to work, but instead choose to work on.

This creates a self-selection, where Rust lovers work on Rust projects and report utopian happy-go-lucky times. It's normal for most technologies.

[steveklabnik]

Do you think all 1,000 people that Google referenced here are people who are pushing it into organizational adoption?

[belval]

It seems likely that the overwhelming majority of those 1000 people are pushing it into organizational adoption. Rust is not used enough yet that anyone will be forced to use it. Older C++ programmers at Google who are uninterested in moving aren't doing Rust.

As a parallel. A team using Scala at Amazon likely uses it because everyone (let's say 90%) was on board. It's just not something you force on your team unless there is existing interest.

Finally (an perhaps more importantly), the parent comment also mentioned older codebases. It does not seem likely anyone of those 1000 is currently doing maintenance so much as completely new projects/features. This tends to be work software developers enjoy more irrespective of language. So if you were pulled from maintenance in C++ to work on something new in Rust I'm pretty sure you'll say Rust is great just because you feel more productive.

[steveklabnik]

> Rust is not used enough yet that anyone will be forced to use it.

Google hired Ferrous Systems to train employees, as well as writing their own training curriculum. That sounds to me like people who would not otherwise use Rust being asked to use it at their job, and their job investing in their skills because they wouldn't or hadn't done it on their own. Is that different than "forced to use it"?

> It does not seem likely anyone of those 1000 is currently doing maintenance so much as completely new projects/features.

Google has been using Rust in android since 2019. That's four years. That is of course not "legacy" in any large sense, but at what point for you is something legacy? Does none of that work over four years count as "maintenance"?

> So if you were pulled from maintenance in C++ to work on something new in Rust I'm pretty sure you'll say Rust is great just because you feel more productive.

The start of this sub-thread, and a lot of the discussion inside of it, implies that people are using Rust simply because they want to, and not because it provides actual advantages. Is your position here that the sole advantage of Rust over C++ is that since projects are newer, they're better to work on? And if so, is that advantage illegitimate?

[belval]

The first two points I don't really have anything to add on.

> Is your position here that the sole advantage of Rust over C++ is that since projects are newer, they're better to work on? And if so, is that advantage illegitimate?

No, to rephrase, I think that maintenance work on average feels less productive and more grueling because you can spend 3 days debugging for a single line change. With a new project (or any new feature) you get to write your own thing which feels more productive.

I'm not saying people are less productive with Rust than C++. I am pointing out that there is a natural bias in the type of work that those two languages are being used for at Google and that this bias will impact self-assessed productivity.

> Does none of that work over four years count as "maintenance"?

Respectfully I think you are building a strawman because you (likely) work with Rust and enjoy it. Google is built on a staggering amount of 10-20 years old C++ codebases that have seen several runs of refactoring at this point and stand on the critical path of several of their most important products. Working on those is inherently slower and more meticulous than writing new Android features (even if 4 years old) in Rust.

[c_crank]

Going by stackoverflow surveys, the majority of younger engineers would be happier to see it implemented than not, regardless of whether they've even used the language before.

[steveklabnik]

The "most loved" statistic (which they have since renamed) counts people who have used Rust before, and want to continue using it. Unless you're suggesting that they're all lying, I don't see how that connects to "regardless of whether they've even used the langauge."

Furthermore, at least in 2023, only ~25% of respondants are under 25. I'm not sure what counts as "younger" to you, but 37% are over 35, so it would seem that the survey skews older, not younger, to me anyway.

EDIT: since you're now flagged into oblivion (I tried to vouch for you but it didn't work), that statistic is what they changed "most loved" from. It counts people who have used Rust before, and want to continue using it.

[izacus]

Mostly? Yes. Google has more than 120.000 engineers. Those 1000 are less than 1% of engineers. It's like having one Rust dude in a 100 person company.

Most of people work in other languages.

[steveklabnik]

The blog post says only 13% of these people have had experience with Rust before joining Google. How do you think Google ended up with so many people who are hardcore evangelists, imposing their views on others? A significant focus of the post is about on-the-job training; do you think that these evangelists were created by these trainings, or did they come to these opinions on their own, and are now pushing for it inside of Google?

Did Google only interview these Rust-loving developers, and none of the people they're supposedly pushing Rust upon?

[izacus]

What on earth are you trying to say here?

I'm just saying that Rust fans are currently self-selecting by choosing to work on Rust projects which skews the satisfaction numbers against other languages.

That doesn't have a lot to do with previous experience - with Rust being so new, __MOST__ developers, even fans, don't have much experience with it.

[bigyikes]

> Do you really consider people learning Rust on the job to be "Rust adopters" who are partisan?

Not necessarily, but it seems not unlikely.

> Is anyone who ever uses Rust a "Rust adopter" who is unable to give an unbiased opinion?

It’s still a relatively new and niche language, so, yes.

> Who would be able to give that opinion, in your view?

Nobody, and maybe that’s my real point, which is why I’d like some metrics to supplement the anecdotes. This especially applies to Rust, but I think also applies to any language.

Note that I don’t mean to imply that there isn’t value in anecdotes. There is.

[sanxiyn]

I agree the post could include more concrete metrics than self-assessment, but more than 1000 data points, even self-assessment data points, are usually not called anecdotes.

[steveklabnik]

> Nobody, and maybe that’s my real point

To be honest, this is what I've taken away from this conversation so far: it doesn't seem like anything will satisfy your desires here.

> which is why I’d like some metrics to supplement the anecdotes

This conversation started with you not liking that the measure of quality is subjective, which is fine. How would you objectively measure code quality though? What metrics would you have preferred to see, other than the ones in this post?

[bigyikes]

I’m confused by your line of questioning. Why do you think I can’t be satisfied?

I don’t have a problem with this Google poll. I think it is valuable.

What would satisfy my desires is exactly what I stated in my original comment: something more objective, like defect rates of Rust code bases compared to non-Rust ones. Metrics like these have their owns problems, but would be a nice supplement to the opinion-based poll.

Neither the objective metrics, nor the opinion poll can provide a complete picture, and neither is a substitute for the other. Both would be awesome.

[steveklabnik]

Because you said

> It’s still a relatively new and niche language, so, yes.

If nobody is able to give a non-partisan reply, I don't see how you could ever be satisfied.

> like defect rates of Rust code bases compared to non-Rust ones.

Cool, thanks. That does seem like one that is more objective, though there are confounding factors in that too, because sometimes defects lurk without being detected. This stuff is hard!

Google did put out something about this specifically on Rust (and others) use in Android, by the way, you might find that interesting: https://security.googleblog.com/2022/12/memory-safe-language...

[scoutt]

> As an engineering manager...

> unbiased opinion

If the engineering manager after putting so much effort into switching to Rust, and trying to convince upper levels, putting their head at risk and after busting balls for months to make everyone learn Rust, comes into the office one day and asks if we love Rust, we the 77% that want to keep our jobs would answer "OF COURSE WE DO!!!!! COULDN'T BE HAPPIER!!!", with a big smile.

[tasuki]

This hasn't been my experience at all.

Me and all the other developers I know complain endlessly about the tools we're forced to use. We complain to anyone patient enough to listen, including all the engineering managers. No one I know ever got fired or laid off for this.

[saulrh]

It's a bit unfortunate that they aren't sharing this statistic for other languages. For example, I'd bet that rather fewer than 77% of Google C++ devs are satisfied with the quality of C++ code. I know that, when I was at Google, I wouldn't have reported satisfaction with the quality of my own C++ code!

[summerlight]

> Well, that’s exactly what I’d expect Rust developers to say. Nobody loves Rust more than Rust adopters.

An increasing number of Android developers in Google are adopting Rust because of the org wide strategy rather than developer passion, so I guess the numbers in 2023 and 2024 would be more interesting to see.

[hbn]

Also since it's a young language, a lot of these people are probably writing in a newer codebase that doesn't have 15 years of early fundamental bad decisions and hacky refactors to make it painful to work in.

[mannyv]

I'm sure there are developers who are like "wow, the quality of my code sucks in this language." But I'm not sure where they work and what they do.