I keep seeing variations on this statement, and I have never figured it out. What, exactly, is it about JavaScript that makes it particularly appropriate for this paradigm?
The way I see it, the only abstraction JS provides that helps with this is first class functions, which are also present (and often richer and more robust) in many other languages.
Python has first class functions, but not anonymous functions, since lambdas aren't full functions.
And Python doesn't have closures, because you have to use "global" or "nonlocal" (in Python 3) to assign a a variable in an enclosing scope.
These features let you write concurrent state machines in JS without explicit state -- you basically use the stack as state.
Python was pretty early in terms of event loop programming for interpreted languages -- asyncore in the stdlib, and Twisted. But I agree that the node.js style is nicer than asyncore, Twisted, or Tornado. I prefer coroutines over state machines, but if you're going to write state machines, than doing it with anonymous closures is nicer than doing it "manually" with classes and so forth.
Tcl was even earlier, but Tcl is pretty foreign to most people, and was more of an embedded language than a scripting language. Pretty sure Tcl has full anonymous closures, but it is a bizarre language in some other ways.
I haven't seen the event loop style in Perl but I think you can do it. If someone has an example I'd like to see it. To me, Perl only barely qualified as a real programming language because you can't even name your function params? At least when I used it, which was over 10 years ago.
Python isn't an exception among languages that people in industry actually use.
For "production grade" server software, which is driving the newfound interest in concurrency, the following languages cover 99% of code written in the last 20 years: C/C++/Java/PHP/Perl/Python/Ruby and the Microsoft Stack (C#, VB).
None of them have anonymous closures. (C# might, but it's also newer, and it's not the the prevailing style of concurrency in any case.)
This is basically JavaScript's Scheme heritage showing through. Anonymous closures are old hat for people who went through a CS program teaching Lisp, but they're not by any means standard in industry.
One of the main reasons that none of the languages needed this feature is because the predominant paradigm for concurrency for the last 2 decades was threading, not state machines and callbacks.
Perl and PHP both have closures. In fact, Perl is closer to Scheme/Lisp than most languages (at least Perl doesn't screw up scoping like JavaScript, replace first-class functions with second-class-bastardizations like Ruby, or do whatever Python thinks it's doing with lambda... ugh)
#!/usr/bin/node
function main() {
var a = 1;
console.log(a);
// named closure
function foo() {
a = a + 1;
}
foo();
console.log(a);
// anonymous closure
(function() {
a = a + 1;
})();
console.log(a);
}
main();> There is no such thing as an "anonymous closure". There are only anonymous functions which may or may not create a closure.
Which is exactly what you did: calling an anonymous function which happens to create a closure over variable `a`.
And that's why Python supports `asyncio` (not to be confused with `asyncore` which is obsolete). So I prefer:
sock = yield from connect('localhost', 7942)
msg = yield from read_message(sock)
print(msg)
connect('localhost', 7942, function(sock) {
read_message(sock, function(msg)) {
console.log(msg);
});
});
`asyncio` is not only easier to use than the traditional "manual" state machines with classes, but also much faster than something like `Twisted`. In my crappy local benchmark[1], it easily beat `Twisted` in a considerable margin. That may be because of the flaws in my test code, but still their performance is on par. I see no points in relying on callback hell, at least in Python, except the lack of the libraries that support asyncio, which makes me a little bit sad.
Part of the reason for stagnation was because you really need new language features -- i.e. yield/send, yield from, etc. JavaScript already had the necessary language features for its concurrency model.
Don't despair the future is bright :)
The different syntax also prevents you from creating functions that can be reused by both sync and async code.
The big thing promises and other callback-based control flow libraries do is that they fix exception handling in async code (its a PITA to add error handlers in every callback when writing async code by hand). They also let you avoid some of the awkward "pyramid of doom" nesting but thats not really killer feature because you can also achieve that by using tons of named functions.
The required bits are in place... alternatively you can use co/koa which uses generators along with yeilding promises to act in a similar fashion.. it does work pretty well, and will only get better.
Lua was quite pleasant to work with in this context!
async read(connect, readMessage, print) {
const sock = await connect('localhost', 7942),
msg = await readMessage(sock);
print(msg);
}It's not that Javascript is especially suited to this model, but thanks to the browser, it was already the most used implementation of this model.
But it was the broad availability of mindshare of those developers who at least knew some JS that really kicked it over the top, given JS as a DSL for I/O bound applications.
Underscore, Flux, promises.js, Async, Angular, Node fibers, Step...
How much is all this abstraction costing us, both in terms of computation time and developer time (both writing and debugging)?
We're in something of a JS framework boom (or hell, if you wish) right now. These people are developing as if their shit libraries won't exist in 3 years. Hence, the total lack of documentation and ongoing maintenance from so many of them. I've already had to maintain code that used abandoned JS frameworks. I'm a little scared of what's around the corner here...
function handleRequest(req)
data = db.fetch("user")
return render("template.html", {user=data})
In db.fetch it uses the "yield" keyword that would tell Lua it is about to do an async operation it should wait till it finish before continue running Lua code, meanwhile run something else instead, making it non-blocking and you can run many of these Lua programs at once on a single thread, all of them concurrently.
function mapList(xs, f)
local ys = {}
for i=1,#xs do
ys[i] = f(xs[i])
end
return ys
end
mapList({10, 20, 30}, function(x)
return db.fetch(x)
end)
I have plans to write dbslayer like "access DB over REST" service as a companion to Luaw so that it can use any and all databases that have JDBC drivers available without having to write non-blocking driver specially for each new database. This kind of arrangement where DB connection pooling is abstracted out of application server itself has other advantages related to auto-scaling in cloud and red/black or "flip" code pushes at the cost of slightly more complex deployment.
All depends on how much spare time I actually get :(
app.use(function *(){
var db = yeild getDbConnection();
var data = db.query("procname", this.request.query.param);
this.body = JSON.stringify(data);
});
Just choose a decent abstraction for callbacks. I prefer promises, but async.js does a good job as well.
The `flatMap` function on a Future in scala might be built into the language, but it is implemented and scala and not significantly different (in my mind), to Bluebird being implemented in javascript.
Every time I use JavaScript I imagine how good life could have been were it Scheme. Every time I have to use JSON I imagine how great life would have been were we using canonical S-expressions[1] instead. There's one good thing—and only one good thing—about JavaScript: it's incredibly well-deployed. As another commenter mentioned, JavaScript is an object lesson in path dependency.
In many ways, it's appropriate that it has 'Java' in the name: it's popular, but it's ugly. There are better languages; indeed, nearly every other non-Turing-tarpit language is better than either Java or JavaScript: Lua, Lisp, TCL, Python, Rebol, Erlang.
V8.
And it's a pretty powerful language. C-like syntax (familiar), Lisp-like (powerful/flexible), it's everywhere and it's fast (thanks to V8). Really, if it weren't for Chrome, Node.js wouldn't be a thing, and JavaScript wouldn't be ruling the world.
It's still possible v8 somehow sparked those other JITs, if before it was public the developers of WebKit and Gecko learned of v8 and stepped up their game. But, I don't know if that's true or not.
Anyhow, it's an impressive achievement that people still mention v8 as the reason JavaScript is fast, when it isn't the fastest today, and wasn't the first to be fast historically. Although, it is certainly a worthy VM, just one among several.
To me, the node story seems to boil down to "V8 was a readily-available fast runtime and people who already knew JS flocked to it" — which is fair enough, but hardly an argument for how appropriate JS is, as a language, for this sort of programming model.
That's basically all there is to a language's success. We like to debate syntax and closures and continuations and type systems and immutability and concurrency models on programming language message boards, but realistically, nobody cares. The two questions they have when they encounter a new language are "Can I learn this in a weekend?" and "Can I build cool things that other people would actually want to use?"
If you look at the history of programming technologies that have "won", the list includes C++, Java, Javascript, PHP, C, Objective-C, and to some extent Perl, Python and Ruby. The first 4 of those are terrible from a language-design standpoint, but the two things they all had in common were a readily-available reasonably-fast runtime (except PHP, and that was "fast enough" for the things people use it for), and a familiar syntax. C, PHP, Javascript, and Objective-C also had the benefit of being the "native" language for a major application platform, which seems to be the other major critical success factor for a new language.
There is a possibility that this viewpoint doesn't leave any room for: the possibility that languages make nearly no difference. Perhaps people are savvy, and interested in more complex things, but the various languages and platforms don't bring any concrete value. Instead of being a function of how widely-ranging people's interests are, it's instead a question of whether anyone is actually making real tracks away from a center, a center whose nebulous nature is only permitting the forging of false distinctions in.
Rather than marking time by languages, perhaps it's more interesting to mark what we focused our language use on?
You can make smart, high level languages like Haskel or Ceylon, but people will generally prefer dumb, easy to learn languages like Basic, PHP or JavaScript, despites their limitations.
Result: instead of making a nice car, well designed and looking good, they put big wheels and powerful engine on soap box cars! :-)
And I'm not a big fan of that theory that JS is Lisp-like. The only thing thats particularly lispy about JS is the first class function and even then they are a bit fucked up because of the wonky function-local scoping rules and the "this" keyword.
It's showing that you've been burned by these magical creatures. It takes time and effort to get used to mastering these awkward concepts
Actually, if you don't know how ((this)) works in different context, you can't call yourself a good js developer.
In other languages, you could use libuv or tornado or aio or whatever, but it's like throwing away the entire ecosystem and using an obscure language anyway.
Devs with experience writing interactions with the DOM had already convinced themselves that callbacks nested ten deep was a totes OK way to write code, "releasing Zalgo" and all.
If you're trying to do non-blocking async stuff in other languages, you have to hope/check that none of your code and none of your dependencies try to do blocking I/O. (Unless you're using something that does async under the covers like haskell or go)