Absolutely, usage of inheritance is (comparatively to Java/C++/Python) quite rare in Ruby.

People favour modules to compose (e.g Enumerable), and more generally interfaces (e.g duck-typed StringIO vs IO/File/etc...)

If you throw in RBS and start to type Ruby things then you start to see that Go-style interfaces pop up quite frequently.

What's this referring to?

Meaningless toy examples have the problem that they can appear to make sense, planting the seeds of terrible ideas.

If in a course example Dog extends Animal, it can be an arbitrary demonstration of language mechanisms (with an uncontroversial is-a relationship) but even in that case it is implicitly suggested that it is a good or "normal" design, implying an alarmingly complex program that has good reasons to deal with those two types.

Such a program is usually not described for brevity, giving the false impression that it exists: if the problem were analyzed with any diligence, usually Dog would appear a completely pointless complication.

I always disliked that phrase. In my experience one of the best ways to check whether you understand a subject fully is to teach a course on it.

> interfaces, traits, etc.

Those are actually mechanisms for achieving polymorphism.

Inheritence inherently (heh) consists of "inheriting" parent class' internals and having ability to extend them. It is basically composition, polymorphism and monkeypatching in a trench coat.

It's interesting that Python does support multiple inheritance.

Encapsulation is possible without inheritance. And "code reuse" is a vague concept that had nothing to do with inheritance in particular.

Not even gonna comment on "message passing".

Entity systems still rely on inheritance as you typically have an Entity baseclass that all entities derive from. That's just a single level of inheritance. Unity does this through MonoBehavior. Unreal is more inheritance-heavy but developers typically subclass something like `Actor` to one level of additional inheritance beyond the Engine's subclasses. A lot of engines will have multiple superclasses behind a Entity class, but that's an implementation detail of the engine itself and to the game developer, it's treated as a single base class that is typically subclassed a single time for the entity itself.

Even in ECS's you will often find inheritance. Some implementations have you inherit a Component struct, others will have the systems inherit a System class.

I'm sure it's still used today in some engines and by some developers but the overwhelming opinion is that doing something like Entity -> Actor -> Monster -> Orc -> IceOrc is a bad idea. Instead it would be like

   class IceOrc : Entity { components {Health, Enemy, PlayerSeek, Position, etc} }

   class Health : Component { value = 100 }

In addition to the underlying domain (and I agree, it’s no coincidence that windowed GUI widgets are common in in OOP textbooks), there’s also overlapping spectrums of language expressiveness and object-orientedness to consider.

The principle of least surprise, bad evil and scary techniques in general might be the orthodox, efficient and intuitive for maintainers in context. Templates in GUI frameworks versus business apps, for example.

Anything where you have literal "instances" of something with common state/behaviour is prime for inheritance, but that's different from trying to model a domain as a set of hierarchal objects.

But I do like classes - you can use them without inheritance, and the other stuff that comes with them (encapsulation, polymorphism, etc) fits my mental model. [0] Classes are just syntactic sugar over closures at the end of the day.

But inheritance is best when it's limited and shallow.

0:

  The venerable master Qc Na was walking with his student, Anton. Hoping
  to prompt the master into a discussion, Anton said "Master, I have
  heard that objects are a very good thing - is this true?" Qc Na looked
  pityingly at his student and replied, "Foolish pupil - objects are
  merely a poor man's closures."

  Chastised, Anton took his leave from his master and returned to his
  cell, intent on studying closures. He carefully read the entire
  "Lambda: The Ultimate..." series of papers and its cousins, and
  implemented a small Scheme interpreter with a closure-based object
  system. He learned much, and looked forward to informing his master of
  his progress.

  On his next walk with Qc Na, Anton attempted to impress his master by
  saying "Master, I have diligently studied the matter, and now
  understand that objects are truly a poor man's closures." Qc Na
  responded by hitting Anton with his stick, saying "When will you
  learn? Closures are a poor man's object." At that moment, Anton became
  enlightened.