I believe it's called Rust :)
Yes, but no.
When people design a language which they know is going to be incompatible, they tend to go all the way with it. If we're breaking it anyway then might as well do a better standard library interface than the stuff designed in the 90s and all that sort of thing, right? And that's good to have for new projects.
But there is a benefit in having something which makes the smallest possible compatibility-breaking change to fix the defect in the original. So you have a "new language" with a borrow checker, but the standard library functions all have the same names and the same purpose and time complexity as the C and C++ ones, which would allow people to run the existing code through a transpiler which for 80% of the lines can be translated directly to working code in the new language, and produces diagnostic errors for the other 20% that explain what needs to be changed.
Which removes 80% of the work from transitioning an existing codebase to the new language. And then more people do that.
Less implicit means safer but also more verbose and more cumbersome to write.
Rust priorities safety over everything else, also over productivity too in some case.
Absence of function overloading and automatic type conversion is a good example of that in Rust.
Is it the right choice ? Only time and multi-million line codebase will tell us.
Rust does not provide the facility to strategically obfuscate code at scale like C++-style function overloading does.
// C++
auto f() -> int32_t {
return 1;
}
// Rust
fn f() -> i32 {
return 1;
} fn i = 0;