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

I think the main advantage of OOP is message passing - which, if you think about it, is pretty how networking works across the board. (This also makes sense if you think about Smalltalk's heritage).

Basically - if I send a message to a networked server - as long as my message is in the correct format and I send it to the right place - then I don't care about the implementation at the other end.

The fact that I send a GET request to HAProxy that analyses it, routes it and then passes it to Nginx that embellishes it and passes it to some application server that actually does the work is OOP in action. As the message sender, I need to know the protocol (message format) and where to send it - and that's it. The fact that the implementation goes through three layers and does who knows what is irrelevant.

The trouble is people looked at Smalltalk and took the wrong bits to be important (just like Steve Jobs did when Apple designed the Lisa GUI).

Now, there is a very similar problem with concepts like recursion. Even Algorithm, DS and problem solving in general. You never get to learn this stuff well because you get drowned in syntax juggling, type headaches, absence of good features to do recursion, first class functions, mutability, closures, pattern matching, and data handling etc well.

I find learning these things in ML or Lisp languages simplifies the problem to a great extent. You basically learn to how to solve problems and then how to use the right tools to solve the problems. Instead people chose tools that send them solving infinite sub problems to arrive at solving the real problem. Most people tune out, and rightly so. Efficiency comes after correctness in any approach. And you should never optimize for speed to begin with.

Most people getting introduced to programming in Java/C++ are generally digging through layers and layers of code trying to do what should be done simply in a straight forward way. This is often made more complicated by addition of frameworks and opinionated way of forcing people doing things in a way that requires them to go and read and work through an entire history of software literature. All the while you could just write code to solve the problem.

Design Pattern abuse is very common in OO world. And people for some reason like to write a lot of code sometimes for something as simple as writing a few lines of code.

Some examples of where global functions might make sense, the Main function of a console application doesn't need to be in a class, or the general Utils and Helpers approach soon becomes cumbersome, you end up having to name things that don't really need names. While static classes can help organise these global functions you also end up playing the naming game when you don't need to. It might not be any improvement but it's an interesting thought exercise to imagine functions living in just a namespace, not a class.

I think in C# static still doesn't give you enough guarantees at either the class or member level. A static class can still have public static mutable members which is a horrible code smell. C# contains enough flexibility to do the things I want, e.g. make things static and readonly, but it's a lot of additional typing and I'd be interested in seeing the model reversed, e.g. immutable defaults with something like `public mutable class Foo` which I remember having seen in other places (F#?).