4 ms·
> "relative absence of blocking IO calls." Do not confuse "language" with "standard library".
by catnaroek 13y ago
> "relative absence of blocking IO calls."
Do not confuse "language" with "standard library".
- dsego 13y agoWell, the browser implementation I guess. The point being the correct mindset.
- catnaroek 13y ago"Mindset" is not a property of programming languages. "Semantics" is. And JavaScript's semantics is, by any reasonable assessment, a huge pile of crap.
- DrJokepu 13y agoMeh, whatever. I can’t believe people still have flamewars about programming languages on the Internet like it was still 1996.
- catnaroek 13y agoI was not trying to ignite a flamewar. I was just correcting the mistaken idea that JavaScript's "relative absence of blocking IO calls" is somehow a property of the language itself. In any case, the real issue at stake is whether there is anything about Node.js that makes it particularly good for writing server-side applications. As far as I can tell, the only thing Node.js brings to the table is an event loop. Event loops are not a particularly earth-shattering concept: Anyone who has written a graphical Win32 application by directly using the WinAPI has written an event loop (message loop in Win32 parlance). I do appreciate not having to write the loop myself, but: 1. An event loop can only handle concurrent I/O. Furthermore, because the event loop is hardcoded into every single Node.js instance, there are two legitimate choices that are nevertheless unavailable to a Node.js programmer: a) disabling the loop, if he does not need it, b) spawning multiple event loops as separate threads within a single Node.js instance. 2. Node.js offers no support whatsoever for concurrent computation. I know, I know, all your Web application does is move data between a database and a client. But, if the only use case of Node.js is going to be making Web applications, would it not have been better to make a Web application framework, and provide it as a library? Languages that actually provide concurrency support (Erlang, Haskell and Rust, to name a few) make writing event loops as easy as it used to be in the 1990s. On top of that, they can be used to write server-side applications that scale.
- deleted 13y ago[deleted]
- dsego 13y agoNode was created to make scripting fast servers easy. Nothing more, nothing less. Because JS (as implemented in the browser and known by many programmers) didn't carry the baggage of blocking IO calls, Ryan thought it would be a good language for an event-loop based server. History of Node.js: http://www.youtube.com/watch?v=SAc0vQCC6UQ http://www.youtube.com/watch?v=SAc0vQCC6UQ
- deleted 13y ago[deleted]
- thedufer 13y agoThe whole event loop idea, which is core to javascript, allows for the single-threaded non-blocking I/O in a way that no other popular language does. Because of this, javascript has features that make this type of programming easy - first-class functions, anonymous functions, etc. So, yes. Non-blocking I/O is a standard library feature, but it works because of language features.
- jussij 13y ago> allows for the single-threaded non-blocking I/O in a way that no other popular language does. C# Async and Await - http://msdn.microsoft.com/en-us/library/vstudio/hh191443.aspx http://msdn.microsoft.com/en-us/library/vstudio/hh191443.asp...
- hackerboos 13y agoTwisted (Python) and EventMachine (Ruby) don't all of these do the same thing?
- dsego 13y agoI believe twisted was an inspiration for node.
- thedufer 13y agoYes. But they are tacked on to the language after the fact rather than built in from the beginning. My experience is that both language and libraries support that kind of pattern better in node than in Python (no Ruby experience with async).
- dsego 13y agowere those in the language before or after node came out?
- bitwalker 13y agoasync/await are just sugar over the much older asynchronous delegate pattern that has been in the language since day one. So yes, they were.