robinm

First experience with #jj #jujitsu

I tried the equivalent of git add -p (jj squash -i).

• I realize that it’s closer to git add --interactive (which I find much more complicated and less productive)
• I wasn’t able to edit a hunk (like the e key in git add -p) which I use a lot to split debug statements from real work

I generated a conflict (as I expected)

• I found no way to show the original diff
• jj undo did not worked (I have not been able to undo the jj squash that introduced the conflict

Very not impressed so far. Fortunately it was a test repo.

Like how the average computer user is never going to [...] install Firefox or whatever.

Not right know but in 2005-2010 (or something like that), the average user was installing firefox because IE was so bad. It used to be at 80% market share IIRC.

It's really nice to see this RFC progress

I never realised it was that simple to do. Thanks a lot to answer the OP question. I had the same for longer than I wish to admit given how easy the answer was!

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 fact that rustc has bugs (which is what cve-rs exploit) doesn't invalidate that rust the language is memory safe.