Future in V

[dumblob]

I've just accidentally found this lib and I'm quite impressed. It seems to implement a sweet spot between CSP, real os-level threads, work stealing (Weave beats by a significant margin in all tests even hand optimized Intel libraries; see also nim-lang/RFCs#160 ), channel API, etc. quite similarly to what I envisined in vlang/v#1868 .

I would have one question:

1. Would you be willing to integrate (or help with integration) libcsp (or its parts) into V?

V is a new alpha-state language striving for efficient parallelism & concurrency support. V can be viewed as transpiler to C and thus provides a way to do the "static analysis libcsp is doing during multistaged compilation" in a more straightforward way.

Currently V maps all it's "go routines" 1:1 to os-level threads, but a more efficient implementation (utilizing CSP per os-thread but with preemptive guarantee, work stealing with Leapfrogging, dynamic adjustment of number of os-level threads due to power management on mobile devices, etc.) is needed.

From my point of view the biggest investment in libcsp would be to support also Windows, MacOS, Android, etc. along with ARM, POWER, and other than x86 architectures (ideally should be platform-agnostic with specialized variants for certain architectures - mainly x86 which libcsp already does 😉).

Maybe @UweKrueger could also comment as he's more up to date than me.

[JalonSolov]

Please don't characterize V as a "transpiler to C". Yes, that is the current default. However, it is one of only 3 types of backend now (with more being considered), and direct x64 output will become the default once it matures.

Whatever is implemented in V needs to work across all the backends as far as possible.