3 ms·
To some degree its a style choice but most (all?) of the languages used for UI use some kind of the UI thread paradigm with a way to run code on and off of that
by jayd16 6y ago
To some degree its a style choice but most (all?) of the languages used for UI use some kind of the UI thread paradigm with a way to run code on and off of that thread. Not everything called a coroutine is designed for UI interaction. Kotlin's are better suited than Goroutines. As you admit your self, js and others have settled on this style and one has to assume its for a good reason.
Async/await solves the problem of posting execution to another thread, getting a result, and easily and efficiently waiting for that result on exactly the thread you need.
It'll be interesting when or if someone uses Loom in the UI space.
- thu2111 6y agoWith JS the reason isn't really all that good - it's because it's expensive and difficult to make JavaScript and browser engines thread safe (or any dynamic scripting language). If it's hard to make the language genuinely multi-threaded then you end up stuck with callbacks and a standard library that uses a totally broken design to try and be as single-threaded as possible. It's basically Windows 3.1 all over again, but in 2021 instead of 1991. Quite sad :( Async/await in the browser at least is unrelated to threading (unless you mean hypothetical helper threads inside the browser). You don't get any choice about where the handle the callback. It's always on the single rendering thread.