Thank a lot for posting it! Thanks also to everyone who have been sending PRs to us since we published the course. We’re overwhelmed by the positive reception by the Rust community!
I wrote the course and I hope it’ll be useful to others who are learning Rust. I think the material can be especially useful for people who need to teach Rust: there is now a ready-to-use course which will bring people up to a fairly advanced level. They won’t be experts, but they’ll have seen most of the syntax, they’ll have seen more complex things like generics, traits and a bit of unsafe. Most importantly, they will have written a few hundred lines of Rust code.
Why is Android putting out a Rust course? Because we’ve been using Rust for a few years in the Android Platform and we want to help our engineers onboard with Rust. For years, a majority of our security vulnerabilities have come from memory safety issues. By using Rust, we can eliminate this class of vulnerabilities.
Do you have any thoughts about the best way to use Rust to write full Android apps, particularly the GUI portion of those apps? I’ve been a Rust programmer for many years but I don’t have much experience with any kind of mobile development. I’d like to be able to write an Android app in pure Rust without having to use a browser-based rendering library or write code in Rust that uses FFI to talk to a native Kotlin or Java app (which I don’t have much experience with in any case). I’m not sure to what degree this is possible as of late 2022.
Hi there! I’m afraid I’m pretty much the same boat as you :-) I’m a Rust developer, but I know very little about Android apps. My understanding is that the community is still working on the best way to use Rust in apps, but it’s not something I’ve been following closely yet.
Ok so maybe I shouldn’t be writing this comment, but honestly, ever since working for Google post-covid, I just can’t take anything they put out seriously anymore. That company is so broken I just don’t trust the quality of the engineers that work there. Like, the Google brand name is a negative for me at this point. There’s way better resources for this kind of thing.
Surely it is useful in conveying the probable quality of the guide, sparing people wasted days.
I came here to see if anyone had opinions on the quality, because I looked at the Kubernetes code some years back, was shocked at the poor quality, and dumbfounded that people were running their businesses on it - so if it says google, I want opinions on quality before getting involved. Given increasing consensus on google I will skip this guide.
No, it’s not. Google is an enormous company. There is always going to be a range of quality.
Maybe OP was in a bad team. Maybe OP has a sour taste in their mouth. Maybe you have misjudged Kubernetes because it does very much appear to work for enterprise level companies.
I think it’s a bad way to go to dismiss an artifact from a large company out of hand simply because of the quality of something else. I have no love for Windows but I think Microsoft is killing it with Xbox.
Half of the reason anyone cares about this guide at all is because it is coming from Google.
It’s very disingenuous to say “don’t say negative things about Google, it’s not relevant” when a major reason we are discussing this guide in the first place is because of Google’s positive reputation.
I’ve heard some similar things about Google in the past several years; that said, do you think that any issues with the quality of Google engineers broadly-speaking is relevant to this Rust guide? I skimmed it and it seemed like a reasonable enough way to get programmers who have no prior Rust experience up to speed with the language reasonably quickly. I didn’t notice any major problems with it, certainly.
I didn’t read it. I’m not saying the guide is bad. It might be good. I’m just not willing to give it a chance, there are other guides out there that are not associated with Google.
Maybe I’m wrong in this instance, but I only have one life to live. I need some kind of filter.
Thanks for being brave enough to say this. I feel obligated to back you up even though this might not be a great idea for me either.
Where to begin? A few snippets: I worked at Apple with a former senior (staff?) Google engineer who had been internally certified at Google as a Python style reviewer.
His code reviews were the absolute worst I have ever seen: he’d leave a dozen comments about the order in which variables were declared, and zero comments about actual engineering. For points of reference: at Mozilla people would leave lots of comments about style, but left even more about substance. At Figma people had a culture of leaving style to automatic tools as much as possible and had an extreme focus on substance.
The same guy refused to use an autoformatter. His friend put up a nontrivial PR at noon, he rubber stamped it literally 5 minutes later, then they complained to our manager about how I didn’t review it. I could share so much more that’s even worse from my experience with this and other Googlers, but it wouldn’t be relevant to programming language style guides and code review.
Lots of excellent people work at Google. But Google also has a subculture of cliquish freeloaders who obsess over style and language guides to obscure the amount of work that they’re actually doing. It’s not that they do no work at all: maybe 30% of their work and reputation comes from style guides and politics rather than actual work. But they will simultaneously act as if that gives them more authority rather than less.
In college I was a fan of the Google Python Language Guide and others, but after seeing the culture they bring along firsthand I now think they’re a red flag.
Thank a lot for posting it! Thanks also to everyone who have been sending PRs to us since we published the course. We’re overwhelmed by the positive reception by the Rust community!
I wrote the course and I hope it’ll be useful to others who are learning Rust. I think the material can be especially useful for people who need to teach Rust: there is now a ready-to-use course which will bring people up to a fairly advanced level. They won’t be experts, but they’ll have seen most of the syntax, they’ll have seen more complex things like generics, traits and a bit of unsafe. Most importantly, they will have written a few hundred lines of Rust code.
Why is Android putting out a Rust course? Because we’ve been using Rust for a few years in the Android Platform and we want to help our engineers onboard with Rust. For years, a majority of our security vulnerabilities have come from memory safety issues. By using Rust, we can eliminate this class of vulnerabilities.
Do you have any thoughts about the best way to use Rust to write full Android apps, particularly the GUI portion of those apps? I’ve been a Rust programmer for many years but I don’t have much experience with any kind of mobile development. I’d like to be able to write an Android app in pure Rust without having to use a browser-based rendering library or write code in Rust that uses FFI to talk to a native Kotlin or Java app (which I don’t have much experience with in any case). I’m not sure to what degree this is possible as of late 2022.
Hi there! I’m afraid I’m pretty much the same boat as you :-) I’m a Rust developer, but I know very little about Android apps. My understanding is that the community is still working on the best way to use Rust in apps, but it’s not something I’ve been following closely yet.
Ok so maybe I shouldn’t be writing this comment, but honestly, ever since working for Google post-covid, I just can’t take anything they put out seriously anymore. That company is so broken I just don’t trust the quality of the engineers that work there. Like, the Google brand name is a negative for me at this point. There’s way better resources for this kind of thing.
I think, as you say, that you should not be writing this comment; I can’t see how this is valuable:
Surely it is useful in conveying the probable quality of the guide, sparing people wasted days. I came here to see if anyone had opinions on the quality, because I looked at the Kubernetes code some years back, was shocked at the poor quality, and dumbfounded that people were running their businesses on it - so if it says google, I want opinions on quality before getting involved. Given increasing consensus on google I will skip this guide.
No, it’s not. Google is an enormous company. There is always going to be a range of quality.
Maybe OP was in a bad team. Maybe OP has a sour taste in their mouth. Maybe you have misjudged Kubernetes because it does very much appear to work for enterprise level companies.
I think it’s a bad way to go to dismiss an artifact from a large company out of hand simply because of the quality of something else. I have no love for Windows but I think Microsoft is killing it with Xbox.
Half of the reason anyone cares about this guide at all is because it is coming from Google.
It’s very disingenuous to say “don’t say negative things about Google, it’s not relevant” when a major reason we are discussing this guide in the first place is because of Google’s positive reputation.
I’ve heard some similar things about Google in the past several years; that said, do you think that any issues with the quality of Google engineers broadly-speaking is relevant to this Rust guide? I skimmed it and it seemed like a reasonable enough way to get programmers who have no prior Rust experience up to speed with the language reasonably quickly. I didn’t notice any major problems with it, certainly.
I didn’t read it. I’m not saying the guide is bad. It might be good. I’m just not willing to give it a chance, there are other guides out there that are not associated with Google.
Maybe I’m wrong in this instance, but I only have one life to live. I need some kind of filter.
Thanks for looking at the course! If you do find problems, please don’t hesitate to open issues and/or to send PRs my way via https://github.com/google/comprehensive-rust.
How is this related to the quality of the linked Rust guide?
Would you mind sharing those? Otherwise your comment is not very helpful.
Thanks for being brave enough to say this. I feel obligated to back you up even though this might not be a great idea for me either.
Where to begin? A few snippets: I worked at Apple with a former senior (staff?) Google engineer who had been internally certified at Google as a Python style reviewer.
His code reviews were the absolute worst I have ever seen: he’d leave a dozen comments about the order in which variables were declared, and zero comments about actual engineering. For points of reference: at Mozilla people would leave lots of comments about style, but left even more about substance. At Figma people had a culture of leaving style to automatic tools as much as possible and had an extreme focus on substance.
The same guy refused to use an autoformatter. His friend put up a nontrivial PR at noon, he rubber stamped it literally 5 minutes later, then they complained to our manager about how I didn’t review it. I could share so much more that’s even worse from my experience with this and other Googlers, but it wouldn’t be relevant to programming language style guides and code review.
Lots of excellent people work at Google. But Google also has a subculture of cliquish freeloaders who obsess over style and language guides to obscure the amount of work that they’re actually doing. It’s not that they do no work at all: maybe 30% of their work and reputation comes from style guides and politics rather than actual work. But they will simultaneously act as if that gives them more authority rather than less.
In college I was a fan of the Google Python Language Guide and others, but after seeing the culture they bring along firsthand I now think they’re a red flag.
There must an English idiom about how something (not everything) which looks nice from far away look like crap from close by.
All that glistens is not gold
You could pull one from the movie “Clueless”:
Yes. It’s “Laws are like sausages, it is better not to see them being made”. i.e. having insider information about some things makes you dislike them.