This post from 2022 was very interesting:

There are approximately 1.5 million total lines of Rust code in AOSP across new functionality and components [...] These are low-level components that require a systems language which otherwise would have been implemented in C++.

To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.

https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html

For those who don't know (I assume you do), you can git bisect run some_command and git will automatically run git bisect until it finds the falty commit. It's amazing.

The issue is that the notion of "tomorrow" becomes quite hard to express. If it’s 20:00 when the sun rose, when does tomorrow starts? In 5 hours ?

I’m not familiar with C tooling, but I have done multiple projects in C++ (in a professionnel environnement) and AFAIK the tooling is the same. Tooling to C++ is a nightmare, and that’s and understatement. Most of the difficulty is self inflicted like not using cmake/meson but a custom build system, relying on system library instead of using Conan or vcpkg, not using smart-pointers,… but adding basically anything (LSP, code coverage, a new dependency, clang-format, clang-tidy, …) is horrible in those environments. And if you compare the quality of those tools to the one of other language, they are not even close. For exemple the lint given by clang-tidy to the one of Rust clippy.

If it took no more than an hour to add any of those tools to a legacy C project, then yes it would be disingenuous to not compare C + tooling with Rust, but unfortunately it’s not.

That’s a very, very good read on how to make a very complex C project safer in practice. To sum-up: make it possible to introduce new module in a memory safe language (Rust in this case), make it harder to write bugs in C since the C part is not going to disappear overnight, and use as much tooling as you can to find any existing or newly introduced bugs (both memory bugs a logique error).

What do you mean by that?

step 1: learn to comment everything. This will helps code reviewer to catch errors because your code doesn’t match the comments

step 2: write your code in a way that makes comments useless and stop writting them

step 3: write your code just like you did in step 2, but documents all the things that you didn’t do, or why the code is more complicated than the naive approach. If your arguments are weak you are not in step 3, but in step 1.

I do understant why old unicode versions re-used “i” and “I” for turkish lowercase dotted i and turkish uppercase dotless I, but I don't understand why more recent version have not introduce two new characters that looks exactly the same but who don't require locale-dependant knowlege to do something as basic as “to lowercase”.

I totally get the = async { body } (and I think I would prefer it for everything since it makes one liner like fn add(a: i32, b: i32) -> i32 = a+b much nicer and compact). I can also get the "ignore associated type” part. But I fail to see why removing the impl in -> impl Future is useful.

I did not saw Elevate Your Rust Code: The Art of Separating Actions and Calculations in my feed before. It was a good read

That's a very nicecly written article.

Just a quick question, isn't point 8 outdated (misconctption: “Rust borrow checker does adanced liftime analysis”) due to the introduction NLL (no lexical lifetime) in Rust 2018?

Couldn't this be solved by having push_back being an inline function (or at least the check on capacity being inlined and the rest of the non-trivial part being in a sub non-inline function)?