Node.js Interview: 4 Questions with Creator Ryan Dahl | Hacker News Reader

Node.js Interview: 4 Questions with Creator Ryan Dahl

bostinnovation.com

53 pointskmccarth13 comments

My first question is "why not coroutines?!"

I love Lua (IMHO, Lua is Javascript, if JS hadn't spent its formative years huffing glue). I get where he's coming from with the "most libraries are blocking" bit, because hey, most libraries ARE blocking -- making a fully event-loop-centric system really is a niche case. If you want to focus on that 100%, cool, use Erlang, damn it. They did it right! Failing that, make a clear point of running "non-async" code externally and message-passing.

But I really don't see the point of deluding JS programmers into writing hand-written-CPS "to be asynchronous". I wish they knew better. See e.g. http://news.ycombinator.com/item?id=2150800

The two most interesting points for me:

* JavaScript wasn't the original language choice: he originally tried C, Lua and Haskell. He especially liked Lua but "it already had a lot of libraries written with blocking code."

* He regrets using the CommonJS module system. ("Far too complex and wildly different from how the browser works.")

Yes, especially on the first: he picked JavaScript specifically because it had so few libraries (implicitly: for a well-known and likeable enough language). Conversely, had he picked a language with lots of existing (blocking) libraries, node might well have been dismissed as broken or half-assed.

> He especially liked Lua

Well, not as much as Haskell : "Haskell is pretty ideal but I’m not smart enough to hack the GHC. Lua is less ideal but a lovely language [...]" (at the beginning of the 2nd answer.)

> He regrets using the CommonJS module system

Yes, and this is pretty interesting. Also, he regrets using WAF as the build system ("it introduces more WTFs than necessary".)

I have a great respect for Ryan Dahl. He is not orthodox. He is not a blind parrot.

Heh, I got the impression that he tried harder to get Lua working, partly because he felt is was a more pragmatic choice, but I take your point.

And I do take yours. The fact than Node is actually using Javascript, which is more similar to Lua than to Haskell, makes your impression very sensible ;-)

The good news is someone else did 'hack' GHC and gave it a nice new IO back-end. http://johantibell.com/files/hask17ape-sullivan.pdf

Given that list of languages, one wonders why he didn't try Erlang, except inasmuch as it already has pretty much everything Node.js has now and more....

I heard it's bad at strings or something.

If he'd put as much effort into Erlang as he has into Node.js, that would be a solved problem now.

Actually, if he put as much effort into Erlang as he did into Node.js as of about six months ago, it would be a solved problem now. Some inspiration from Haskell could have proved useful, too; Haskell has finally gotten over the "strings are linked list of numbers" stupidity (amazing what being really concerned about performance will do for you) and are finally doing really interesting things with strings based on binaries.

That was sarcasm. I get the impression that many of the people put off by Erlang's strings are unaware of atoms, too.

The string type could be better, certainly, but the language has plenty of other aspects to make up for it. I hear Java is bad at {atoms,pattern matching,fault tolerance,...}.

Sorry, I have a bad habit of springboarding off the sarcasm without making it clear I got it. :) Seriously, they're months away from the point where they will discover they can't replicate Erlang on top of JS no matter how smart they are; I'm very down on Node.js's long term future because trying to build it on top of JS was locally a cool hack but globally an unrecoverable error. They're not done applying their first coat of whitewash and not interested in being told that a whitewashed Pinto is still not going to be a race car.

No kidding. I was working on a very similar, event-loop-based system in Lua, but after spending more time with Erlang, I realized that it was already done a million times better. Lua's very good for other stuff, but massive concurrency is not its focus.

I wrote a (somewhat limited) Lua asynch. webserver to provide a REST interface to my distributed filesystem, but I'm not interested in generalizing it or making it uber-scalable anymore. It uses select (luasocket.select, actually), which is quite good enough for my purposes. It's not the primary part of the system, anyway - it was actually feature creep.

The thing that really bugs me with node.js is writing everything in callback-passing-style. Coroutines are SO much cleaner.

Reply on news.ycombinator.com