mrtngslr

The family of Rust courses by Google have grown to include a course on how to use Rust in Chromium!

This is targeted at Chromium engineers and others who build the browser, but everybody can play along at home and learn how to integrate Rust with their browser.

The goal is to make Chromium and Chrome more secure by eliminating a whole class of errors related to unsafe memory handling.

Thanks! We do include speaker notes on some pages (but not yet all[1]). We would love to expand this and PRs are very welcome for this :-)

I think videos will end up being made by someone other than me since I feel it takes too much effort when you don't have the right setup already. We have an issue and I'll update it as soon as I hear more about videos.[2]

[1]: https://github.com/google/comprehensive-rust/issues/1083 [2]: https://github.com/google/comprehensive-rust/issues/52

A bit more detail: we've been expanding our Rust training at Google over the last year. We've now had more than 500 Googlers go through Comprehensive Rust and they tell us that they really like it — also when we ask them again three months later :-)

The post is a huge Thank You! to the many people who have helped with the course, both inside and outside of Google. More than 30 Googlers (who already knew Rust) have picked up the course and taught it around the world.

People have used the material for university classes[1] and there will soon be online classes[2] as well. I hope it will become a good resource for people to teach Rust in many different contexts!

Pull requests are always welcome, the whole thing is open source[3]!

[1]: https://mo8it.com/blog/teaching-rust/

[2]: https://twitter.com/mrtngslr/status/1696601520412783052

[3]: https://github.com/google/comprehensive-rust/

I wrote a blog post about how we've been scaling Rust adaption in Google.

I've seen that too: having experience with Rust made C++ feel easy.

I looked at C++ many years ago but never used it professionally. About 6-7 years ago, I learnt Rust and a few years later, I started working full time in a C++ team at Google. There are many things in the Google C++ Style Guide[1] that reminds me of Rust, from the ban on exceptions to the use of `std::optional` for optional inputs and outputs.

[1]: https://google.github.io/styleguide/cppguide.html

Hey there! I wrote the course and you're spot on: the course is meant for classroom training (at Google and elsewhere). If you have the time to read a book, then I highly recommend diving into one of the many great Rust books. I've linked some of the freely available ones here: https://google.github.io/comprehensive-rust/other-resources.....

We've made an attempt at making Comprehensive Rust useful for self-learners by providing speaker notes on many of the pages. However, they're still quite terse and could be expanded in many places. PRs for that will be gratefully accepted :-)

My colleguage Andrew wrote the bare-metal part. I believe he picked the micro:bit board because it's readily available around the world. It also has a lot of fun sensors (microphone, rudimentary speaker, compass, ...). I'm sure there are other boards around, but so far people seem very happy with this board in our classroom training.

The only slight problem is the noise when 30 boards are powered on at once :-D They ship with an elaborate demo program which plays sounds and blinks the LEDs when you start it up.

Yes, it's definitely important to tailor the training to the audience!

When I'm teaching the course, I start by asking people about their background — if it's primarily C/C++ people, then we can quickly page through the slides about the stack and the heap.

The course is meant to be interactive, which means that you should try out the embedded code snippets. You can edit them and run them from your browser :) However, if you really want a PDF, then use the print page[1]. It will let you produce a ~210 page PDF with the entire course.

For learning Rust via a non-interactive medium, I recommend the Rust Book[2]. It has all the narrative that the course material is missing.

[1]: https://google.github.io/comprehensive-rust/print.html

[2]: https://doc.rust-lang.org/book/.

Thanks for posting the link and thank you very much to everyone who have sent us PRs over the last 24 hours!

Please keep submitting them. You can use the little pencil icon in the top-right of any page to quickly submit a typo fix patch. I'm from Denmark and English is not my first language — I very much appreciate the help from you to fix all the grammar mistakes :-)

Yeah, that is a fun tutorial indeed :-D I forgot to add that one to the list of https://google.github.io/comprehensive-rust/other-resources..... Would you care to open a PR for that?

Sorry, you're right :-) I meant to comment further up where people asked if we could reference rustup.rs in the installation instructions.

I actually haven't tried this... do you know off the top of your head what it takes to make a cycle with Rc?

It should not be possible with normal borrows (and safe Rust) since they're statically checked to be acyclic.

Right, this is a problem with reference counted data structures in general. You're correct that Rust doesn't try to solve this particular problem.

Put differently, the borrow checker won't allow you to create a cycle of refrences (the & kind). But you can do it with library types such as Rc.

Thanks for reposting :-)

In general, I feel that the new course will be useful for people who want to teach Rust. If you have a group of engineers and you want to teach them Rust, then this is a ready-to-go solution. You only need to spend some time getting familiar with the material and then you can start teaching it. I don't think there was such a resource before.

For self-study, I really like the Rust book and also Rust by Example. I've listed a bunch of good resources here: https://google.github.io/comprehensive-rust/other-resources.....

Hi, I wrote the new course. We have been enabling the use of Rust in the Android Platform.

Roughly speaking, the Android Platform is the Linux distribution running below the Android apps we all know. There are a number of daemons running on the system and these are often written in C++. We've now made it possible for Android engineers to write them in Rust instead (or to link in Rust libraries if they want). To do this, the Android build system had to be extended with new rules, see https://source.android.com/docs/setup/build/rust/building-ru....

The overall goal is to have more secure software. Rust removes a whole class of possible security vulnerabilities and we deploy it to make phones more secure. See https://security.googleblog.com/2022/12/memory-safe-language... for details on that.

Actually, there is already an issue for this: https://github.com/google/comprehensive-rust/issues/19 and I hope someone will fix it soon :-)

