No, it does not- that is due to orthogonal choices. There’s no need to conflate Go’s lack of generics with its simplicity, especially when the designers are at this moment working on adding them in some form.
Let’s take another example, since I said there were a lot of languages with this goal. To cater more toward your personal preferences, let’s look at 1ML. Their goal is to unify previous MLs’ features into a “small and consistent language.” 1ML has generics and sum types and modules, so clearly this goal is not incompatible with your pet features.
What it is incompatible with is something like Haskell, which is in a lot of ways the C++ of the ML family. And that’s fine, because Haskell’s goals involve being a place where people can research new language features! This obviously isn’t a perfect comparison, but Haskell is a huge language with quite a few overlapping “feature zoo” situations.
I will also say, as has been said before, that things like field initialization shorthand, GATs,
try blocks and
try fn, and
const fn are not “feature zoo” candidates, specifically because they “fill in” a very particular kind of “holes” in the language, removing special cases and making Rust more orthogonal.
This is in stark contrast to
impl Trait or
throw, which introduce new special cases and make the language less orthogonal. For example, in a perfect world without implementation time constraints, I would have preferred that we just got
abstract type without
impl Trait, and especially not