mantrax6

But, of course, the "if we don't like Node.JS, we just don't understand the true way(tm) of using it" card.

Such narratives usually get louder and louder, until they flip and all the former supporters of X suddenly proclaim "I can't keep quiet anymore, I must speak against X".

I've seen this too many times.

I like Node.JS, it's a good thing it exists, but no technology is perfect and we should be capable of honestly discussing the strengths and weaknesses of a given technology.

No comment on typing, if you can't bother to do basic research over whether what you say makes sense in real projects.

I'll just say that in 2014 proclaiming that your multicore application architecture is spawn() and fork() can only induce laughter in the presence of proven distributed computing algorithms that don't require every developer to use a roll-your-own message passing library and protocols.

Fieldman's work doesn't exist in vacuum. He talks about HTTP, and HTTP has the verbs it has. It's hard enough to find consistent behavior in HTTP servers and proxies with "PUT" and "DELETE" let alone anything else. But even ignoring that, the verbs the spec talks about are limited. And that's a big problem.

As for RPC, essentially any communication between machines is a RPC. It's message passing ("call") and if the message arrives on the other end it's processed by a message handler ("procedure").

No server can just reach into another server's RAM and get or modify a resource directly. The interaction happens entirely by the will of the message receiver, and in exactly the way the receiver wants (not the sender).

So if we'll be building everything on an appropriate abstraction, it better match what really happens (messages, message handlers) and not some wishful thinking abstraction layered on top (resources, resource modification).

RPC is not REST's problem. The problem is the limited commands (PUT, POST, DELETE) and the single possible query type (GET) that we need to work with.

When a payment gateway has to represent a simple "process payment" command with a series of bogus abstractions like a "POST /payment/transaction/new", you know REST is the wrong tool for the job.

None of them are dead. As for why, long story short, because HackerNews' code is really poorly written. Gateway errors, horrendous response times, bogus limits and false positives. My usage patterns are likely not typical, but this is hardly an excuse for such a poor UX.

For example, I couldn't even respond right now through mantrax5...

Next time I'll just take the alternative and instead of making more accounts, I'll just stop visiting the site completely.