Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interview with Ryan Dahl, Creator of Node.js

mappingthejourney.com

Post reply on HN
Print view View original

201–210 of 235 posts

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

#201

Post by int_19h »

nulagrithom wrote: post #130
thomasz wrote: post #107

Earlier quoted context omitted.

It's hardly the fault of the language if people are lying in their method signatures. I'm not aware of a mainstream PL with a type system that is powerful enough to avoid something like that.

In this case, the .NET-provided base class defaults to using the synchronous version when the async version hasn't been overridden. https://msdn.microsoft.com/en-us/library/system.data.common.... > Providers should implement this method to provide a non-default implementation for ExecuteReader overloads. > The default implementation invokes the synchronous ExecuteReader method and returns a completed task, blocking t…

This is a bug in the library. The correct way to do these "async but not really" wrappers is to call the synchronous implementation in a separate thread pool worker thread, and wrap that into a task (as Task.Run does). This is hardly optimal perf-wise, but it is truly asynchronous wrt to the caller. If I remember correctly, it's what Stream does for its default implementations of async methods.

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

#202

Post by int_19h »

cdelsolar wrote: post #73
nulagrithom wrote: post #68

Earlier quoted context omitted.

On that note, coming back from node.js has been a really frustrating experience for me. I want to scream every time somebody suggests threading as a solution to non-blocking database calls and HTTP requests. It's made me painfully aware of how often parallelism is suggested in place concurrency. C# in particular does a great job at conflating concurrency and parallelism. Both fall under the same Task namespace and it…

but why? Go's model is perfect. They're not real threads, it's basically very similar to Node, except that you can write code without a mess of callbacks and it's easier to reason about...

Go's model breaks down as soon as you have to invoke into non-Go code, because the latter has no idea about goroutines.

This is a general problem with all "green thread" abstractions - they are not OS level, or if they are (as e.g. fibers are on Win32), nobody cares to use them.

Promises, on the other hand, can be mapped to a straightforward callback-oriented C API, thus allowing a fully async execution stack end-to-end across different languages. You can even go one step further and define a uniform API for all such callbacks, as WinRT did.

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

#203

Post by int_19h »

icedchai wrote: post #167
jdc0589 wrote: post #104

Earlier quoted context omitted.

> Since server-side JS didn't exist yet, I'm being petty, but serverside JS did exist before node (e.g. Narwhal, which I believe is where jsgi and a lot of the commonjs stuff originated)

Server side JS is older than that. It existed over 20 years ago. Does anyone remember Netscape Livewire? It was basically "ASP-style" server-side javascript that ran on Netscape's "Enterprise" web server. It was a little unstable, but pretty advanced for the time (had DB connectivity, etc.)

While we're at it, ASP itself had JavaScript (well, JScript, technically) support alongside VBScript, out of the box. It wasn't particularly popular, probably because anyone doing ASP was likely to be using the rest of MS stack - and that meant VB for desktop LOB apps, usually.

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

#204

Post by int_19h »

corford wrote: post #82
bit_logic wrote: post #49

Many are forgetting the initial reason node.js became popular. Consider the popular server-side landscape before node.js. It was dominated by Java, Python, etc. The primary way these ecosystems handle concurrency is OS-level threading. There was nothing else in the popular languages. Each language had some niche library that did non-blocking I/O (Twisted for Python, Netty for Java), but these all had a critical flaw,…

>because the threaded code blocks. Python and Java threads don't block on I/O, only on CPU. Event loops (i.e. node) also block on CPU. AFAIK, node's advantage over threads was just that it offered much higher concurrency for I/O constrained tasks for the same memory (and was easier to programme for people coming from the front-end world).

Python and Java threads block the thread on I/O. Which is wasteful, because you have a huge chunk of memory allocated for the stack of that thread, being reserved but not actually in use.

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

#205

Post by int_19h »

pcwalton wrote: post #190
jabl wrote: post #187

