Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

opensource.googleblog.com

Post reply on HN
Print view View original

141–150 of 233 posts

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#141

Post by steveklabnik »

bigyikes wrote: post #127
steveklabnik wrote: post #21

Earlier quoted context omitted.

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?

> 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…

> 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?

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#142

Post by bigyikes »

steveklabnik wrote: post #141
bigyikes wrote: post #127

Earlier quoted context omitted.

> 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…

> 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…

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.

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#143

Post by belval »

steveklabnik wrote: post #62
belval wrote: post #51

Earlier quoted context omitted.

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…

> 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 see…

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.

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#144

Post by steveklabnik »

belval wrote: post #143
steveklabnik wrote: post #62

Earlier quoted context omitted.

> 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 see…

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…

Thanks.

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#145

Post by steveklabnik »

bigyikes wrote: post #142
steveklabnik wrote: post #141

Earlier quoted context omitted.

> 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…

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 pol…

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

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#146

Post by stusmall »

wiz21c wrote: post #31
stusmall wrote: post #15

Earlier quoted context omitted.

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 pr…

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 :-)

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.

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#147

Post by rascul »

littlestymaar wrote: post #80
no_wizard wrote: post #20

Earlier quoted context omitted.

Color functions are just not the right road to go down. Something akin to Javas new green threads would be better, or Go style coroutines. The path Rust is going means async becomes viral, and is something I dislike a lot about JavaScript[0] and other languages I’ve worked in[1]. I’d love to see Rust avoid this trap. [0]: I work in TypeScript in actuality not sure which to use here. It’s certainly by far the language…

I really wish people stopped using this concept of “function colors”, especially in the context of Rust because the `async fn`/“regular function” split is strictly equivalent to the `try_something()`/`something()` split (the first one being fallible and returning a `Result` in case of failure). `Result`s and `Option`s are coloring the stack in exactly the same way a `Future` does (and `async` is pure syntactic sugar…

> not a struct like `Result`

Minor nitpick, but it's an enum.

https://github.com/rust-lang/rust/blob/master/library/core/s...

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#148

Post by littlestymaar »

rascul wrote: post #147
littlestymaar wrote: post #80

Earlier quoted context omitted.

I really wish people stopped using this concept of “function colors”, especially in the context of Rust because the `async fn`/“regular function” split is strictly equivalent to the `try_something()`/`something()` split (the first one being fallible and returning a `Result` in case of failure). `Result`s and `Option`s are coloring the stack in exactly the same way a `Future` does (and `async` is pure syntactic sugar…

> not a struct like `Result` Minor nitpick, but it's an enum. https://github.com/rust-lang/rust/blob/master/library/core/s...

Indeed, thank you. (and since it's now been 2h since I posted this, my stupid mistake will live forever)

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#149

Post by mannyv »

bigyikes wrote: post #14

> 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 codeb…

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.

Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022

#150

Post by dureuill »

steveklabnik wrote: post #56
Kranar wrote: post #49

Earlier quoted context omitted.

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.

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

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?
Post reply on HN