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

61–70 of 233 posts

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

#61

Post by sanxiyn »

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…

While I think n>1000 data points on Rust learning curve is informative, I think build time complaint is less so.

This being Google, it probably means something like "this C++ build takes 24 hours locally, but thanks to magical distributed build infrastructure it completes in 10 minutes, whereas Rust build takes 18 hours locally but even with magic does not complete in under 30 minutes, which is too long". That is important to Google, but it is almost completely irrelevant to anyone outside Google.

It is unclear to me whether improving rustc performance is the right solution to Google's problem. It is probable working on Rust integration to Google's build infrastructure is higher ROI than working on rustc.

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

#62

Post by steveklabnik »

belval wrote: post #51
steveklabnik wrote: post #25

Earlier quoted context omitted.

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…

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

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

#63

Post by softirq »

ljlolel wrote: post #39
softirq wrote: post #30

> Low-level Operating Systems Sr. User Experience Researcher Wow, I didn't even know this job existed. IMO Rust as a C++ replacement is fine, Rust as a C replacement has more trade-offs than I still care to make. C is still far simpler (you can still read K&R in one day and keep most of the language in your head), has faster compile times, and the pain points cough macros are still often pain points in Rust. I think…

Try Zig as a C replacement.

I'm not really looking for a replacement for C, the ecosystem of system programming is still really C centric, it would take a large shift in the industry for me to justify investing in another language. I've dabbled with Rust only because early support was merged into Linux. IMO most languages are only marginal improvements over the previous generation that don't outweigh fighting against the entrenchment of expertise, documentation, and integration that come with established languages. It's also hard to be a true expert at a low level domain and multiple programming languages unless you're willing to give up all of your free time.

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

#64

Post by steveklabnik »

c_crank wrote: post #50
steveklabnik wrote: post #25

Earlier quoted context omitted.

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

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.

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.

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

#65

Post by bfrog »

softirq wrote: post #30

> Low-level Operating Systems Sr. User Experience Researcher Wow, I didn't even know this job existed. IMO Rust as a C++ replacement is fine, Rust as a C replacement has more trade-offs than I still care to make. C is still far simpler (you can still read K&R in one day and keep most of the language in your head), has faster compile times, and the pain points cough macros are still often pain points in Rust. I think…

You can and do use simple pointers in Rust, nothing prevents this.

The abstractions can be more used like static interfaces you want to reuse. E.g. a byte stream interface, a regmap interface, etc.

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

#66

Post by arijun »

Animats wrote: post #37
VWWHFSfQ wrote: post #5

Earlier quoted context omitted.

rust team needs to abandon their own execution runtime and just bless tokio and pull it into std. They're doing nobody any favors right now

I'm struggling to get tokio out of my executable. I'm not using it, but stuff keeps pulling it in. Async contamination is a huge problem. For highly concurrent code with threads running at different priority levels, if async gets in there it makes a mess.

Sorry if this is ignorant, but what’s the difference between async and concurrent? Is the problem that async schedules everything itself?

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

#67

Post by gpderetta »

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…

I vastly prefer stackful coroutines than stackless, but of all the languages, rust is probably the one that can justify that decision the most.

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

#68

Post by steveklabnik »

izacus wrote: post #45
steveklabnik wrote: post #25

Earlier quoted context omitted.

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

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.

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?

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

#69

Post by jrockway »

Animats wrote: post #37
VWWHFSfQ wrote: post #5

Earlier quoted context omitted.

rust team needs to abandon their own execution runtime and just bless tokio and pull it into std. They're doing nobody any favors right now

I'm struggling to get tokio out of my executable. I'm not using it, but stuff keeps pulling it in. Async contamination is a huge problem. For highly concurrent code with threads running at different priority levels, if async gets in there it makes a mess.

You know what they say about libraries; if you're not having problems, you're not using enough of them.

On a more serious note, "I want other people to write my code, but they're not following my standards" is rarely a sympathetic point of view.

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

#70

Post by summerlight »

criddell wrote: post #54
summerlight wrote: post #38

Earlier quoted context omitted.

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?

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