To be honest, the course suggests using apt since that's an easy security-approved way to install things on our computers (see https://en.wikipedia.org/wiki/GLinux).

I'll be happy to update it to suggest using rustup like "normal". Could you make a PR for that?

Hi, I wrote the course :-) Yes, this is a real thing — Android has had support for Rust in the Android Platform for a few years now. Most recently, we shipped support for DNS-over-HTTP/3: https://security.googleblog.com/2022/07/dns-over-http3-in-an...

We put out the course to make it easy for even more people to onboard with Rust.

From: https://plus.google.com/+MartinGeisler/posts/eR6obsGwTGw

Changeset evolution has some similarities with a distributed reflog. Like Git, commits are immutable in Mercurial and we can only "change" a commit by creating a new version and then hide the old version. Mercurial "hides" the old version today by stripping it from the repository — the old version is then stored in a bundle in the .hg/strip-backups folder.

This is far from optimal, so a first step was to add a concept of hidden commits. Hidden changesets have been part of core Mercurial for some time now. The evolve extension enables it and actually changes commands to use it. So "hg commit --amend" will normally strip the old commit, but when evolve is enabled, it will instead hide it. This is both faster and safer.

The next step is the introduction obsolete markers. These are small markers that tell you when a commit is succeeded by a better version. When you amend a commit, an obsolete marker will be created that say "the new version obsoleted the old version". This information is something that Git doesn't store, and it is by distributing these markers that we can make Mercurial more intelligent. As an example, if I amend a commit that you have already based work on, then evolve will know that it should rebase your work onto the successor I created. It will tell you about this when you pull from me and get the new version along with the obsolete marker. Your commits will be called "unstable" as that point, meaning that they are descendants of a commit marked obsolete (they descend from the commit I amended and thus marked obsolete). You can run "hg evolve" and it will figure out that it should run "hg rebase" behind the scenes.

Seen like this, I would say evolve is similar to what happens in Git when you edit history, but with some extra meta data that will allow you to edit shared history with confidence.

Yes, they are merged. The Facebook guys have been doing a great job optimizing things all over the place (revsets in particular).

If you haven't already, then you can go vote on this issue: https://bitbucket.org/site/master/issue/6710/enable-exchange... -- and ask your collegues to do so too! :-)

The Bitbucket devs are nice guys and have said that they do listen to issue feedback like this.

That's a good image. The key difference to Mercurial is then that Mercurial's tree of commits don't need Post-it notes. The tree can stand on its own without extra branch labels. You can add them (see bookmarks) but they're an optional feature.

Largefiles are being used for production in game companies and we have not gotten reports about corruption.

> I think people hear "rewrites history" and let their imaginations run wild with sci-fi tales of wonder, only then to think of the grave horrors such power would enable... but forget to look at what actually is happening when you "rewrite history" in git. There is no reason to fear it.

Yeah, I very much agree with this. Rewriting history is a tool, a very powerful tool. It's something you can use if you want to.

It reminds me a little of a discussion I had recently with a developer who mostly used statically typed languages. I'm using to dynamically typed languages like Python and JavaScript, so it was puzzling for me to hear him talk about the horrors of dynamic types. He said things like "I pass a Person object to a function and the function might do anything with it -- like adding new methods and fields to it!". Yes, it is true that you can add a new method to an object in most dynamically typed languages. No, adding methods and fields by accident is not really a problem in real life.

Just because you have the option of doing something, doesn't mean that you must do it.

Revision numbers are stable within a given repository. The revision number for a commit is simply the index of the commit in the changelog — nothing more. Since a changeset must come after its parent in the changelog, the revision numbers give you a topological ordering of the changesets. A topological ordering is often not unique — this is why revision numbers can differ between repositories, even if they contain exactly the same commits.

Because the changelog is append-only, new commits you pull in get higher revision numbers than the existing commits. Your existing revision numbers will thus not change when you do 'hg pull' and 'hg merge'. We don't actually guarantee that revision numbers cannot change when you pull, but it's been the case until now.

In any case, the stability of the revision numbers isn't why we like them — we like them since it's often easier to type 'hg histedit 12345' than 'hg histedit c38c3fdc8b93' when you've looked up a particular changeset in your (local!) repository.

Hosting sites like Bitbucket and Kiln will wisely not show you revision numbers since the concept is meaningless when talking about more than one repository.

I don't think this is true today. Git and Mercurial have the same basic model, which means that a commit is immutable because the identity of a commit is determined by its content.

This means that you must re-create a changeset in both systems if you want to "change" it. Mercurial and Git can do this and have been doing it for years. The difference is that Git has a built-in concept of garbage collection whereas Mercurial does not. So commands that modify history in Mercurial must trigger the garbage collection (we call it strip) manually -- and they do, of course.

So you wont see any big difference between 'hg rebase' and 'git rebase'. They both build new commits and remove the old commits (in Git they're removed eventually, in Mercurial they're removed immediatedly, but with a backup if you want to restore the pre-rebase state).

The latest versions of Mercurial has history modification built-in: you can 'hg commit --amend' without enabling any extensions. The changeset evolution concept will take this even further and allow really cool collaborative editing of shared history.

Mercurial ships with 30+ standard extensions and you simply enable them as needed. More experienced users can download and then install third-party extensions as they like.

This of them as major modes for Emacs, if you're familiar with that. Emacs comes with syntax highlighting support for a lot of languages and the mode is turned on automatically. Sometimes you need to install a new major mode yourself, but the bundled modes get you a long way.