About the article you linked:

Author is removing every part of the initial function, admitting there are reasons those things are there in the first place, only to be left with a slightly more verbose version of an equivalent python implementation. Well then just use python?

Author also doesn't seem to understand what static polymorphism is/why this specific function is generic. It's not strictly about "bytes", it's about avoiding virtual calls/have nicer API. Author conveniently omits mentioning the clone() calls their version requires from the client call. Or they would make everything automatically cloned, and I already addressed that in the first paragraph I

Finally, standard libraries are notoriously bad examples of "normal" code. They mention it, but still declare that that their example is relevant. If the functions I wrote were compiled and used thousands of times per day I would probably worry more about splitting generic and concrete implementations. I'll take this over anything in the C++ standard library (which is a much more relevant language to compare rust with than e.g. python)

At first glance, sure it would be easier to read, but if you have to look for the types then things get much harder. Either the types will be in comments, on different lines, or in a different file entirely.

This is pretty much how OCaml works and you can omit the types altogether if you don't specify an interface file, in most cases. But it's not hard to deal with in practice since IDEs (and text editor + LSP plugin) can easily show the inferred type on inspection.

Nevertheless, I don't really find Rust to be ugly either.

I'm a long time C user Almost everything I write is in some strongly typed language lol

I still find C much easier to read and understand than any large Rust codebase