Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022
opensource.googleblog.com
Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022
1–10 of 233 posts
Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022
#2Great post. Aligns with my experiences. Although who thought unsafe would be bigger hurdle than borrowing.
I do wish to know did Rust impact their velocity and by how much.
Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022
#3"The top three challenging areas of Rust for current Google developers were:
* Macros
* Ownership and borrowing
* Async programmingAsync 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 developers prefer.
It would be really nice if the Rust standard library were to get structured concurrency similar to what Ada has:
https://en.wikibooks.org/wiki/Ada_Style_Guide/Concurrency
https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Devel...
Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022
#4Great post. Aligns with my experiences. Although who thought unsafe would be bigger hurdle than borrowing. I do wish to know did Rust impact their velocity and by how much.
I think Google has a lot of C++ programmers who may have assumed they'd have to use unsafe so they could continue to write everything like they did in C++ (much like many refuse to use features that aren't from ancient versions of C when writing C++), but then likely in practice ended up writing much less unsafe code than they thought they would.
Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022
#5"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
Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022
#6"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…
> 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 developers prefer.
This seems to be an repeated antipattern with a lot of languages/ecosystems, resulting in fragmented and half-baked solutions. A fully-featured async standard library involves making a lot of opinion-based decisions, and not everyone will be happy. But it's better for 80% of people who probably don't care that much, and nothing stops the other 20% from implementing libraries for their use-cases.
Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022
#7"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
That is never going to happen, for both good reasons and bad reasons.
Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022
#8After 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.
Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022
#9Re: Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022
#10Really 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.