6 ms·
On the other hand, since these methods are not compatible it will create certain split in the ecosystem.
by stshine 10y ago
On the other hand, since these methods are not compatible it will create certain split in the ecosystem.
- msbarnett 10y agoThose splits are inevitable. There is no One Size Fits All concurrency primitive. Embedded devs and web devs have vastly different requirements. Either the split is "every use-case finds the primitive that works best for it" (Rust), or the split is "here's the blessed primitive, other use-cases can pound sand" (Go)
- Manishearth 10y agoMust it? In fact, I'd expect the reverse -- choosing a model for the language will make the ecosystem tied to that model For example, while tokio is being integrated with hyper, it does not affect the "usual" users of hyper at all, both in terms of API and in terms of what's going on under the hood, cost-wise. Having a blessed solution for async like tokio that is not in the stdlib seems to encourage folks to integrate with it, but not in an irrevocable manner; the core library stays intact and able to support potential other models in the future.
- stshine 10y agoSure, I do hope we can focus on one concurrency primitive, but the possibility that we may have async/await and coroutine at the same time seems kind of unfortunate to me.
- Manishearth 10y agoAFAICT async/await the way Rust intends to have it (plans are rough right now) basically coroutines with extra sugar to specialize it with futures. The core language won't know about event loops, it will just know about futures, and you wire up your async/await or whatever to the event loop yourself. As both in the context of concurrency will involve futures they will probably work well together.
- stshine 10y agoI'd love to see this goes well with highest performance.
- Manishearth 10y agoAFAICT It's all going to be a generator-like abstraction which is pretty zero-cost.
- stshine 10y agoThe real world is always more complicated, since cps carries stack in its arguments.