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

51–60 of 233 posts

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

#51

Post by belval »

steveklabnik wrote: post #25
izacus wrote: post #23

Earlier quoted context omitted.

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.

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

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.

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

#52

Post by wredue »

IshKebab wrote: post #46
epage wrote: post #34

> Rumor 2: The Rust compiler is not as fast as people would like – Confirmed ! I wish there was more context to these, especially this one. For example, how much of this is perception compared to what they were used to (go?, Python?, C++?)? Or is it "any waiting is bad"? From an improvement perspective, I'd also love to know why their builds are slow. Is it proc-macro heavy? Do they have wide and deep dependency grap…

Yeah most of these results are meaningless without comparison to other languages. Same with the "how quick is it to learn?" what are the equivalent numbers of Go? Based on my experience they're overselling how easy it is to learn and underselling the compiler speed. Compilation is fairly fast these days. I would say it's faster than C++ feature-for-feature, at least for clean builds. But on the other hand most people…

[flagged]

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

#53

Post by shellac »

no_wizard wrote: post #20
thesuperbigfrog wrote: post #3

"The top three challenging areas of Rust for current Google developers were: * Macros * Ownership and borrowing * Async programming " Async programming is the area I would like to see the most improvement, especially in the standard library. So much concurrent and parallel Rust code relies on third-party libraries because the standard library offers primitives that work but lack the "creature comforts" that developer…

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…

For many languages I absolutely agree: stackful coroutines are the way to go since the programmer experience is much smoother, with fewer hiccups like having different kinds of functions, or being unable to yield in loops. Lua, Go, and now Java got this right; python, javascript, and c# have to live with a bit of a mess.

But Rust is not a language which can dictate its execution environment. It needs to be able to exist in a C-ish world, and that's not something that supports yielding. It's a shame, but at least you can write kernel modules in Rust.

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

#54

Post by criddell »

summerlight wrote: post #38
durandal1 wrote: post #8

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.

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

Does Rust give guarantees around paging? Is Rust similar to C++ in that respect?

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

#55

Post by tracker1 »

epage wrote: post #34

> Rumor 2: The Rust compiler is not as fast as people would like – Confirmed ! I wish there was more context to these, especially this one. For example, how much of this is perception compared to what they were used to (go?, Python?, C++?)? Or is it "any waiting is bad"? From an improvement perspective, I'd also love to know why their builds are slow. Is it proc-macro heavy? Do they have wide and deep dependency grap…

Hard for me to directly compare, but Rust builds that I have experienced have been comparable to large Node/npm projects built with webpack (JS tooling). Totally different space and output, but comparible.

The long dependency trees are part of it, but usually not too bad and only really bad the first time, since you don't have to rebuild every crate every time (I could be wrong, but it seems that way). I haven't been using it day in, day out though. I've installed a few apps via cargo, and have done some experiments for service applications, and Tauri as well.

As for the day to day use and how painful it is... I haven't had enough exposure to really comment on... it seems "fast enough" but I'm not running compiles often enough, simply because my knowledge and experience aren't really great in Rust. I've looked at it and played with it a few times, then I set it aside for months at a time and every time it's like I'm starting over.

Where I'm working now, there are some serious issues that may result in areas needing better start time on services, so that may be an opportunity to advocate for Rust. I've never really loved C or C++, so I'm less inclined to want to use them.

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

#56

Post by steveklabnik »

Kranar wrote: post #49
durandal1 wrote: post #8

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.

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

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

#58

Post by nu11ptr »

no_wizard wrote: post #20
thesuperbigfrog wrote: post #3

"The top three challenging areas of Rust for current Google developers were: * Macros * Ownership and borrowing * Async programming " Async programming is the area I would like to see the most improvement, especially in the standard library. So much concurrent and parallel Rust code relies on third-party libraries because the standard library offers primitives that work but lack the "creature comforts" that developer…

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…

While I agree and would prefer green threads to async myself, I believe Rust chose async/await because it was shown the former could not be done as a "zero cost" abstraction and didn't interop with C well (somebody correct me if I'm wrong on that).

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

#59

Post by nicoburns »

IshKebab wrote: post #46
epage wrote: post #34

> Rumor 2: The Rust compiler is not as fast as people would like – Confirmed ! I wish there was more context to these, especially this one. For example, how much of this is perception compared to what they were used to (go?, Python?, C++?)? Or is it "any waiting is bad"? From an improvement perspective, I'd also love to know why their builds are slow. Is it proc-macro heavy? Do they have wide and deep dependency grap…

Yeah most of these results are meaningless without comparison to other languages. Same with the "how quick is it to learn?" what are the equivalent numbers of Go? Based on my experience they're overselling how easy it is to learn and underselling the compiler speed. Compilation is fairly fast these days. I would say it's faster than C++ feature-for-feature, at least for clean builds. But on the other hand most people…

> Compilation is fairly fast these days. I would say it's faster than C++ feature-for-feature, at least for clean builds.

Faster than C++ is of course very faint praise. C++ is also very slow!

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

#60

Post by nmlt »

estebank wrote: post #10

Really happy to see these results on the perception of googlers on quality of the Rust compiler errors, an area I'm highly passionate about. I'd like to take this as an opportunity to encourage the 9% (and the other 91% as well) to file tickets when we don't meet the bar we've set for ourselves.

I haven’t tried debugging with lldb in some time so I don’t know whether it has improved significantly, but couldn’t the 9% also include that?
Post reply on HN