The thing that the author seems to miss:
Node is basically just using JS as a scripting layer for libuv. It’s not that multitasking is hard, it’s not that richer threading models aren’t available–it’s that, as a punt, it’s pretty straightfoward to use a language with low impedance mismatch with async I/O to get something up and running.
From this, everything else about Node–the good and the bad–follows.
tl;dr: the author wants to talk about how good Elixir is, but can’t do it without trampling on other technologies with unfit comparisons.
Yeah. I mean, OK cool, I have no love for Node either, but I’m also of the opinion that “safe” and “dynamically typed” is an oxymoron, so I guess that would exclude Elixir for me too.
This is a weird post.
Part of the point of Node is that all the libraries are aware of the cooperative threading model, and the default APIs are non-blocking (with callbacks). Thus you can get the performance advantages of event-based asynchronous I/O without thinking about it too hard. (Which you can then throw away without thinking too hard either, by doing CPU-intensive tasks on your single event loop thread. No free lunch here.)
I think his point is pretty sensible - the Erlang/Elixir/BEAM runtime is pretty cool beans, especially compared to NodeJS.
If you’ve got other things that we should check out that are cool from statically-typed land, I’m always on the lookout for something new and interesting.
The point is that if you want to show an ecosystem proper, do it on its own right. Elixir is great, BEAM is too, but most of the parts they are good at are shown much better in isolation, without slinging mud at Node.
The post is neither fish nor fowl: it’s not a good criticism of Node nor a particularly good endorsement of Elixir, because it is based on the poor criticism of Node.
By all means, programming languages must be criticised, but hyperbole rarely is it. Not because it’s out of line, but because it doesn’t stick particularly well. It’s fun to read, but not lasting.
Nah, I would be into it though.
I use Go exclusively on the job and I’m happy. I would like a Supervisor model thingy but Go doesn’t really have one (I think I read a post about why it was hard but I forget) and Google does something similar with the entire process instead (Borg will just restart a dead task), so there’s no real push for it to change.
At least, faster than Python.
At least, faster than Python.
That’s arguably a tossup.
Except that in every day actual use it’s not.
Had no idea this site existed and it’s incredible thanks!
It’s a neat site, but sometimes it’s misleading.
People have a tendency to submit code using tricks that would normally be avoided or frowned upon. For example, checkout how many of the Haskell samples are using unsafe modules to avoid laziness and immutability.
That’s not against the rules, but it’s good to be aware of.
Sure that is true but if you know the languages you can see “is this normal”. For the JS and Python top few examples they seem to be relatively normal.
Shame they don’t show how fast the “bad output” was generated, that would be an interesting benchmark.
Yeah, if you use libuv in Python, you’ll get the same I/O performance as Node, which uses libuv.
But the actual CPython interpreter is horribly slow compared to V8’s JIT. PyPy is better than CPython, of course.
Also, I’ve tried async Python 3 and it’s honestly somewhat clunky. The awesome thing about ES6 async/await is that it just uses promises, which makes it trivial to integrate with code that doesn’t use async/await syntax.
You read my mind. At the very least don’t hand wave - SHOW ME. Prove your mastery of both technologies by comparing and contrasting the code. if you can’t, you’ve no business writing the article IMO.
I think the main reason is that node.js is just a more highly ‘engageable’ keyword. So if you have a title that says “my opinion about Elixir” there would be many fewer clicks than if you have your title as “NODE.JS IS BAD also elixir”.
Another approach found in Clojure is to use threads coupled with persistent data structures. These data structures are immutable from user perspective, but use structural sharing internally for common data. This avoids the problem of managing shared state between threads without having to do wholesale copying of the data.
I’m sorry but the English in this post is really bad :(
He’s Finish. And the post is in GitHub. You could help him out.
hmm but given the title I don’t want to help him out.