This is true, to some extent. See e.g. Erlang and Prolog (though they have both forms of overloading really: functions pattern match their arguments, and this can be used for overloading).
The problem really is that language design informs and shapes the language culture. The path of least resistance is by and large followed. I expanded on why I didn't want overloading in the zulip thread:
(1)But the TLDR is that the devex is worse in languages like C++ that have this feature (C# also according to @scottmcm):
- Error messages end up with "no overloading matching ..., did you mean <list of 17 different things>"
- Code review becomes harder (no type info in GitHub, Gitlab etc)
- Navigating code in your editor becomes harder: clang and RA will often not know where to go when you use macros (Rust and C++) or templates (C++, duck typed) or generics (Rust, currently OK but RA would be confused if I tried to ctrl click inside f() above to go to the inner function). If you are working on a large code base with other people this quickly becomes a problem. Having unique names make things easier to find.
- Writing code but becomes worse: the IDE will give you less good completions when you are filling in arguments to an overloaded function, and often it will second guess which one you are using and start completing for a different variant. In Rust you select up front by writing different function names.
So, I just don't think it is worth the cost or risk to support function overloading on Rust in a "native feeling" way.
Named arguments is less risky, as the tooling doesn't tend to get as confused. The main risk there is that it encourages overly broad APIs.