> Async event-driven programming is not going away, it's probably always going to be the most performant model because incoming packets translate into interrupts and kernel mode and thread context switches are expensive.
That's like saying "assembly isn't going away, because it's the language of the CPU". Of course assembly isn't going away, but other than the Kernel and device drivers, there's not much reason to use it else where.
Coroutines are a much better way to write performant network services. In Go, when a goroutine blocks on I/O, it yields execution to other goroutines. You, the programmer, never think about it, because the platform handles it for you.
> Coroutines are a much better way to write performant network services. In Go, when a goroutine blocks on I/O, it yields execution to other goroutines. You, the programmer, never think about it, because the platform handles it for you.
Not only that but, unlike Node.js, Go (and Erlang) actually do scale to multiple CPUs and don't make your whole app crawl to a halt if you got some bit of code somewhere that is CPU bound.
This fantasy that Node.js supposedly scales because it is async is so laughable I don't understand how anyone ever took it seriously.
Of course assembly isn't going away, but other than the Kernel and device drivers, there's not much reason to use it else where.
Assembly largely has gone away. It used to be that all serious PC apps were written in asm. Eventually though, C compilers and RAM improved enough to not require that. Today the only things written in asm tend to the absolute lowest-level system routines and a few hand-tuned loops.
But you might also be interested to know that MS embeds the web server in the kernel using async IO (http.sys) and that the WinHTTP client library runs async as well.
Coroutines are a much better way to write performant network services.
I agree native coroutines or CPS would better. There are better choices of development language than Javascript, too.
But it's not the tool, it's the hand and the attitude that wields the tool that determines the quality of the result.
That's like saying "assembly isn't going away, because it's the language of the CPU". Of course assembly isn't going away, but other than the Kernel and device drivers, there's not much reason to use it else where.
Coroutines are a much better way to write performant network services. In Go, when a goroutine blocks on I/O, it yields execution to other goroutines. You, the programmer, never think about it, because the platform handles it for you.