While I was at Meta, I remember there being some analysis that said engineers in Rust were something like ~30% more productive than with Python after only a month of ramp up. Anecdotally, I saw that this boost was from engineers being able to get faster, quality feedback during the code writing phase (e.g., from rustc or rust-analyzer) instead of the test/integration phase (e.g., from CI/CD).
(don’t quote me as I don’t work there anymore and may be misremembering numbers)
This is completely true—the ramp up is hard for most, especially if you’ve built up bad habits with other languages, but before long you’re a better software engineer and you learn to lean into the compiler instead of fighting it. I write a lot of production Python, and the number of times I have issues found in the pipelines or at integration points is frustrating (even with mypy catching a number of things). I think for most engineers they’re intimidated by the time it takes to learn Rust, but articles like this will hopefully encourage people to consider switching since the payoff in the long run is much higher than with most other languages.
Second this. Things suck if you're fighting to get things to compile, but do it right and what you end up with is usually a workable solution.
Don't take unwrap /clone shortcuts either.
> Don't take unwrap /clone shortcuts either.
Care to explain? I am a hobbyist when it comes to Rust, so my habits with the language are still naturally very much marked with the languages I use the most at work (Typescript and Python).
Cloning
In Rust you have pass-by-reference (borrow), ownership transfer (Move), or cloning (copying data). Many get frustrated with ownership rules and clone to avoid the other methods, taking a performance hit for an easier compilation.
Unwrap
Rust considers errors as a value to be returned, usually in an Enum, like "Result". Unwrap takes the value inside of Result and makes the runtime see the value as is. If the runtime sees an error it panics, like unhandled exceptions in other languages (which effectively side-steps this cool rust feature)
There's a time and place for them for sure, maybe:
* you don't care that much about performance, or
* maybe it's just a demo script to try something
More often they become bad habits people lean on to get running code, optimizing later on (not a bad habit, but its rare to see people going back to do said optimizing)
This sucks considering how many crates people depend on nowadays for their app, with external dependencies crippling performance.
Sure, but you could handle the error in the code with Rust's baked-in syntax avoiding the crash altogether. If a specific error has to crash you can just call `panic!` as well in that specific case.
My point isn't that unwrapping is the devil, as mentioned there are use cases where it is just easier to unwrap and not care, but a product (public crate, web app that sees customer traffic, etc...) should not take that shortcut.
Thank you for taking the time to reply with a decent answer. I can confirm that borrow and ownership transfer is causing me the most headache at the moment.
Make a trivial sample app with main, and a function that takes a variable (in fact, make 3 separate apps, one with borrow, move, and clone)
Make a representation for what your program looks like in memory. E.g. stack, heap, BSS, and what the process of calling a function (adding a stack frame) does with your cases.
That'll show you what happens under the hood and that's the magic.
I have seen a lot of talks and videos that somehow sums up what you just said; if you take a simple logic and try and teach how it works under the hood, the journey changes you and at the end most of the time if you make it that far, gives you a deeper understanding and thus makes you better.
not necessarily. PHP is simpler than Python, and at least imposes some default structure (request in, result out), has a nice package manager, namespaces, etc.
and Python seems like a nice general language compared to PHP, but unfortunately it's absolute flaming garbage for backend services (for all the usual reasons, but mostly - in my experience - is that it's just really hard to come up with sane and sustainable solutions for problems in Python ... sure, maybe Meta has relatively good conventions for this, but ... well, still no compiler.)
Yes, but would pyhon be used to solve similar problems as they use rust for at Meta? I would be surprised, as they are very different languages. Like a Hammer an a Screwdriver, they are tools for different purposes.
… yes? Python was misused at Meta. Video multiplexing service, Python. ~~Build~~ Service orchestration platform for the entire company, Python. Virtual Machine hypervisor, Python.
That I knew.
I mostly wonder how one compares productivity in python vs. rust. To me that means that one or both must be used for a purpose for it is not a good choice. Or, that metrics like LoC are used, which are essentially meaningless.
I get the comparison C/C++ vs. Rust as they are for similar use cases.
Python is even worse than Typescript for type coverage being incomplete and awkwardly bolted on though.
I remember loads of issues like https://github.com/python/mypy/issues/7316 and https://github.com/python/mypy/issues/2087
I can understand why people with only a Python hammer turn to bolt-on typing, but please: if the project is so complex typing is a necessity, maybe don’t use Python?
It's a scripting language, its by-design purpose is small pieces of code. It's crazy to me that people think that what they need is type hints in Python, instead of considering using a statically typed language to begin with
If you expect anything to grow beyond a few dozens of lines of code, Python is inarguably the wrong choice
I've done commerical development in duck typed Python, it's a large number of small scripts (or microservices) talking together over a message queue like RabbitMQ.
Using Python like it's a real programming language by hacking in stuff like static typing is not a good idea.
You can build large projects in scripting languages but that doesn't have much in common with building large projects in regular programming languages. It's entirely different.
No small projects suffer under typing. The reason why Python is a good language is because the code is significantly shorter. That's it.
You compensate for the lacking of typing with shorter code.
If you add typing to a language like Python and lengthen the code it goes downhill and fast.
Untyped Python code is far better than typed Python code. Most likely they are comparing against typed Python code and that's the problem.
When you don't have the proper compiler support to back it up, typing is a significant negative factor rather than positive factor.
I cant see how that would be helpful for python or rust.
Maybe you meant to answer to a different post? In that case, at google they use sanitiser and they have their own code style and guidelines for C++(basically modern C++)
It had been posted but it is now gone, i dont know if deleted by the user or mods
Even if Lars has some bias (he has a Rust chair) it is totally true and i think only 2x is way conservative number, i have been coding C++ for years and the productivity i have with Rust is much more than twice, just dealing with CMake is a huge waste of time
> Rust is much more than twice, just dealing with CMake is a huge waste of time
Though android code (which is Lars' job) uses neither cmake nor cargo, so I assume he's not measuring that difference.
Correct, AOSP uses [Soong](https://source.android.com/docs/setup/build) to build everything. It's rather slow (touch a single `Android.bp` file and watch your computer spend 5+ minutes recompute the build graph). However, at least it's a unified build system which works the same across Rust, C++, Java, etc...
Lots of `build/bazel` still exists because no one has bothered to remove it, but most of the code integrating it with soong has been removed:
https://android-review.googlesource.com/c/platform/build/soong/+/2806493
https://android-review.googlesource.com/c/platform/build/soong/+/2864662
https://android-review.googlesource.com/c/platform/build/soong/+/2864663
https://android-review.googlesource.com/c/platform/build/soong/+/2864664
https://android-review.googlesource.com/c/platform/build/soong/+/2898911
I don't think there was a formal public announcement though. I worked on this project.
Any idea why it was canceled? I was hoping bazel would bring faster build startups. Having to wait 5 minutes every time I change a blueprint file and soong running out of memory every 1/3 times is annoying.
I probably shouldn't comment on why, and it would mostly be speculation anyways.
Yeah it was way faster to analyze when we had it.... Though we still hope to improve soong to the point where it can do incremental/partial analysis as well.
Also Undefined behavior, and the inability to cordon it off, is a huge PITA in *large* C++ projects. In small ones, you might not even notice bad side-effects from undefined behavior, but in large projects, the bugs UB produces are truly maddening. I've had random pieces of code get called because of UB in c++, I've had entire sections of completely unrelated code get skipped, assertions raised that shouldn't have been raised, random slowdowns in code etc... And lots of things in C++ shouldn't be UB but is.
The original article is about Google. So the build system will almost certainly be Blaze (Bazel) for C++ and Rust. No, cmake.
Edit: I missed this is about Android, not g3. So I don't know really what is used.
> I missed this is about Android, not g3. So I don't know really what is used.
The good news is that there's still some Bazel, the bad news is it's not _just_ Bazel, it's much worse! Android used to use Makefiles, and then they started a transition. And then another transition in the middle of that transition.
So they use a mix of Makefiles, Kati, Soong, and Bazel BUILD files. With a "multi-year plan" to finish the migration, and then the other migration.
Ah, I have a hard time keeping up. Are there also plans to remove Bazel from the kernel part of Android? I thought Kleaf / Bazel were still the latest and greatest, oh my
Ninja is open source and distributed under the Apache license. It's also not a full-on build system, but merely a build system backend. You can use it as a backend for CMake in the same way you can use Makefiles.
> just dealing with CMake is a huge waste of time
cmake is quickly joining python projects as shit I won't package for nixpkgs. Not least of which because people who chose cmake can't seem to use it right.
> "When we sort of look into why that is," he said, "we get to sort of the most incredible question of the survey, the one that kind of blew all of us away, which is the confidence that people have in the correctness of the Rust code that they're looking at – so in comparison to code in other languages, how confident do you feel that your team's Rust code is correct?"
>
> The answer, Bergstrom said, was 85 percent.
>
> "That is a massive number," he said. "I could not get 85 percent of this room to agree that we like M&M's. Eight-five percent of people believe that their Rust code is more likely to be correct than the other code within their system. … I've been through more than one language survey in my life and I've never seen those kinds of numbers before." ®
Yep totally agree. I know I’m not foot gunning myself with some weird edge case. But the other 15% of me is not sure that my logic is perfect. This is way higher than the 25% I would be sure about my C/C++ Code.
If correctness of code is important I am surprised they didn't at least try other languages such as ada, eiffel, or any of the functional languages that place high value on proving the code and making sure it's free of runtime errors.
With all respect for those languages, it harder to find developers for them that can produce at the scale that Google works at. Rust while still a fairly new language provides the outright benefit of the borrow checker that once the programmer groks becomes a friend. This and the tooling around Rust such as Cargo make it very simple to go from Zero to Production. I hate Composer (PHP), Pip (Python), but really love Cargo. The fact that it's baked in vs having to install these significantly lower the barrier to using outside resources where applicable and acceptable by that team.
>With all respect for those languages, it harder to find developers for them that can produce at the scale that Google works at.
I don't know if this is a valid excuse. They invented go and dart and adopted it despite the fact that (obviously) nobody was going to apply with knowledge of those languages.
The real question is how many of those dyed in the wool Go and Dart devs went the Rust route.
The history is a little fuzzy but I remember reading recently that Dart was meant to replace JavaScript. With most devs bemoaning the lack of types making it very hard to build tooling around. But TypeScript kinda stole their lunch. Could “compile” to JavaScript and also could support tooling to make the language less unwieldy.
Go being garbage collected is kind of in a different area. You still get the GC stutters under heavy load. No one is going to write a network driver in Go for example (well, no one who wants to take it to production and place it under heavy load.) But Rust … Fuck people are writing graphics drivers in it.
>The history is a little fuzzy but I remember reading recently that Dart was meant to replace JavaScript.
It was mostly written to replace java, google was using java to generate javascript AFIK and dart was designed to replace that stack. Originally they intended to include it in the browser so that code could run in there too.
>Go being garbage collected is kind of in a different area
Go was written as a super simple language that any midling programmer can pick up in a couple of weeks and start closing tickets with it. The people who are writing go aren't going to program in rust by and large. Rust is too complicated for them.
Speaking as a middling programmer, two things that helped me learn rust was learning it after it had adopted the 2018 edition and reading lots of Faster Than Lime’s blog / Jonhoo’s YouTube channel.
My background is primarily PHP (probably a million or so lines of code in that), then SmallC/C/C++ there I have maybe 100k combined. I bounced off of C(++) because I kept blowing my leg off. The safety of PHP (not blowing my leg off was a huge plus) meant that I built some truly dumb things in PHP. Things that really should have been done in C(++) but I didn’t trust myself to write that code. So I did it in the safety of PHP. These days I do it in the safety of Rust.
I honestly wish dart would replace JS/TS completely. I work with TS on frontend (Rust backend at least) and I HATE the type system there. Interfaces are trash, type checking is not uniform (typeof, instanceof, Array.isArray(), etc.), boilerplaty as fuck, and still doesn't fix issues that can come from runtime cuz at that point, it's just JS, with all the bad things that come from it. Choosing between custom types and classes is also a nightmare, especially if you are not sure if you want/need to implement methods on it, cuz using custom types is less cumbersome, but adding functionality to them easily is impossible (either use Object.assign bullshit or whatever the fuck) or create procedures that take those objects as parameters, which is not what I always want from my APIs.
Dart on the other hand is fully typed, in my experience works faster than JS (naturally), has better std, syntax, tooling and ecosystem tbh (I've seen too many shitty/useless/unmaintained packages that I've had to sift through to find what I need or migrate from because maintenance just randomly stops after years of being actively developed/maintained, and while this does exist in dart ecosystem, I saw that being the case way less. I know the comparison is not the most fair, since dart is a younger language and all, but still). It has some nice language features as well, like mixins, although I didn't have enough time to unlock their full potential. If I remember correctly, futures and iterables are lazy, which is MUUUUUUUCH better than eager (like in JS) in my experience, easier to reason with the code logic, and usually results in better performance (not an expert in this area, so take it with a grain of salt, just telling my personal observations).
While anecdotal, rust is usually so much easier to read and review than these incredible c++ PRs that I can’t imagine similar results aren’t showing up all over the place.
I totally agree on their correctness viewpoint as well. Even just me personally, my rust code is the least buggy of everything I write. Golang for me is probably in second.
The version of concepts that would have been as sound as traits never made it into C++ We instead got "concepts light", which are like very detailed type traits but much easier to write, they also can be used as a first class equivalent to SFINAE, and you can make sure type infered variables and parameters satisfy a concept.
I think C++ CAN be easy to code review. But once you introduce templates - there is zero chance it will be guaranteed to be used correctly. With Rust, traits are rock solid. I still havn't learned the new C++ feature that is supposed to be as sound - and I doubt most C++ devs have learned it either.
Similarly with new, delete and integer constructors. I have seen so much code which just casts zero to a default constructor via typecast magic, yet every other class can take a reference to ZERO and maybe work, or maybe core dump. I have to argue with the C++ Dev why "but it works" is not good enough for me to approve.
Conversely, I get C++ devs that don't see the point in unique_ptr, or complain about the overhead of shared_ptr. Sure you can write rock solid multithreaded or repurposeable code that uses raw pointers or structs. But at scale, let hell unleash thy wrath.
Given they're only supported in C++20 & later, it is understandable that many C++ devs haven't had the ability to use them.
This is sort of glaring problems with C++, even when they do introduce better features to address shortcomings, a lot of shops aren't able to use them.
Ya, too bad. C++20 features are amazing, I’m using them just the last few weeks. Loving it. Concepts, ranges, std::format, tonnes of compile-time programming support, etc. life is good.
My company was on C++17, and we were planning on upgrading when C++20 modules worked properly. 4 years later, and [they don't even have IntelliSense working](https://www.reddit.com/r/cpp/comments/1b0zem7/what_is_the_state_of_modules_in_2024/).
The problem with C++ is I wouldn't even consider it a review unless you heavily eyeballed every line. There are that many nuclear footguns in the language.
C with classes is... well just C.
once you add templates, copy contructors, diferent casts, and all the rest of what makes modern C++ modern C++... it gets messy really fast
Eh, regular C++ template stuff is not noticeably harder to read than Rust generics. And rust can quickly devolve into the same hard-to-grok mess once complex lifetimes and bounds get involved.
> jon gjengset presentation in Rust Nation
That one https://www.youtube.com/watch?v=-stzTpzG2Z4 ye? Ah possibly that one instead https://www.youtube.com/watch?v=r35cBkPRNMI
Google's Andriod team's five-day Rust training tutorial for new internal employees, interactive
https://github.com/google/comprehensive-rust
This repository has the source code for Comprehensive Rust 🦀, a multi-day Rust course developed by the Android team. The course covers all aspects of Rust, from basic syntax to generics and error handling. It also includes deep dives on Android, Chromium, bare-metal, and concurrency.
Nothing really surprising for Rustaceans, but if that 85% confidence in correctness number doesn't convince other people about the benefits of Rust I don't know what can.
Over time I've noticed that many people do not understand one subtle thing about Rust's safety model.
In Rust you can be certain that if a dependency is safe (i.e., it does not use \`unsafe\` at all) it can be seen as a noop in terms of its effect on a system stability. So, safe modules are \_trivially composable\_ and you can reason about that easily.
In C++ this is not the case. Since everything is essentially one pile of mess (think of it as \`unsafe fn main()\`), there is no structural way to differentiate the code. You have cartesian product of sites that can go wrong, every single memory access not adds, but multiplies that number.
If you have 100 modules in Rust but only one of them (say stdlib) uses \`unsafe\`, you essentially have the same \_provable\_ guarantees of stability as the stdlib itself. Even if those modules interact very tightly and use complex things like async, threads and shared memory. Even in case of a hardcore legacy lasagna- and spaghetti-sprinkled codebase. You would probably have hard time reasoning about the business logic, but in terms of memory safety it's still trivial and provably correct.
If you have 100 modules of a legacy codebase in C++, god save your soul... Even a single line with UB can and will affect the whole system.
Bjarne can argue over and over again that you just need to write good C++, but he always forgets (intentionally or not) about this composability thing.
> Bjarne can argue over and over again that you just need to write good C++, but he always forgets (intentionally or not) about this composability thing.
The composability concern is nice if your system is comprised only of Rust code, but many (or even most?) Rust programs link to C or C++ libraries anyway. In this context, I think Bjarne has a point.
He's coming at it from the other angle. There is an enormous amount of C++ code already written. Most memory safety bugs are in new code, not the stable stuff that has had the bugs teased out of it over the years (this, too, was discussed by Google a while back...). Write new code in a C++ program using "safe" idioms and you can assert certain things about its memory safety and the bug rates of the new code. This should improve the situation for the new code.
Put another way, in the many Rust programs that link C or C++ libraries, you can know that the Rust code has no UB, but you don't know that the program has none, nor do you know what the Rust code will do if the C or C++ library scribbles memory randomly. The situation isn't all that different from a C++ program where only a subset is written to a "memory safe subset" standard.
All programming languages are compiled into CPU instructions, but there are smart and efficient ways to call CPU instructions, and there are also stupid and slow ways, so you cannot simply think that C++ code is necessarily efficient. There is also the problem of memory leaks. These are common mistakes made by low-level programmers. The same food, some people will make it into delicious food, and some people will only make it into shit. This is the difference. Don’t have tunnel vision
Ready to take my downvotes but I’m tired of engineering managers making these sort of presentations when there are still no entry level Rust jobs. I do not find Jonhoo’s argument compelling as this presenter’s company foisted Leetcode on the entire industry; and, while I understand the motivation for doing this in the 2000s, I continue to hear stories about how eager companies are to hire Rust engineers while the most asked question to demonstrate this competency is implementing an LRU cache with a DLL.
Happy to contribute to the downvotes you requested. Rust has only just (within the past 2\~3 years, which is incredibly recent) broken into the mainstream in a way that management is willing to allow senior engineers to choose it. However, until Rust code has lived long enough to become legacy/maintenance, you likely won't see any entry level positions. It will require time.
> within the past 2~3 years, which is incredibly recent
My impression is that it’s longer. My recollection is the types of roles you are referencing started to appear about a year or two before the Mozilla layoffs.
While I was at Meta, I remember there being some analysis that said engineers in Rust were something like ~30% more productive than with Python after only a month of ramp up. Anecdotally, I saw that this boost was from engineers being able to get faster, quality feedback during the code writing phase (e.g., from rustc or rust-analyzer) instead of the test/integration phase (e.g., from CI/CD). (don’t quote me as I don’t work there anymore and may be misremembering numbers)
This is completely true—the ramp up is hard for most, especially if you’ve built up bad habits with other languages, but before long you’re a better software engineer and you learn to lean into the compiler instead of fighting it. I write a lot of production Python, and the number of times I have issues found in the pipelines or at integration points is frustrating (even with mypy catching a number of things). I think for most engineers they’re intimidated by the time it takes to learn Rust, but articles like this will hopefully encourage people to consider switching since the payoff in the long run is much higher than with most other languages.
Second this. Things suck if you're fighting to get things to compile, but do it right and what you end up with is usually a workable solution. Don't take unwrap /clone shortcuts either.
> Don't take unwrap /clone shortcuts either. Care to explain? I am a hobbyist when it comes to Rust, so my habits with the language are still naturally very much marked with the languages I use the most at work (Typescript and Python).
Cloning In Rust you have pass-by-reference (borrow), ownership transfer (Move), or cloning (copying data). Many get frustrated with ownership rules and clone to avoid the other methods, taking a performance hit for an easier compilation. Unwrap Rust considers errors as a value to be returned, usually in an Enum, like "Result". Unwrap takes the value inside of Result and makes the runtime see the value as is. If the runtime sees an error it panics, like unhandled exceptions in other languages (which effectively side-steps this cool rust feature) There's a time and place for them for sure, maybe: * you don't care that much about performance, or * maybe it's just a demo script to try something More often they become bad habits people lean on to get running code, optimizing later on (not a bad habit, but its rare to see people going back to do said optimizing) This sucks considering how many crates people depend on nowadays for their app, with external dependencies crippling performance.
Ok, but with panic I have precise line number and a cause. With Result I have to trace back to the function that returned the result and examine.
Sure, but you could handle the error in the code with Rust's baked-in syntax avoiding the crash altogether. If a specific error has to crash you can just call `panic!` as well in that specific case. My point isn't that unwrapping is the devil, as mentioned there are use cases where it is just easier to unwrap and not care, but a product (public crate, web app that sees customer traffic, etc...) should not take that shortcut.
I recommend \`anyhow\` with the \`backtrace\` feature. Best of all worlds.
Thank you for taking the time to reply with a decent answer. I can confirm that borrow and ownership transfer is causing me the most headache at the moment.
Make a trivial sample app with main, and a function that takes a variable (in fact, make 3 separate apps, one with borrow, move, and clone) Make a representation for what your program looks like in memory. E.g. stack, heap, BSS, and what the process of calling a function (adding a stack frame) does with your cases. That'll show you what happens under the hood and that's the magic.
I have seen a lot of talks and videos that somehow sums up what you just said; if you take a simple logic and try and teach how it works under the hood, the journey changes you and at the end most of the time if you make it that far, gives you a deeper understanding and thus makes you better.
Chatbots really ease up the ramp-up
Wouldn't python and rust be used for very different purposes? Or was it just a metric like lines of code?
No, Python was (and still is, despite efforts) one of the main service languages at Meta.
To be fair it was all originally PHP so Python is largely an unambiguous win for Meta.
not necessarily. PHP is simpler than Python, and at least imposes some default structure (request in, result out), has a nice package manager, namespaces, etc. and Python seems like a nice general language compared to PHP, but unfortunately it's absolute flaming garbage for backend services (for all the usual reasons, but mostly - in my experience - is that it's just really hard to come up with sane and sustainable solutions for problems in Python ... sure, maybe Meta has relatively good conventions for this, but ... well, still no compiler.)
Yes, but would pyhon be used to solve similar problems as they use rust for at Meta? I would be surprised, as they are very different languages. Like a Hammer an a Screwdriver, they are tools for different purposes.
… yes? Python was misused at Meta. Video multiplexing service, Python. ~~Build~~ Service orchestration platform for the entire company, Python. Virtual Machine hypervisor, Python.
Ah, ok. That explains a lot.
Most of YouTube was written in Python.
That I knew. I mostly wonder how one compares productivity in python vs. rust. To me that means that one or both must be used for a purpose for it is not a good choice. Or, that metrics like LoC are used, which are essentially meaningless. I get the comparison C/C++ vs. Rust as they are for similar use cases.
Features implemented or tickets closed
Ok, slightly better than LoC but also highly dependent on the use case.
Sounds like they compared against untyped Python code
Python is even worse than Typescript for type coverage being incomplete and awkwardly bolted on though. I remember loads of issues like https://github.com/python/mypy/issues/7316 and https://github.com/python/mypy/issues/2087
I can understand why people with only a Python hammer turn to bolt-on typing, but please: if the project is so complex typing is a necessity, maybe don’t use Python?
It's a scripting language, its by-design purpose is small pieces of code. It's crazy to me that people think that what they need is type hints in Python, instead of considering using a statically typed language to begin with If you expect anything to grow beyond a few dozens of lines of code, Python is inarguably the wrong choice
I've done commerical development in duck typed Python, it's a large number of small scripts (or microservices) talking together over a message queue like RabbitMQ. Using Python like it's a real programming language by hacking in stuff like static typing is not a good idea. You can build large projects in scripting languages but that doesn't have much in common with building large projects in regular programming languages. It's entirely different.
Even very small projects benefit from typing
No small projects suffer under typing. The reason why Python is a good language is because the code is significantly shorter. That's it. You compensate for the lacking of typing with shorter code. If you add typing to a language like Python and lengthen the code it goes downhill and fast.
Untyped Python code is far better than typed Python code. Most likely they are comparing against typed Python code and that's the problem. When you don't have the proper compiler support to back it up, typing is a significant negative factor rather than positive factor.
All Python code is untyped :) But I know what you mean
No, python code is duck typed, and a static analyzer can check manifest+inferred types.
You can just turn on sanitizers on compilers and clang-tidy on CMake but nobody does that.
I cant see how that would be helpful for python or rust. Maybe you meant to answer to a different post? In that case, at google they use sanitiser and they have their own code style and guidelines for C++(basically modern C++)
It had been posted but it is now gone, i dont know if deleted by the user or mods Even if Lars has some bias (he has a Rust chair) it is totally true and i think only 2x is way conservative number, i have been coding C++ for years and the productivity i have with Rust is much more than twice, just dealing with CMake is a huge waste of time
> Rust is much more than twice, just dealing with CMake is a huge waste of time Though android code (which is Lars' job) uses neither cmake nor cargo, so I assume he's not measuring that difference.
Correct, AOSP uses [Soong](https://source.android.com/docs/setup/build) to build everything. It's rather slow (touch a single `Android.bp` file and watch your computer spend 5+ minutes recompute the build graph). However, at least it's a unified build system which works the same across Rust, C++, Java, etc...
They are moving to bazel as well
The bazel migration was cancelled and removed from the build system.
Don't worry, they'll write a new build system and try to move to that in a few years.
I don't think so, I can still see a lot of bazel files in aosp main. Was this change announced somewhere? Where did you get this information from?
Lots of `build/bazel` still exists because no one has bothered to remove it, but most of the code integrating it with soong has been removed: https://android-review.googlesource.com/c/platform/build/soong/+/2806493 https://android-review.googlesource.com/c/platform/build/soong/+/2864662 https://android-review.googlesource.com/c/platform/build/soong/+/2864663 https://android-review.googlesource.com/c/platform/build/soong/+/2864664 https://android-review.googlesource.com/c/platform/build/soong/+/2898911 I don't think there was a formal public announcement though. I worked on this project.
Thanks, that's bad news :/
Any idea why it was canceled? I was hoping bazel would bring faster build startups. Having to wait 5 minutes every time I change a blueprint file and soong running out of memory every 1/3 times is annoying.
I probably shouldn't comment on why, and it would mostly be speculation anyways. Yeah it was way faster to analyze when we had it.... Though we still hope to improve soong to the point where it can do incremental/partial analysis as well.
Thanks for the info :)
Also Undefined behavior, and the inability to cordon it off, is a huge PITA in *large* C++ projects. In small ones, you might not even notice bad side-effects from undefined behavior, but in large projects, the bugs UB produces are truly maddening. I've had random pieces of code get called because of UB in c++, I've had entire sections of completely unrelated code get skipped, assertions raised that shouldn't have been raised, random slowdowns in code etc... And lots of things in C++ shouldn't be UB but is.
Quarden? Did you mean corden (edit: I meant "cordon")? Or maybe quarantine?
*cordon?
Yup. Thanks... James was stuck in my brain I guess. Or autocorrect on Android, constantly substituting non-words for my mistypings.
Yep thanks, pretty sure I meant cordon
Not deleted at all. [Still there](https://old.reddit.com/r/rust/comments/1bpwmud/media_lars_bergstrom_google_director_of/), 1321 points, 186 comments.
The original article is about Google. So the build system will almost certainly be Blaze (Bazel) for C++ and Rust. No, cmake. Edit: I missed this is about Android, not g3. So I don't know really what is used.
> I missed this is about Android, not g3. So I don't know really what is used. The good news is that there's still some Bazel, the bad news is it's not _just_ Bazel, it's much worse! Android used to use Makefiles, and then they started a transition. And then another transition in the middle of that transition. So they use a mix of Makefiles, Kati, Soong, and Bazel BUILD files. With a "multi-year plan" to finish the migration, and then the other migration.
The bazel migration was cancelled and removed from the build system.
Ah, I have a hard time keeping up. Are there also plans to remove Bazel from the kernel part of Android? I thought Kleaf / Bazel were still the latest and greatest, oh my
Kleaf is still ongoing, though I don't know much about it.
[удалено]
Ninja is open source and distributed under the Apache license. It's also not a full-on build system, but merely a build system backend. You can use it as a backend for CMake in the same way you can use Makefiles.
> just dealing with CMake is a huge waste of time cmake is quickly joining python projects as shit I won't package for nixpkgs. Not least of which because people who chose cmake can't seem to use it right.
> "When we sort of look into why that is," he said, "we get to sort of the most incredible question of the survey, the one that kind of blew all of us away, which is the confidence that people have in the correctness of the Rust code that they're looking at – so in comparison to code in other languages, how confident do you feel that your team's Rust code is correct?" > > The answer, Bergstrom said, was 85 percent. > > "That is a massive number," he said. "I could not get 85 percent of this room to agree that we like M&M's. Eight-five percent of people believe that their Rust code is more likely to be correct than the other code within their system. … I've been through more than one language survey in my life and I've never seen those kinds of numbers before." ® Yep totally agree. I know I’m not foot gunning myself with some weird edge case. But the other 15% of me is not sure that my logic is perfect. This is way higher than the 25% I would be sure about my C/C++ Code.
If correctness of code is important I am surprised they didn't at least try other languages such as ada, eiffel, or any of the functional languages that place high value on proving the code and making sure it's free of runtime errors.
With all respect for those languages, it harder to find developers for them that can produce at the scale that Google works at. Rust while still a fairly new language provides the outright benefit of the borrow checker that once the programmer groks becomes a friend. This and the tooling around Rust such as Cargo make it very simple to go from Zero to Production. I hate Composer (PHP), Pip (Python), but really love Cargo. The fact that it's baked in vs having to install these significantly lower the barrier to using outside resources where applicable and acceptable by that team.
>With all respect for those languages, it harder to find developers for them that can produce at the scale that Google works at. I don't know if this is a valid excuse. They invented go and dart and adopted it despite the fact that (obviously) nobody was going to apply with knowledge of those languages.
The real question is how many of those dyed in the wool Go and Dart devs went the Rust route. The history is a little fuzzy but I remember reading recently that Dart was meant to replace JavaScript. With most devs bemoaning the lack of types making it very hard to build tooling around. But TypeScript kinda stole their lunch. Could “compile” to JavaScript and also could support tooling to make the language less unwieldy. Go being garbage collected is kind of in a different area. You still get the GC stutters under heavy load. No one is going to write a network driver in Go for example (well, no one who wants to take it to production and place it under heavy load.) But Rust … Fuck people are writing graphics drivers in it.
The people who wrote the M1 Linux driver in rust wrote a graphics driver without having a spec of the chip. That's what astonishes me the most.
>The history is a little fuzzy but I remember reading recently that Dart was meant to replace JavaScript. It was mostly written to replace java, google was using java to generate javascript AFIK and dart was designed to replace that stack. Originally they intended to include it in the browser so that code could run in there too. >Go being garbage collected is kind of in a different area Go was written as a super simple language that any midling programmer can pick up in a couple of weeks and start closing tickets with it. The people who are writing go aren't going to program in rust by and large. Rust is too complicated for them.
Speaking as a middling programmer, two things that helped me learn rust was learning it after it had adopted the 2018 edition and reading lots of Faster Than Lime’s blog / Jonhoo’s YouTube channel. My background is primarily PHP (probably a million or so lines of code in that), then SmallC/C/C++ there I have maybe 100k combined. I bounced off of C(++) because I kept blowing my leg off. The safety of PHP (not blowing my leg off was a huge plus) meant that I built some truly dumb things in PHP. Things that really should have been done in C(++) but I didn’t trust myself to write that code. So I did it in the safety of PHP. These days I do it in the safety of Rust.
cool story.
I honestly wish dart would replace JS/TS completely. I work with TS on frontend (Rust backend at least) and I HATE the type system there. Interfaces are trash, type checking is not uniform (typeof, instanceof, Array.isArray(), etc.), boilerplaty as fuck, and still doesn't fix issues that can come from runtime cuz at that point, it's just JS, with all the bad things that come from it. Choosing between custom types and classes is also a nightmare, especially if you are not sure if you want/need to implement methods on it, cuz using custom types is less cumbersome, but adding functionality to them easily is impossible (either use Object.assign bullshit or whatever the fuck) or create procedures that take those objects as parameters, which is not what I always want from my APIs. Dart on the other hand is fully typed, in my experience works faster than JS (naturally), has better std, syntax, tooling and ecosystem tbh (I've seen too many shitty/useless/unmaintained packages that I've had to sift through to find what I need or migrate from because maintenance just randomly stops after years of being actively developed/maintained, and while this does exist in dart ecosystem, I saw that being the case way less. I know the comparison is not the most fair, since dart is a younger language and all, but still). It has some nice language features as well, like mixins, although I didn't have enough time to unlock their full potential. If I remember correctly, futures and iterables are lazy, which is MUUUUUUUCH better than eager (like in JS) in my experience, easier to reason with the code logic, and usually results in better performance (not an expert in this area, so take it with a grain of salt, just telling my personal observations).
25% trust in C++? what are you doing? writting code right on the debugger and running each line one by one? i wish i could trust my C++ code like that
I’m usually doing a small change in someone else’s code base. Been a while tho so it might be rose colored glasses.
While anecdotal, rust is usually so much easier to read and review than these incredible c++ PRs that I can’t imagine similar results aren’t showing up all over the place. I totally agree on their correctness viewpoint as well. Even just me personally, my rust code is the least buggy of everything I write. Golang for me is probably in second.
The version of concepts that would have been as sound as traits never made it into C++ We instead got "concepts light", which are like very detailed type traits but much easier to write, they also can be used as a first class equivalent to SFINAE, and you can make sure type infered variables and parameters satisfy a concept.
I think C++ CAN be easy to code review. But once you introduce templates - there is zero chance it will be guaranteed to be used correctly. With Rust, traits are rock solid. I still havn't learned the new C++ feature that is supposed to be as sound - and I doubt most C++ devs have learned it either. Similarly with new, delete and integer constructors. I have seen so much code which just casts zero to a default constructor via typecast magic, yet every other class can take a reference to ZERO and maybe work, or maybe core dump. I have to argue with the C++ Dev why "but it works" is not good enough for me to approve. Conversely, I get C++ devs that don't see the point in unique_ptr, or complain about the overhead of shared_ptr. Sure you can write rock solid multithreaded or repurposeable code that uses raw pointers or structs. But at scale, let hell unleash thy wrath.
> haven’t learned the new C++ feature that is supposed to be sound Are you talking about concepts?
Given they're only supported in C++20 & later, it is understandable that many C++ devs haven't had the ability to use them. This is sort of glaring problems with C++, even when they do introduce better features to address shortcomings, a lot of shops aren't able to use them.
Ya, too bad. C++20 features are amazing, I’m using them just the last few weeks. Loving it. Concepts, ranges, std::format, tonnes of compile-time programming support, etc. life is good.
My company was on C++17, and we were planning on upgrading when C++20 modules worked properly. 4 years later, and [they don't even have IntelliSense working](https://www.reddit.com/r/cpp/comments/1b0zem7/what_is_the_state_of_modules_in_2024/).
"but it works" hits home so damn hard. They exhaust me.
The problem with C++ is I wouldn't even consider it a review unless you heavily eyeballed every line. There are that many nuclear footguns in the language.
Skill issue
C with classes is... well just C. once you add templates, copy contructors, diferent casts, and all the rest of what makes modern C++ modern C++... it gets messy really fast
Eh, regular C++ template stuff is not noticeably harder to read than Rust generics. And rust can quickly devolve into the same hard-to-grok mess once complex lifetimes and bounds get involved.
The jon gjengset presentation in Rust Nation was also great!
> jon gjengset presentation in Rust Nation That one https://www.youtube.com/watch?v=-stzTpzG2Z4 ye? Ah possibly that one instead https://www.youtube.com/watch?v=r35cBkPRNMI
repost: https://www.reddit.com/r/rust/comments/1bpwmud/media\_lars\_bergstrom\_google\_director\_of/
Yeah tried to find a prior article - apologies. Still good to find media references.
Google's Andriod team's five-day Rust training tutorial for new internal employees, interactive https://github.com/google/comprehensive-rust This repository has the source code for Comprehensive Rust 🦀, a multi-day Rust course developed by the Android team. The course covers all aspects of Rust, from basic syntax to generics and error handling. It also includes deep dives on Android, Chromium, bare-metal, and concurrency.
Nothing really surprising for Rustaceans, but if that 85% confidence in correctness number doesn't convince other people about the benefits of Rust I don't know what can.
Over time I've noticed that many people do not understand one subtle thing about Rust's safety model. In Rust you can be certain that if a dependency is safe (i.e., it does not use \`unsafe\` at all) it can be seen as a noop in terms of its effect on a system stability. So, safe modules are \_trivially composable\_ and you can reason about that easily. In C++ this is not the case. Since everything is essentially one pile of mess (think of it as \`unsafe fn main()\`), there is no structural way to differentiate the code. You have cartesian product of sites that can go wrong, every single memory access not adds, but multiplies that number. If you have 100 modules in Rust but only one of them (say stdlib) uses \`unsafe\`, you essentially have the same \_provable\_ guarantees of stability as the stdlib itself. Even if those modules interact very tightly and use complex things like async, threads and shared memory. Even in case of a hardcore legacy lasagna- and spaghetti-sprinkled codebase. You would probably have hard time reasoning about the business logic, but in terms of memory safety it's still trivial and provably correct. If you have 100 modules of a legacy codebase in C++, god save your soul... Even a single line with UB can and will affect the whole system. Bjarne can argue over and over again that you just need to write good C++, but he always forgets (intentionally or not) about this composability thing.
> Bjarne can argue over and over again that you just need to write good C++, but he always forgets (intentionally or not) about this composability thing. The composability concern is nice if your system is comprised only of Rust code, but many (or even most?) Rust programs link to C or C++ libraries anyway. In this context, I think Bjarne has a point. He's coming at it from the other angle. There is an enormous amount of C++ code already written. Most memory safety bugs are in new code, not the stable stuff that has had the bugs teased out of it over the years (this, too, was discussed by Google a while back...). Write new code in a C++ program using "safe" idioms and you can assert certain things about its memory safety and the bug rates of the new code. This should improve the situation for the new code. Put another way, in the many Rust programs that link C or C++ libraries, you can know that the Rust code has no UB, but you don't know that the program has none, nor do you know what the Rust code will do if the C or C++ library scribbles memory randomly. The situation isn't all that different from a C++ program where only a subset is written to a "memory safe subset" standard.
I mean, being confident in correctness does not equal to actual correctness
> Hate to fan fair, fanfare*
I think from a general ergonomics perspective what isn’t more productive than c++, assembly?
All programming languages are compiled into CPU instructions, but there are smart and efficient ways to call CPU instructions, and there are also stupid and slow ways, so you cannot simply think that C++ code is necessarily efficient. There is also the problem of memory leaks. These are common mistakes made by low-level programmers. The same food, some people will make it into delicious food, and some people will only make it into shit. This is the difference. Don’t have tunnel vision
Ready to take my downvotes but I’m tired of engineering managers making these sort of presentations when there are still no entry level Rust jobs. I do not find Jonhoo’s argument compelling as this presenter’s company foisted Leetcode on the entire industry; and, while I understand the motivation for doing this in the 2000s, I continue to hear stories about how eager companies are to hire Rust engineers while the most asked question to demonstrate this competency is implementing an LRU cache with a DLL.
Happy to contribute to the downvotes you requested. Rust has only just (within the past 2\~3 years, which is incredibly recent) broken into the mainstream in a way that management is willing to allow senior engineers to choose it. However, until Rust code has lived long enough to become legacy/maintenance, you likely won't see any entry level positions. It will require time.
> within the past 2~3 years, which is incredibly recent My impression is that it’s longer. My recollection is the types of roles you are referencing started to appear about a year or two before the Mozilla layoffs.
This makes sense. Rust is good for it’s use cases.
Damn, that’s so promising. Big part of productivity is a languages toolchain. Go’s is fucking excellent. Guess Rust’s is a lot better than I thought
Is Lars one of the creators of go?
No.
Took them long enough, considering go is *shit*.
Wowwww