I don't really see a pervasive point to this rant. It is true that OOP can be reduced to message passing, and that there's a specific style of OOP a lot of people see as "OOP", but that doesn't mean that this style is "just obfuscated procedural code, or uglified functional code". That OOP can be implemented on top of functional style code, or procedural style code says nothing about it being "true OOP" or not. For example, the great Common Lisp Object System is built with functional primitives. And that makes it more elegant, not less. Building an object system on top of a functional/procedural language is syntactic sugar, and there's nothing inherently bad about it. After all we write code for people to read.

I'd like the code complete approach. A method has 4 channels: api, status, input, output.

Reducing how many channels interact semplify code a lot. Oop went for input, status and statu, output pairs. Functional uses input, output and api, output pairs.

Good programmers understand that and apply the one which is proper to model their problem, to reach performance/memory goals and most importantly to reduce te cognitive load of large codebases.

Buddha about Language Wars:

Then the Buddha gave advice of extreme importance to the group of Brahmins: 'It is not proper for a wise man who maintains (lit. protects) truth to come to the conclusion: "This alone is Truth, and everything else is false'.' Asked by the young Brahmin to explain the idea of maintaining or protecting truth, the Buddha said: ' A man has a faith. If he says, "This is my faith", so far he maintains truth. But by 9 that he cannot proceed to the absolute conclusion: "This alone is Truth, and everything else is false". In other words, a man may believe what he likes, and he may say 'I believe this'. So far he respects truth. But because of his belief or faith, he should not say that what he believes is alone the Truth, and everything else is false.

(from "What the Buddha taught, a really great book!)

> 'I believe this'. So far he respects truth

What if he believes is objectively wrong?

He only talks about wise men who protect truth, so the truth being true is a given I'd say.

EDIT: Of course he's talking to people who swear by the truth they protect. Instead of telling them they're wrong, telling them others might be right is far more likely to get them to consider his point of view -- that other "truths" are just as equal.

It certainly beats using NodeJS.

EDIT: Yea, this was meant as a reference to the coreutils-in-nodejs post on the frontpage.

NodeJS is for applications, Rust is for system programming. How does one beat another?

It's akin to saying "ARMv7 assembly beats using Java for Android programming".

He is probably referring to this: https://news.ycombinator.com/item?id=11334597 -- discussion on CoreUtils in Javascript!

Ah, understood.

I think neither of these beats actual coreutils and their support base (still under impression of Termux capabilities...), at least not yet.

Rust is a general programming language, no need to constraint oneself to a single domain.

So is JS.

But like I said, both implementations suck compared to actual coreutils.

Parent comment probably refers to [1] submitted earlier today.

[1] https://news.ycombinator.com/item?id=11334597

Probably a response to this: https://news.ycombinator.com/item?id=11334597

It's a communication medium for me. Customer service is but a subset of it.

Apart from this being of questionable usability, why do people feel the need to solve every problem with (Node)JS? I can think about a ton of languages better suited for systems programming at the top of the hat.

Because JavaScript is the most widely used language in the world.

As a web developer, I know JavaScript very well. I have already encountered thousands of its idiosyncrasies and I am very good at making it work for me.

Therefore any tool written in JavaScript is automatically easy for me to understand and modify. If that tool could have been more elegantly written in another language, that's awesome for people who know that other language, but it's irrelevant to me. Even if I kind of know my way around the other language, I'm never going to be as effective with it as the language I use every day. And a lot of people use JavaScript every day. This is the reason why people feel the need to solve problems in JavaScript.

But JS can't solve every problem, nor can it solve certain problems well.

I understand people feel the need to solve problems in JS because they're scared or inconvenienced by learning a new programming language.

But why not learn a new language? Having a working knowledge of C won't kill you.

edit: could you explain how JS is the most widely used language in the world?

> Having a working knowledge of C won't kill you.

I do have some knowledge of C, and I could learn more. But unless I change career, I'll always be faster and more effective in JavaScript because I think in it all day, so I'll almost always choose JS over C. I'm not disparaging anyone who uses C, just answering @faaef's question about why people "feel the need" to make everything in JavaScript – because they can, they happen to know JS very well, and because there's automatically a huge potential contributor base.

> could you explain how JS is the most widely used language in the world?

I don't know, but I assumed it's the most widely used because websites :) Also it's the most popular language on GitHub

JS is definitely the wrong language for a number of programming projects. JS lacks a number of features that other languages have... on its own, that doesn't make it a bad language, but it means it's less useful for certain projects.

Like this one. Like the POSIX API that is actually compatible with other applications.

And by that definition of used, C and Java are pretty strong competitors, seeing as every SIM card and Bluray player and so many more run Java... and then there's Linux and its embedded RTOS cousins, etc., etc., that are written in C or C++. I think embedded devices beat out JS pretty well.

I'm not talking necessarily about elegance, but performance, safety, the ability to run on embedded devices, a widely-available toolchain and so on.

Apart from that, it's great to have a favorite language, but choosing a hammer for every task does not seem like the mark of a great craftsman for me.

I believe most people in every profession are not/do not aspire to be great craftsmen. And in the end, if their tools work, nobody cares outside of their immediate colleagues.

...and herein lies the problem.

What problem? I think we need a mixture of specialists and generalists

For fun and education? I am not a fan of the idea from a practical point of view, but it seems like implementing these things could be a nice learning experience.

Why would threading with GIL be worse than no threading at all?

As long as IO is your bottleneck the GIL shouldn't be much of a problem. And Python (and I'm sure Ruby, too) has excellent async support.

Not saying Node.js isn't useful, but I wouldn't automatically say no to Python or Ruby.

Fair point. I would probably use a multiprocessing approach in node.js or use https://www.npmjs.com/package/webworker-threads. If perf were very critical I would use Rust.