3 ms·
At this point, I'm pretty convinced that "async" in 10 years is going to be like "object oriented" is now. A gigantic dead end that we're barrelling down for t
by bsder 5y ago
At this point, I'm pretty convinced that "async" in 10 years is going to be like "object oriented" is now. A gigantic dead end that we're barrelling down for the wrong reasons--in this instance because everything web must be Javascript and work around all its warts.
Every time someone talks about async, they always forget that you need an Executor, and those executors always have problems because they don't have the boundedness of Javascript.
Using Javascript means your executors can only fire on a very constrained set of events that are completely prescribed. The moment you use something like Rust, that assumption is out the window and now your executor can't just do a couple of sockets and some DOM things. It has to accommodate sockets, timeouts, message queues that might wakeup by getting a message from another threads, character file descriptor devices, a terminal screen refresh, a video card vertical blanking event, etc.
In short, your Executor has to accommodate an infinite variety of events when using async outside of the bounds of Javascript. Effectively everybody has to write their own personal Executor the moment they do something other than an IP socket.
That's not an "improvement" in programming. That's a step backwards.
- eloff 5y agoI'm not certain you're wrong, but not for those reasons. There are still threads for all the long tail of synchronous operations. It's easy enough to do from Tokio or other async frameworks. However, the go approach of making async look like sync code is certainly much easier to write and read code for. I'm skeptical that async is really superior to that.
- asimpletune 5y agoFutures and channels I think are abstractions that solve different problems. Channels for instance are really good for producer/consumer problems. Futures on the other hand can be extremely elegant and flexible in ways that channels aren’t great at.
- eloff 5y agoThat is true, but not the point making. I'm talking about goroutines versus async/await. Both have an async runtime under the hood, but goroutines feel just like normal programming.
- dcow 5y agoThat's why I like the idea of scoped executors rather than trying to have a global executor do everything. Libs should provide their own executors and manage their own async event handling while allowing the user to provide their own implementation if needed (e.g. for single threaded test code where performance is not a problem or e.g. in a production environment where you can heavily optimize the executor if your requirements demand it). If you don't call any of the async overloaded functions in a lib, then you don't get any of the async code compiled in, including the runtime.
- pdpi 5y agoI don’t think any of this is about bringing the JS execution model to other languages. Rather, it’s about making it easier to build the next nginx.