I think you missed the last sentence of the post:

Finally, when you reference a Git hash for posterity, e.g. in another commit message, I’d recommend always using the full value.

The git config is just for display purposes in terminal output. That only needs to be unique as of the time it's displayed; and as I noted, the current default behavior is to adjust the size dynamically, so the displayed hash segment is always unique no matter how big the repo is.

Have you considered that one property of actual, real-life human intelligence is being "too complicated to have precise guidelines"?

Maybe, but the comment I was responding to is not at all clear about what is deprecated and what is no longer an issue. Note, too, that the other top-level comment on the post is from someone who didn't realize that destructors can be missed.

I should have said "relatively simple", not "very simple".

https://programming.dev/comment/8548915

I should have said "relatively simple", not "very simple". Yes, modern assembly instructions can often be relatively complex (though not on all architectures). But the point is that every abstraction layer presents a simpler API compared to what's below, but must be implemented in terms of complex combinations of the fundamentally simple units of functionality in the layer below it. This is true of assembly, yes, but that doesn't make it less true of higher level languages.

Whoever named the "final final fixed" one seems to have missed the point of version control. 😑

...yeah, I already said that if there is another branch starting with those letters it should be deleted. You need a naming convention.

Oh, Nim is possibly even a better example because it is "transpiled" rather than compiled, meaning the compiler actually generates C or C++ code. You can then compile that with whatever compiler you want. However, I don't know of any major projects in Nim to compare against ones in C, C++, Rust, etc.

Edit: and Zig should be extremely efficient as well.

So...you had to make your own version of unique_ptr to make it zero-cost? Doesn't that just confirm the original statement you were disagreeing with, that unique_ptr has a small runtime cost? Or was there some other reason you thought the creator of the video you shared has "no idea" what unique_ptr is?

I also don't understand why the standard library can't use the trivial-abi attribute. Different implementations of the standard library aren't required to be interoperable, are they?

I still don't understand what you think is "apples-to-oranges" here. If you change the Rust code to require the C ABI, there's no difference in the generated code: https://godbolt.org/z/1xf9qG3n8

I hated the first nine words of this comment, but agree with everything else

Ada is still "new" compared to C, so I suspect the OP would have similar problems with it.

The question of what advantages Rust has over Ada is a good one, but I think it's been pretty well discussed already. Just a quick google for "Rust vs Ada" turns up lots of discussions.

I don't know Ada, and I love Rust, but it seems entirely plausible that the reasons for Rust's greater popularity is primarily social rather than technical. Before I learned about Rust, my impression from talking to more experienced C++ programmers was that Ada was an interesting language with good ideas that was ruined by being "designed by committee." Rust is at least the third major attempt to design a language specifically to draw some of C++'s user base, the other two being D and Ada (there are other examples that are more debatable; e.g. Erlang and Nim). But hey...at least one of them is finally gaining some ground!

Or Ruby, if you want to suffer less psychic damage...