node.js came into existence because it turned out that it was particularly apt for server side programming, not because it was force fitted into it.
I still don't see what it offers against .NET, Java, C++, OCaml, Haskell stacks, and their concurrency options.
It turns out that most of the reasons a server needs threads is IO. With node, any IO is moved to a new thread, so you get most of the threading benefits, but are completely safe (provided libuv is safe).
Another consideration is JS being dynamic. It's very easy to create extremely flexible APIs and you can move very fast adding features without breaking things. While That SML or F# app will provide much better type guarantees (and somewhat better performance), those benefits simply don't pay off for a lot of projects.
There's also something to be said for functional vs OOP styles. You will never see a JS dev writing enterprise fizzbuzz. Even in very large projects, those layers of boilerplate abstraction simply won't exist. Part of that is being dynamic and part is being functional.
LWT is a thing.
As for being dynamic, my experience has shown that beyond prototyping, most dynamic languages don't scale with the teams.
You apparently never seen enterprise JavaScript, specially in projects with multiple consultancy companies being part of the mix.
Not quite (or somewhat): the IO is done asynchronously. You tell the kernel to notify you when any of a set of FDs are ready for reading/writing, and it resumes you when that is so.
I recommend reading epoll(1) or kqueue(1).
The event loop and non-blocking I/O are inherent in JavaScript. The language lends itself very well to scalable server-side programming.
One of the most significant reasons to use a language like Node for server-side async programming is that for any random library you choose to use there's a very high probability the library also supports async and won't block on you. For better or for worse, async is pervasive in the JavaScript ecosystem. Even languages that have good async frameworks, like Python, most libraries will block as it's the normal I/O mode for the language.
With the caveat of my argument assuming "Typescript is a superset of Javascript."
[0] https://github.com/denoland/deno
[1] https://github.com/denoland/deno/issues/464#issuecomment-411...
>That said, 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. It was the realization that: oh, actually, this is not the best server side system ever.
E: To clarify on this a little since I'm not posting from a phone. Which means he's still using Javascript-as-a-server (Deno), so he obviously still has some faith in using Javascript-as-a-server.
Go > Node, in his opinion, but that says nothing about Go > Javascript.
> My problems with Node are almost entirely around
> how it manages user code.
> In contrast to the focus on evented I/O early on,
> the module system was essentially an afterthought
> With this in mind, I have long thought about how it
> could be done better....
Except what part is that? Having to download 4 or 5 projects to build, compile, and run 'basic' pages is too much bloat; not to mention the dependency hell.
It more and more seems to me like node was made 'because we can' instead of providing something. This can be seen with all of the cruft required; a lot made as an after-thought.
Package manager, npm; which itself has proven that... it wasn't designed too well. The reliance of it creates the cruft. Add in the fact that a web server shouldn't be event driven. I (personally) haven't seen any other language do an event-driven web; and I'd say, for good reason (callback hell.)
Javascript itself is okay because it's a requirement today for web pages to the average joe. However, if the Javascript foundation is merging; it'll their motto to use it (Node.)
Likewise, dependency hell is an issue in lots of languages. The company I'm with has legacy dependency issues with their Java. They have pip dependency issues with Python. The front-end testers learned JS and left ruby simply because they couldn't get their tooling installed on another machine without a couple days work (turned out JS was easier to maintain and faster too). Yarn exists and solves the major issues NPM had (though they seem to be improving as well).
EventMachine or twisted are two event-based servers (ruby and python) with some level of popularity. The big issue with them is every library you reach for has blocking code everywhere, so actually making it work is painful. Promises eliminated callback hell years ago for most of us. Koa/generators eliminate most of the rest as well.
On the flip side, JS as a language is rapidly evolving and node is a serious consideration when adding new features. Node as an implementation is extremely fast and I doubt that there's another scripting language that comes anywhere close to its combination of performance, size, memory usage, startup time, etc.