Why don't you agree not to talk about stuff you have no clue about?
a) inheritance is not an antipattern
Using it wrong might be an antipattern in the moment where it is used
b) multiple inheritance is not an antipattern either
For example the infamous "diamond pattern" only happens if you actually program it: intentionally. And there are plenty of use cases where MI is useful. Perhaps you should read some books about C++ before talking BS?
c) strictly speaking: JavaScript has no inheritance art all!
JS has syntactic sugar, that looks like inheritance in many cases, but is, oh oh, you hate it: a linked list of prototypes. The moment when you "inherit" in JS, you are actually referencing to another _object_, not a class!
The main problem is that people use languages in the same way as they used to do in another language. E.g. many C++ guys came from Smalltalk. So they use inheritance similar. Of course the main difference is static versus dynamic typing. Hence early class libraries for C++ looked over engineered. In Smalltalk you can beam methods into classes via meta classes. So you do not need MI. And also: two classes implementing the same method signature: do not need to have a common super class ... as dispatch is dynamic anyway.
For examples: Dart, Java and C# Generics are not the same thing. All work slightly different. And only C++ and some esoteric languages have real templates, you understand what that means, when you once did template meta programming.
The power of C++ is for example shines when you combine templates and MI. Before I give an example, most SI languages cheat anyway, and offer an alternative in one way or the other: with mixins or traits. And some do it really badly, for example Java with interfaces that have default implementations.
So, when do you use inheritance, oh, in C++ for example, you can inherit "privately" then you only get the implementation of the base(s), and your public inheritance chain looks clean. When I write a GUI framework however, why the fark would I _not_ use inheritance? Not using it would be completely braindead.
Now imagine a linked list class - called Link - with one template parameter, which is an enum, and one to mix in a base class.
enum { up, down } UpDown;
enum { next, previous } NextPrevious;
class CADPoint {
float x, y, z;
}
class MentorCADPoint : public ThreeDCADPoint, public Link[UpDown, MentorCADPoint], public Link[NextPrevious, MEntorCADPoint] {}
Instead of keeping your CADPoints in external lists of what ever kind, they have their list structure embedded, flat, in the MentorCADPoint class.
Yes, you inherit two times from the same template, but it has different template arguments. In reality you most likely would use protected inheritance ... or make the algorithms traversing your points, friends.
The only problem with inheritance is that most books explaining it: explain it wrong.
Neither a seaplane nor a water plane is crafted by inheriting from a boat and a plane ...
Your main problem is: you never were in a team with good developers. So your conclusion about the big world of developers: is simply plain wrong. Unfortunately you live in a world of hire cheap, and fire if necessary. I live in a world where we hire excellence and try to make them never leave. And: we do code reviews. The guys not grasping the code get educated. Unless the code is in fact to complex and gets refactored.
For example: I do not know a single bad C++ developer. They are all top notch, not only in C++ but in basically everything regarding "code". However: we all shifted away from C++. Well, with the new fresh wind, see "circle C++" https://www.circle-lang.org/si... and https://github.com/seanbaxter/... it is perhaps time to take a look again :P Does Qt compile with circle c++? Oh oh ... potential potential ...