4 ms·
If you're counting on people to drop down into a single-threaded runtime when using async constructs, you've really lost the mark. Parallelism is the user's goa
by foooorsyth 3y ago
If you're counting on people to drop down into a single-threaded runtime when using async constructs, you've really lost the mark. Parallelism is the user's goal most of the time, right? Perhaps in web context to avoid runaway thread spawning and slow loris attacks it's not (the main selling point of node.js), but otherwise people want to go fast.
>Also, seriously, more people should consider Kotlin.
I like Kotlin, but I find its coroutine machinations to be far more confusing that just plain threads (over which Java already had/has some nice quality of life abstractions). And debugging broken Kotlin coroutine code is hell. You will not get a normal-looking stack trace when things go wrong.
- proto_lambda 3y agoThe main goal of using async for me is to not have to handle all the IO wait state machines myself. It does a pretty good job of that, and as long as my program consists of a bunch of tasks concurrently waiting for IO to finish, a single thread is perfectly fine.
- biorach 3y ago> Parallelism is the user's goal most of the time, right? I'm not sure you're right about that.
- foooorsyth 3y agoIn the general sense? Probably not. In the context of Rust users? It certainly begs the question: why use Rust if you aren't going for speed? Just write it in Node/Go/JVM-lang if performance doesn't matter and you just want an event loop that looks like threads.
- felipellrocha 3y agoTake the browser. It gets an incredible amount of performance out people’s devices even though 99% of javascript is bound to a single thread. The way they accomplish that is via their asynchronous architecture. So, not always.