3 ms·
This isn't true. If you had stackful coroutines or something equivalent, you would be able to do all the things this thing does and you wouldn't have to pepper
by anonymoushn 5y ago
This isn't true. If you had stackful coroutines or something equivalent, you would be able to do all the things this thing does and you wouldn't have to pepper your callers and callers' callers with "await" whenever you add an operation that may take some time to a function for the first time.
We had this in Python and still have it in Lua, C, Zig, and so on, but the world has mostly gone the other way.
- samatman 5y agoI happen to be working on an application which is largely written in Lua and uses the same event loop (libuv) as Node. I can confirm that with careful engineering, application code doesn't have to suffer from the color problem. Fundamentally the trick is to yield after creating a callback, and resume into that callback when the thread has more data to process. A `foo:bar():baz():bux()` chain can pause execution in any of those methods and the user doesn't have to know which (some knowledge of whether this will happen /at all/ is required, only because you need a coroutine since Lua can't yield the main thread). This isn't built-in, need to start with something like BEAM for that, but it's a nice sweet spot.
- poink 5y agoI think the issue they were getting at is code like this: function doSomething(doSomethingElse) { internalState.setUp(); doSomethingElse(); internalState.tearDown(); } Right now, you can safely assume this whole thing will execute to completion without anything else happening in the interim, so a lot of existing JS makes that assumption. If `doSomethingElse` can yield while other code executes the assumption becomes invalid.