250 points · 224 comments · 2 years ago · rhaen
opensource.googleblog.comestebank
softirq
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 the biggest thing is that systems programming still requires a language that gets out of the way so you can focus on very technical problem domains where what the hardware is actually doing really matters. Rust is a language designed to get in your way and force you to create type abstractions. Adding too many abstraction can be exceedingly dangerous in an environment where not having a full view of how memory and hardware registers are laid out leads to even worse errors than just buffer overflows. IMO Rust makes this type of programmer more difficult just as C++ does.
thesuperbigfrog
* 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 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...
bigyikes
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 codebase might also be more likely to write high quality code in any language, as compared to the average developer (or even average Googler).
durandal1
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.
predictabl3
Some of the stuff people say about Rust reminds me of iOS users talking about Android. "Tell me you are operating from a place of near total ignorance, without telling me that you're talking out your butt".
See: the number of people, here, acting like you can't do raw pointers in Rust, or acting like it's militant woke youngins forcing poor big Google to adopt a safer, productive language.
Ygg2
I do wish to know did Rust impact their velocity and by how much.
pvorb
AtNightWeCode
hgs3
pcthrowaway
But this is Google, and the people doing self-assessments were likely influenced by the context of operating in cut-throat bureaucracy where self-aggrandisement is a requisite to career progression within the org.
Whether or not this survey was tied to any performance evaluation (and from the article it's not even clear that it wasn't) the relevant thing is whether the employees knew without a doubt that they weren't going to be compared against one another based on their self-assessment
edit: I'm curious if the people downvoting disagree with my assertion that the survey methodology is flawed, or the assertion that it's unlikely to become as competent in rust in 2 months as you would be in languages you have years of experience with.