Ask HN: Why do new(ish) programming languages eschew OOP features?

   {...students(ajaxDb), ...teachers(ajaxDb)}

   public class StudentsAndTeachers extends Students implements IStudents, ITeachers {
       private _teachers;
       public constructor(Database db, Teachers teachers) {
           super(db);
           _teachers = teachers;
       }
       public getTeacher(TeacherId teacherId) {
           return _teachers.getTeacher(teacherId);
       }
   }

   new StudentsAndTeachers(ajaxDb, new Teachers(ajaxDb));

(More likely, you wouldn't write this, but every example that is colloquial in inheritance is non-colloquial in composition. The composition oriented solution can be used cleanly with strong guarantees provided to its users; whereas all inheritance oriented solutions are so tacky and hard to use that you will demand a framework with dependency injection which half your team won't be able to understand and will have to treat as magical incantations.)

But in its traditional Gang of Four incarnation (which I encountered years later as a newbie), it felt like an awful lot of ceremony and unneeded complexity to get anything done.

Inheritance has too easy syntax to avoid "accidental duplication" (pieces of code seem similar on short term but eventually differ on the long run) without creating a new common abstraction to depend on: even before realizing the introduced dependencies are unnecessary but now even deeply entangled. Because in its core what might just happened is "raw" code(text) reuse instead abstraction reuse. "Code duplication is better than wrong abstraction." Or "Write code what is easy to delete."

You might keep adding and adding until you won't be able to substract, because you have to check every dependency back and forth, and there are no layers of abstractions but a constant change of [meaning] with the hope of usefulness in future infinite far away. Additionally intermediate level classes also need names (and meaning...) which makes the naming problem constant and might even blur the clear lines between the originally clear abstractions. The language of our system/domain consists of the relation of individual abstractions, we can't just overload every word and/or litter with unnecessary ones.

It's also a question to decide when to write a class and instantiate instead of just using an adhoc "anonymous" object and use a necessary pattern like factory function or some delegation (like parent class) later if needed. (Ofc. classes might be created later as well, but weird enough it goes the other way around in my xp, maybe its just me, ruined by noob Java 1.6/C# habits gained at the first years of university).

It's too easy to find wrong abstractions with inheritance, too easy to blur good ones, and too hard/exhausting to delete them.

Reflection on the thread: I think I'll focus more on the proper naming of functions "DO"s instead of "WHAT"s, because DOs must have clear intent to drive the design/architecture.