I think you have a hard time understanding the différence between “not possible” and “much harder”.

In Rust, the code does not compile.

In C++ the code compile, but

• if you have a test case
• this test case triggers the bug (it is not guarateed to properly reproduce you production environment since it depends on the parameters of the allocator of your vector)
• you use ubsan

… then the bug will be caught.

Yes it is possible, noone says the opposite. But you can’t deny it’s harder. And because its harder, more bugs get past review, most notably security bugs as demonstrated again and again in many studies. The

That’s why I did not said it was impossible, just order of magnitude harder to catch in C++ compared to Rust.

To have asan finding the bug, you need to have a valid unit test, that has a similar enough workload. Otherwise you may not see the bug with asan if the vector doesn’t grow (and thus ref would still be valid, not triggering UB), leading to a production-only bug.

Asan is a wonderfull tool, but you can’t deny it’s much harder to use and much less reliable than just running your compiler.

void foo() {
    std::vector v = {0, 1, 2, 4};
    const auto& ref = v[1];
    add_missing_values(v);
    std::cout << ref << "\n";
}

void add_missing_values(std::vector<int>& v) {
    // ...
    v.push_back(3);
}

Neither foo(), nor add_missing_values() looks suspicious. Nonetheless, if v.push_back(3) requires v to grow, then ref becomes an invalid reference and std::cout << ref becomes UB (use after free). In Rust this would not compiles.

It is order of magnitudes easier to have lifetime errors in C++ than in Rust (use after free, double free, data races, use before initialisation, …)

Is it possible to do in Rust?

Yes

Is possible to do in Rust, by mistake, and not easily caught by a review?

Definitively not.

DRY and YAGNI are awesome iif you also practice YNIRN (You Need It Right Now)! Otherwise you just get boilerplate of spaghetti

You got me in the first 3 quarters, not gonna lie!

There are cases where instead of origin/master..HEAD you may want to use @{upstream}..HEAD instead to compare with the upstream of your current branch. It’s unfortunately quite unknown.

The quote (and the associated discussion) is such an important part of Rust and why I love this language so much. Anything that can be automated should at one point be automated reliably, and the sooner the better.

I never understood why python won agaist ruby. I find ruby an even better executable pseudo code language than python.

Read your own code that you wrote a month ago. For every wtf moment, try to rewrite it in a clearer way. With time you will internalize what is or is not a good idea. Usually this means naming your constants, moving code inside function to have a friendly name that explain what this code does, or moving code out of a function because the abstraction you choose was not a good one. Since you have 10 years of experience it’s highly possible that you already do that, so just continue :)

If you are motivated I would advice to take a look to Rust. The goal is not really to be able to use it (even if it’s nice to be able able to write fast code to speed up your python), but the Rust compiler is like a very exigeant teacher that will not forgive any mistakes while explaining why it’s not a good idea to do that and what you should do instead. The quality of the errors are crutial, this is what will help you to undertand and improve over time. So consider Rust as an exercice to become a better python programmer. So whatever you try to do in Rust, try to understand how it applies to python. There are many tutorials online. The official book is a good start. And in general learning new languages with a very different paradigm is the best way to improve since it will help you to see stuff from a new angle.

I wasn’t clear enough. But in a contry where the sun rise at 20:00, the weekday looks like:

• day 1: Monday morning to Tuesday evening
• day 2: Tuesday morning to Wednesday evening
• day 3: Wednesday morning to Thurday,
• …

And phares like "let’s meet on Tuesday“ without hour indication could either mean end of day 1 or start of day 2. Likewise "let’s meet the 20th” (assuming the 20th is a Tuesday) could either mean end of day 1 or beggining of day 2.

–

And alternative be to have

• day 1 == Monday == “end of the 19th” to “the start of the 20th”
• day 2 == Tuesday == “end of the 20th” to “the start of the 21st”
• day 3 == Monday == “end of the 21st” to “the start of the 22nd”
• …

Which solve the issue of "let’s meet on Tuesday”, but not “let’s meet the 20th”.

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 ?

Interesting idea indeed. I’ve never used async yet, but I’m always surprised at how the problem space seems to be much more complicated than what it initially looks like.

You shouldn’t, it’s short and interesting

I would have liked a link to the LKLM thread. Usually they are quite informative

I use a 42 key layout modified from bépo (french dvorak inspired layout) with the altgr layer of ergol. Go check this altgr layer it’s awesome for programming, and there is a version compatible for qwerty and lafayette.

╭╌╌╌╌╌┰─────┬─────┬─────┬─────┬─────┰─────┬─────┬─────┬─────┬─────┰╌╌╌╌╌┬╌╌╌╌╌╮
┆     ┃   ¹ │   ² │   ³ │   ⁴ │   ⁵ ┃   ⁶ │   ⁷ │   ⁸ │   ⁹ │   ⁰ ┃     ┆     ┆
┆     ┃   ₁ │   ₂ │   ₃ │   ₄ │   ₅ ┃   ₆ │   ₇ │   ₈ │   ₉ │   ₀ ┃     ┆     ┆
╰╌╌╌╌╌╂─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┼╌╌╌╌╌┤
·     ┃     │   ≤ │   ≥ │  *¤ │   ‰ ┃  *^ │     │   × │  *´ │  *` ┃     ┆     ┆
·     ┃   @ │   < │   > │   $ │   % ┃   ^ │   & │   * │   ' │   ` ┃     ┆     ┆
·     ┠─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┼╌╌╌╌╌┤
·     ┃     │   ⁽ │   ⁾ │     │   ≠ ┃  */ │   ± │   — │   ÷ │  *¨ ┃     ┆     ┆
·     ┃   { │   ( │   ) │   } │   = ┃   \ │   + │   - │   / │   " ┃     ┆     ┆
╭╌╌╌╌╌╂─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┴╌╌╌╌╌╯
┆     ┃  *~ │     │     │   – │     ┃   ¦ │   ¬ │  *¸ │     │     ┃           ·
┆     ┃   ~ │   [ │   ] │   _ │   # ┃   | │   ! │   ; │   : │   ? ┃           ·
╰╌╌╌╌╌┸─────┴─────┴─────┴─────┴─────┸─────┴─────┴─────┴─────┴─────┚ · · · · · ·

Yeah, this make sence

It’s also what I understood from what I read but I assume it was just a poor choice of word. Debug symbols are way too important for debugging to be stripped by default.

If you have references explain why and how that it’s easier to port C to a new architecture by creating a new compiler from scratch than to either create a backend for llvm (and soon gcc) or to create a minimal wasm executor (like what zig is doing) to this new architecture I’m interested. And of course I talking about new architectures because it’s much easier to recreate something that as already be done before.

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.