Live data from Hacker News

Interview with Ryan Dahl, Creator of Node.js

mappingthejourney.com

191–200 of 235 posts

Re: Interview with Ryan Dahl, Creator of Node.js

#191

Earlier quoted context omitted.

Maybe he's talking about when it got popular, not when it was literally invented...but I guess you can just be pedantic and miss the point.

I was seeing frameworks in ColdFusion referencing MVC back around 2001.

Yeah, MVC was well known to the Visual C++ community in the 90s, and it was a well established concept among commercial (as opposed to academic) programmers even back then.

Re: Interview with Ryan Dahl, Creator of Node.js

#193

Earlier quoted context omitted.

I'd suspect NGPT was abandoned because they couldn't use growing stacks while staying compatible with C calling convention (but I wasn't able to find any confirmation of this by googling). Go doesn't have this issue because it uses another calling convention.

Stack growth is orthogonal to the M:N vs. 1:1 distinction. You can have large stacks with M:N or small stacks with 1:1.

Are you saying we could use a 1:1 threading model with growing stacks (by growing stack I mean a stack that starts for example at 2 KB and is grown as needed)?

Re: Interview with Ryan Dahl, Creator of Node.js

#195
post #23

A serious problem with Node was the callback pyramid of doom. This means deeply nested callbacks such that the indentation wanders steeply to the right. When you do loops or have exceptions programming got very confusing. In effect you have to do a continuation passing transform. It's not difficult but the results are utterly unreadable. For example a simple for loop could be transformed into recursive function becau…

When green threads, fibers etc. were a hot topic in the node.js community I was pretty involved in core development.

As far as I remember, we were never so much against the idea of it, but we didn't believe an actually good implementation was possible.

The primary concern was scalability. At the time supporting high concurrency networking (10K+ connected clients) was a top priority for us.

The solutions proposed by Laverdet and Jouhier used libcoro or fibers to achieve the desired "cooperative threading"; this may not involve actual OS threads but it does require the creation of a thread stack for every fiber. To handle 10K connections you would need 10K stacks so you have to allocate 40GB memory right there, too much.

We were aware that there were more effectient ways to do it, but this would have big changes to the V8 javascript engine. We didn't have the resources (nor the skill) to get it done and take on the maintenance burden.

There were also concerns about the surprising language semantics it created; suddenly callbacks might run "inside" a function, e.g. after it's called and before it has returned, not something a javascript user would normally expect to be possible.

Nowadays with async/await the callback-hell problem is actually solvable (to the extent that node-fibers solved it, anyway). It'll take time though before that becomes noticable, because a lot of packages need to change their APIs to take advantage of it.

Re: Interview with Ryan Dahl, Creator of Node.js

#196
post #88

Earlier quoted context omitted.

So if I don't like Java and C, what's your suggestion I should use instead to get the best of both worlds and not the worst?

Any language that uses the actor model for concurrency which is basically every language created in the last decade. Elixir, GO, Akka framework for Java and C#, Pony, Dart, Erlang, ELM, SCALA, ...

F# with it's built in actor model, robust OCaml based syntax, great support for functional Akka[.net] actors, simplified concurrency and asynch programming support, and very own ELM implementation is a great contextual answer for anyone who wants to be on the front lines of lightweight non-blocking concurrent & parallel web development in .Net land.

Re: Interview with Ryan Dahl, Creator of Node.js

#197
post #23

A serious problem with Node was the callback pyramid of doom. This means deeply nested callbacks such that the indentation wanders steeply to the right. When you do loops or have exceptions programming got very confusing. In effect you have to do a continuation passing transform. It's not difficult but the results are utterly unreadable. For example a simple for loop could be transformed into recursive function becau…

Finally :) I've been arguing for fibers, coroutines and generators with non-blocking IO as an alternative to bending everything backwards to fit in event loops for a long time. And begging for salvation from ever dumber and clumsier programming languages and more ignorant hipster programmers. I ended up writing my own language to investigate further since no one else seemed to be interested in stepping far enough out of the box.

https://github.com/andreas-gone-wild/snackis/blob/master/sna...

Re: Interview with Ryan Dahl, Creator of Node.js

#199
post #85
post #23

A serious problem with Node was the callback pyramid of doom. This means deeply nested callbacks such that the indentation wanders steeply to the right. When you do loops or have exceptions programming got very confusing. In effect you have to do a continuation passing transform. It's not difficult but the results are utterly unreadable. For example a simple for loop could be transformed into recursive function becau…

When your code wanders steeply to the right, then it is time to create named functions, variables or otherwise flatten it. Just like when the code nests too much for any other reason. But I agree that js attracted "Real programmers don't use Pascal" kind of programmers at first. Pascal style programmers perceived js as pure hell and treated it as abomination. Through, I am not sure whether they were swayed or rather…

But that's the thing. With callbacks, code that is logically the same (except that it's async) that wasn't nesting too much before, was suddenly nesting too much after.

And conversely, you can reduce nesting to, basically, zero in any imperative language, if you replace all your conditionals and loops with a bunch of labels and gotos.

Which is to say, how much code nests is very much a language design issue. Good PL design should not cause unnecessary nesting where it's not warranted by the structure of the solution.

Re: Interview with Ryan Dahl, Creator of Node.js

#200
post #119
post #99

Earlier quoted context omitted.

Why post a contrived meme as an example? Especially one with a sane solution[1] just below. [1]: https://pbs.twimg.com/media/B4W2AmaCAAA-heo.png

It's an exaggeration, yes, but it does correctly summarize how I felt when I had to work with node.js code bases before stuff like promises became mainstream.

An exaggeration could be written for any language. A decent programmer would not write code like the one you showcased as an example for callback hell.

This https://docs.spring.io/spring/docs/2.5.x/javadoc-api/org/spr... is not an exaggeration and I still would not use it to showcase how I felt when I had to work with Java developers.

Post reply on HN