(Safe) Rust is a lot better about the "Pit of Success" design than C++
There are fundamental technical choices to deliver that, but also ergonomic things like notice Rust's []::sort is a stable sort, whereas C++ std::sort is an unstable sort. If you don't know about sort stability in Rust what you wrote works and in C++ you get a nasty surprise.
C++ has std::sort() and std::stable_sort(). You should write what you mean, and you should know and understand your tools. Blaming the tool for your ignorance marks you as significantly less than an artisan.
Sort specifically is kind of a weird example, but C++ is full of awful naming.
std::map (which is not a hash map, which is what most people would expect), std::move (which doesn't move), std::vector (which is not a vector), and std::vector<bool> (which is not even a std::vector).
Sure, both languages offer both generic comparison sorts†. But the defaults matter and as always in C++ the defaults are wrong, here it's reflected in naming.
That's not actionable information, except in the sense that the correct action is "don't use C++". Because sure, I know about sort stability, and I know about pointer provenance, and about memory ordering, but there might be any number of things I do not know and unfortunately in C++ "you should know and understand" absolutely everything at all times, which is not viable.
† The C++ standard library sorts are both much slower than in Rust, but hey, they're also both less safe so you're really getting the worst of both worlds
> Sure, both languages offer both generic comparison sorts†. But the defaults matter and as always in C++ the defaults are wrong, here it's reflected in naming.
Why, exactly, is the c++ std::sort "wrong"? There are tradeoffs both ways. You happen to prefer stable sorting to speed, but that is a preference not an objective fact.
It's silently an unstable sort, which is surprising, and then to add insult to injury it's also slower. Yeah, I know, the C++ unstable sort is so slow it's slower than Rust's stable sort.
YMMV for input types, sizes etc but generally that's what the numbers look like and though it's not universal it's actually quite common. "I bet the C++ is faster" is the wrong instinct, sometimes by a large margin.
And stable sorting typically allocates large amounts of memory, which is also an unpleasant surprise.
I prefer the C++ naming convention, because it matches my expectations. When I studied CS, quicksort was considered the default sorting algorithm, and stable sorting was therefore a special case.
My pet peeve is that standard library sorting algorithms are still mostly single-threaded. Multicore CPUs have been the norm for ~20 years, but standard libraries still don't offer reasonable algorithms for sorting large arrays.
You are failing to make an argument for why stable sorting is objectively the correct choice. Just because something doesn't match your expectations doesn't make it wrong.
It's not so simple that you can just declare what is surprising. Surprise depends on context, and not everyone will have the same context as you. You say you would expect the term 'sort' to mean a stable sort, and I would expect it to always mean in-place sorting, others may expect it to use the absolute fastest way to get something sorted... Different users will have different priorities and therefore expectations.
Sort stability does not matter when the sorting key is the only thing in your data being sorted. E.g. When I sort my M&Ms by color, I never keep them in the same order, because it doesn't matter. A red M&M is a red M&M. Nobody expects their red M&Ms to remain in the same order after sorting. I do tend to expect my M&M sorting to happen in-place. I expect to not need to provide additional candy holding bowls to later clean up that were used for temporary storage while my M&Ms were getting sorted. But I'll optionally grab additional bowls when I'm in a time crunch it if it speeds things up...
Now, if we're sorting all the cars on a parking lot by color, it may be more important to keep all the red cars in the same order where they started, for example if they were previously already sorted by brand, it /can/ be useful if that is preserved. But it's not guaranteed to be important or useful. Maybe the rich owner just want to torch all their red cars all together. I typically won't have access to additional temporary parking lots only used during sorting, or maybe the owner is coming with a flame thrower at 1PM and it has to be done as fast as possible whatever the cost. There is a tradeoff, rent additional parking lots during sorting, or take more time and do in-place stable sorting, or jumble up the car brands.
So what I want is control. That's all. Whether or not the ambiguous term 'sort' is stable or unstable, or in-place or not is just semantics. The only way to get clarity is to either use prior agreement, or to not use ambiguous names. Maybe a language should ban 'sort', and only allow 'foo_sort_bar' names with stability of memory usage postfixes or prefixes to 'inform' the developer. Neither choice is ideal and will satisfy everyone. It's like being a DJ at a high school party.
I'm not saying that the STL is great in practice, since it appears to optimize for usage flexibility with defined algorithmic and memory complexity at the big-O level, and mostly disregards actual real-life metrics. Arguing, however, that a language or library is better because an objectively ambiguous choice was made differently than your expectations is like arguing for fundamental superiority of either endianness over the other.
There are fundamental technical choices to deliver that, but also ergonomic things like notice Rust's []::sort is a stable sort, whereas C++ std::sort is an unstable sort. If you don't know about sort stability in Rust what you wrote works and in C++ you get a nasty surprise.