Hacker News new | past | comments | ask | show | jobs | submit login

> It grew from a questionable technology to one used for critical infrastructure in many large enterprises. It performs incredibly well for high-volume IO operations with a much lower code complexity than languages that rely on multi-threading.

Well, that is not where one usually uses multi-threading (OS level threads), as the threads would possibly be bottle-necked by IO and there would be no use of having the overhead of multiple threads. IO does not become magically faster by using multiple threads.

Which languages "rely" on doing that? Many popular languages have green threads and many have asynchronous concepts. I would assume, that programming language designers are aware and do not prescribe using multiple threads for IO of multiple concurrent "execution units".

Note: Little typo in the TOC: "Cetralize error handling".




The complete failure of early Java iterations of green threads and fall back to 1:1 OS threads, along with terrible async ergonomics in Java, meant a lot of backend software was based on real OS thread e.g. per connection. The story was similar in C/C++ for different reasons - the details of select and its various extensions were some of the least portable parts of otherwise POSIX interfaces. And on the lower end e.g. Python also relied on OS threads unless you built your entire application around one of the early async reactors.

The real success story behind node is libuv. It's a shame it was married to such a mediocre language, but that language did have some of the least-bad async ergonomics at the time (nearly by accident - client-side JS had to yield to the browser frequently, and the language was mostly designed to run small code blocks instead of application lifecycles).


The author is saying “green threads” and “asynchronous concepts” are more complex than “everything is synchronous”.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: