3 ms·
As an application developer, I am curious about where this is leading/empowering. I hope to see something akin to the Project Loom approach in Java whereby sui
by ed_blackburn 3y ago
As an application developer, I am curious about where this is leading/empowering.
I hope to see something akin to the Project Loom approach in Java whereby suitable parallelisation abstractions are native, and one configures concrete implementations. Examples off the top of my head are:
1/ Light threads with default implementation of a scheduler provided by CPython and not dissimilar to Golang. Orthogonal to adjunct libraries or potential language features like channels.
2/ A no-op that uses the GIL can be default or even an interpreter switch, as discussed in the article.
3/ A stable ABI so one can replace the CPython implementation with an alternative. Written in Rust or whatever could be for hardware or a cloud vendor's environment.
4/Sub-interpreters, where parallelism pays to be far more coarse, could be Actor like architectures where spawned processes are new interpreters whose Actor System is a graph of interpreters.
These envisioned use cases offer significant advantages, and the potential benefits are exciting and encouraging. The prospect of this progress is exhilarating, and I eagerly anticipate this endeavour's evolution. Thanks to all those painstakingly putting so much energy into this.
Edit: spelling and formatting