Earlier quoted context omitted.

AFAIU a lot of the complexity and slowness of "traditional" M:N threading approaches were due to the requirement to follow POSIX semantics (signal handling, preemptivity, etc.) within a purely library/OS based approach (no changes in the code generated by the compiler). If you're doing a green threads implementation for a high level language runtime, those restrictions don't apply, to an extent. I think e.g. Erlang,…

Go still has a lot of issues around the inability to preempt except at function call boundaries, which is an issue that doesn't exist in 1:1 threading. Fairness and priority inversion are likewise issues with M:N that apply equally well to Go's implementation. Signal handling is too, although any GC language pretty much has to sacrifice POSIX signal handling already... Green threads done right strikes me as something…

Win32 has been offering fibers for ages, but no-one picked them up. Even .NET started designing around them (there are some vestigial remains of that in CLR hosting APIs), but abandoned that effort before it ever shipped.

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

#206

Post by int_19h »

jerf wrote: post #69
camus2 wrote: post #33

Earlier quoted context omitted.

> Using ideas from history isn't a problem. And Go is unique in that it combined all these learned lessons into something new. what learned lessons, like pragmas and struct tags?

A lot of is more in what was taken away rather than what was added. As someone who is occasionally accused of being too pro-Go on HN... I actually have no problems thinking of Go as a really nice and refined 1990s language. Another type of "Java done right". (I say "another" because I think C# has a really good claim to that as well, albeit in a very different direction.) There's a place for that in the world. As muc…

"A really nice and refined 1990s language" really is a perfect description of Go (and also explains why some people love it with a passion, while others can't understand what all the fuss is about).

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

#207

Post by georgecalm »

I was always curious why Ryan Dahl left the community. He finally answered that question; not the way I thought he would though:

"I think Node is not the best system to build a massive server web. I would definitely use Go for that. And honestly, that's basically the reason why I left Node."

Go may be an excellent choice for massive non-web servers, I don't have enough experience in it to say. For the product I work on, though, Node.js is the way to go. It's the best framework that allows us to use the same exact code on the server and on the client to create a fast progressive site.

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

#208

Post by bartread »

k__ wrote: post #58
nas wrote: post #47

Earlier quoted context omitted.

This was easily foreseeable when he started on Node.js. The Twisted framework for Python had existed for years (decades?) before Node.js was created. Anyone familiar with programming in that style knew of the issues with "callback hell". I was the primary instigator of generators for Python. Part of my motivation was to do something like CSP (e.g. call-with-current-continuation, call/cc) without having to redo the wh…

Somehow I never experienced callback hell. It always felt like every other code-nesting problem to me. I mean, nobody talks about conditional hell, everyone acknowledges that you should flatten out your conditionals.

I'm inclined to agree. To me callback hell is a symptom of lazy, or perhaps just ignorant, programming. It was never a necessity: if things are getting out of control, create a named function and pass in the name as the callback to make things more readable.

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

#209

Post by endorphone »

noblethrasher wrote: post #177
endorphone wrote: post #176

Earlier quoted context omitted.

I said entirely typical , not that it was a dick-sized "challenge". A completely standard developer on .NET or PHP in 2008 was building pages that rendered at less than 10 requests per second. This is experience, not a guess, given that my role was improving the performance of those disasters. A completely average developer on node was building pages that was 10x to 100x better performance. Secondly, simply spawning…

Not the OP, but I knew what you meant I soon as I read it. But, did the typical .NET app really not make use of the Asynchronous Programming Model that was part of the standard library? I ask because in 2008 I was only about 3 years into professional web development, and even I knew about stuff like the C10K problem[1] and that I/O Completion ports were apparently one of the few things that Unix people admired about…

Their use was incredibly rare. It was common to find advice columns telling you that you don't need them.

https://blogs.msdn.microsoft.com/rickandy/2009/11/14/should-...

Post reply on HN