You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Debugging the current Wing toolchain when developing changes or features in the compiler can cumbersome because there are many concerns that overlap between the Node.js-based CLI and the Rust-based compiler core. For example, a large responsibility of the Wing compiler is to parse files and emit error information about these files, but the standard libraries for Node.js and Rust provide fairly different sets of APIs which don't always map 1:1.
To use the Rust-based compiler in Node.js, we compile it to WebAssembly and embed the WASM file in our Node package. Besides this requiring a dedicated build process (currently handled by turbo), a large amount of custom wrapper code has to be maintained for mapping functions between Rust and Node.js, and serializing/deserializing the data being passed or returned.
As a concrete example, in this PR I had to spend several hours trying to root cause the reason why a recently introduced CLI command was hanging. In the end, the looping was happening within the WASI file system mapping layer. Though it's possible to have these kinds of looping or file system issues with any compiler that needs to explore file paths and build an internal graph of files, the fact that we have to solve these problems at multiple layers is a burden.
In sum, the separation across language layers both make it a lot harder to contribute to the Wing compiler, and makes it much harder to debug. I believe unifying these under a single language will make it simpler to debug and continuing to stick to Rust will avoid the need to rewrite as many parts of our stack, while ensuring we can continue to scale the language performantly into the future.
Proposed Solution
Rewrite the CLI in Rust, and ship a unified binary (for all major architectures) to users. Initially we will require users to provide their own Node.js installations on their system which our CLI will call through subprocesses, but in the future we may consider embedding and shipping Node within our own CLI.
Implementation Notes
An initial proof of concept for performing just the "compile" command has been prototyped in the wingcli-v2 folder. Further work is needed to bring over more capabilities, including:
Diagnostics
Testing
Doc generation
Language server
Wing Console integration
Component
CLI
Community Notes
Please vote by adding a 👍 reaction to the issue to help us prioritize.
If you are interested to work on this issue, please leave a comment.
If this issue is labeled needs-discussion, it means the spec has not been finalized yet. Please reach out on the #dev channel in the Wing Discord.
The text was updated successfully, but these errors were encountered:
Use Case
Debugging the current Wing toolchain when developing changes or features in the compiler can cumbersome because there are many concerns that overlap between the Node.js-based CLI and the Rust-based compiler core. For example, a large responsibility of the Wing compiler is to parse files and emit error information about these files, but the standard libraries for Node.js and Rust provide fairly different sets of APIs which don't always map 1:1.
To use the Rust-based compiler in Node.js, we compile it to WebAssembly and embed the WASM file in our Node package. Besides this requiring a dedicated build process (currently handled by
turbo
), a large amount of custom wrapper code has to be maintained for mapping functions between Rust and Node.js, and serializing/deserializing the data being passed or returned.As a concrete example, in this PR I had to spend several hours trying to root cause the reason why a recently introduced CLI command was hanging. In the end, the looping was happening within the WASI file system mapping layer. Though it's possible to have these kinds of looping or file system issues with any compiler that needs to explore file paths and build an internal graph of files, the fact that we have to solve these problems at multiple layers is a burden.
In sum, the separation across language layers both make it a lot harder to contribute to the Wing compiler, and makes it much harder to debug. I believe unifying these under a single language will make it simpler to debug and continuing to stick to Rust will avoid the need to rewrite as many parts of our stack, while ensuring we can continue to scale the language performantly into the future.
Proposed Solution
Rewrite the CLI in Rust, and ship a unified binary (for all major architectures) to users. Initially we will require users to provide their own
Node.js
installations on their system which our CLI will call through subprocesses, but in the future we may consider embedding and shipping Node within our own CLI.Implementation Notes
An initial proof of concept for performing just the "compile" command has been prototyped in the
wingcli-v2
folder. Further work is needed to bring over more capabilities, including:Component
CLI
Community Notes
The text was updated successfully, but these errors were encountered: