[kllrnohj]

> In most languages, if you take two features and use them both, they add up.

Java nio vs. io

Java Reader vs. InputStream (not necessarily the interfaces themselves, but the redundancy between them eg should I use InputStream -> BufferInputStream -> InputStreamReader? Or InputStream -> InputStreamReader -> BufferedReader?)

Java float[] vs. ArrayList<Float> vs Vector<Float> vs. FloatVector vs. FloatBuffer - just how many ways can we describe "a linear allocation of numbers" in Java at this point? And they're still adding new ones!

So no, other languages don't just magically handle this more gracefully than C++ does. If a language is successful, it will either suffer from this or it'll stagnate - it's the natural consequence of preserving backwards compatibility while adding new features & capabilities.

[ttfkam]

Reader is for text/characters while InputStream is for bytes. An InputStream always lays at the heart of a Reader. Java's I/O may not be the most elegant of simplest, but it makes additive sense assuming you don't just have a bone to pick with the language.

The float examples are artifacts of pragmatism between plain old data types versus heap allocated objects. Though I do admit Vector<Float> is absolutely obsolete and should be avoided. The others have a clear purpose and raison d'être.

Now java.util.Date on the other hand…

[kllrnohj]

> The others have a clear purpose and raison d'être.

Yes, but they don't compose cleanly together. As in, I can't just use FloatVector in all places that took a FloatBuffer previously or whatever. They aren't additive in an incremental migration sense, they are additive in the "these are just wholly unrelated APIs in their own wholly distinct silos" sense. Aka, the thing C++ is regularly slammed for doing even though it's additions aren't even this clunky.

[wiseowise]

Don't forget Date/Time classes. Absolute mess.

[pjmlp]

Something that .NET also missed to fix.