Consider using future-rs instead of libuv

[creationix]

Since the libuv part of the nucleus interface isn't set in stone, we could consider other backends that provide similar capabilities.

I found this today and it looks really promising. https://github.com/alexcrichton/futures-rs

[creationix]

See also: https://aturon.github.io/blog/2016/08/11/futures/

[Fishrock123]

Not sure about this, my implementations will almost certainly have libuv at least as a compatibility layer.

My goal is still to be able to run Node on top of nucleus in some way or form, and it won't stop being that.

See the goals of the JS low-level API from the API WG: https://github.com/nodejs/api#js-api -- very similar to here. I'd prefer not to have to fork the project for this.

[creationix]

Trust me, I hate compatibility layers more than anyone I know. I don't want to force you to add a layer on top of rust I/O or fork this project to be able to use it with node.

The first step with this can be some sort of analysis to see just how different libuv and this API would be. Can a common API that fits both be done without having to create compatibility shims in either direction. (I don't want a libuv flavored shim on top of native rust code either).

Ideally, the nucleus API is neutral and doesn't lock us into any backend. The question is: how realistic is this? Libuv is already a compromise API since it was made to abstract over windows completion ports and unix poll based interfaces. So I'm fairly confident we can figure something out. This is why I bring this up now before there is a huge body of JS code written for the libuv interface.

[Fishrock123]

Unsure, I think creating a generic JS FS api is far out of scope though.

[creationix]

What do you mean by "generic JS FS api"? Is there even a significant difference between future-js's API and what libuv exposes? Exposing the libuv fs interface (or something equivalent) is certainly in scope.

[Fishrock123]

Is there even a significant difference between future-js's API and what libuv exposes

Unknown. WHat I mean is something generic enough to support almost all possible fs backends if there are differences

[creationix]

I'd be plenty happy coming up with an interface that worked for libuv and future-rs. Simply having two backends to abstract over would make the code generic enough that other backends shouldn't have too much trouble. I don't see a need to try to guess what will be needed in the future.

Though looking more at their interface I'm not sure this will be possible. Libuv is callback based and future-rs is future based using reactive functional style code.

[creationix]

Another option is to have a libuv interface and another future-rs interface and write the abstraction on top in JS. I'm not sure how much I want to put that burden on the JS layer or fragment it.

I just don't see much value in using rust for the glue code, but still using libuv and duktape for the real work. The final binary is larger and slower and you still have unsafe C code doing most the dangerous stuff. I may be underestimating the value of rust glue code though.

[Fishrock123]

I may be underestimating the value of rust glue code though.

Personally, I can't reasonably write C at all, but I'm mostly fine leaving it to those who can.