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

31–40 of 233 posts

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

#31

Post by wiz21c »

stusmall wrote: post #15
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.

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

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

#32

Post by tedunangst »

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 don't think that's bad, but it's a big stretch to say 50% at four months debunks the myth of six months.

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

#33

Post by [deleted] »

saulrh wrote: post #19
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.

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

[deleted]

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

#34

Post by epage »

> 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 graphs? Do they have large individual crates? And so on.

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

#35

Post by loudmax »

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…

Are tracking memory allocation or variable types not pain points for large complicated programs?

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

#36

Post by giraffe_lady »

jimbob45 wrote: post #12
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…

Is there any Rust outfit out there that doesn't discourage macro use? For that matter, is there any team with a language out there that encourages macro use when working as a team?

I've never seen a team that encouraged writing new macros to solve routine problems. But I've certainly been on teams that made heavy use of a few carefully deployed macros to solve recurring problems specific to that codebase.

I think elixir's sigils are probably the closest thing I've seen to "routine, encouraged macro use." Since almost every application will end up with a bit of template lite almost-dsl pseudo language for something or other. They're simpler than defining a grammar & writing a parser and more maintainable than regex.

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

#37

Post by Animats »

VWWHFSfQ wrote: post #5
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…

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.

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

#38

Post by summerlight »

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.

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

#39

Post by ljlolel »

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.

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

#40

Post by shadowgovt »

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

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.

Post reply on HN