alexcrichton commented on issue #26:
Thanks for taking the time to write this up, but as I read over it at least personally the main impression that I get is that this is a lot of work and process for not a lot of gain. These sorts of things seem good to write down eventually in the future but for now it feels to me like we have much bigger issues in wit-bindgen around issues like:
- The component model is still a moving target that wit-bindgen hasn't caught up to. There's significant divergence in the current implementation of async/futures/etc between the predicted path of the component model and wit-bindgen as-is today.
- In wit-bindgen features like resource types don't even exist in the component model yet.
- Support for streams in wit-bindgen doesn't exist beyond parsing, and it's unclear how this will play out in each language.
- The interface of wit-bindgen itself ("what exactly do you write down") in terms of what are the inputs and what are the outputs is itself still in flux.
Overall this seems like the wrong time to add process to a situation that mainly needs foundational work to make progress. Unfortunately this work isn't just exclusive to wit-bindgen as there's a lot of coordination that also needs to happen with the component-model proposal, various consumers, etc.
Reflecting on this now I'm personally thinking that it would be better to flesh out wit-bindgen itself and its implementation before going much further down the path for a release process and versioning and such. For example with Wasmtime first the API had an RFC and afterwards there was a Wasmtime 1.0 RFC. This sort of feels like the inverse order of operations is happening for wit-bindgen and I think that's at least one reason this feels premature aftering seeing it laid out.
Last updated: Nov 22 2024 at 16:03 UTC