Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
krustlet
Discontinued Kubernetes Rust Kubelet [Moved to: https://github.com/krustlet/krustlet] (by deislabs)
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
On Micro-VM's specifically, shout out to Wyrcan[1], which similar-ish to Fly.io is taking a container image & booting into itv an advanced & secure bootloader for a container image.
[1] https://gitlab.com/wyrcan/wyrcan
> - A way way better tooling story.
I think this is a real paint point of WebAssembly but it's getting better. You can now compile C/C++ code to WASM using clang as it became a first class citizen in v8 (or later?). Of course, clang does not provide all the runtime goodies that emscripten does but if you limit yourself to use WASM for some part of your code that require performance then all you need to provide is a few Javascript glue code. For prototyping purposes I've bundle an npm package that bring clang to your frontend project without the need to install it through a package [0].
Chrome debugger now support WASM [1] but you still need to install an extension. I've started to work on a way to convert the DWARF symbols from the WASM binary into sourcemap on the fly [2][3] but it still rough around the edge and need some work but it can definitely be done. This would allow WASM debugging natively in any browser supporting sourcemaps.
You also have all the WASM binary tools that you would find for any other kind of executable format in WABT [4].
[0]: https://www.npmjs.com/package/@jdmichaud/wasm-toolkit
[1]: https://developer.chrome.com/blog/wasm-debugging-2020/
[2]: https://github.com/jdmichaud/dwarf-2-sourcemap
[3]: http://site.novidee.com/blog/blog-entry.html?article=2022082...
[4]: https://github.com/WebAssembly/wabt
> - A way way better tooling story.
I think this is a real paint point of WebAssembly but it's getting better. You can now compile C/C++ code to WASM using clang as it became a first class citizen in v8 (or later?). Of course, clang does not provide all the runtime goodies that emscripten does but if you limit yourself to use WASM for some part of your code that require performance then all you need to provide is a few Javascript glue code. For prototyping purposes I've bundle an npm package that bring clang to your frontend project without the need to install it through a package [0].
Chrome debugger now support WASM [1] but you still need to install an extension. I've started to work on a way to convert the DWARF symbols from the WASM binary into sourcemap on the fly [2][3] but it still rough around the edge and need some work but it can definitely be done. This would allow WASM debugging natively in any browser supporting sourcemaps.
You also have all the WASM binary tools that you would find for any other kind of executable format in WABT [4].
[0]: https://www.npmjs.com/package/@jdmichaud/wasm-toolkit
[1]: https://developer.chrome.com/blog/wasm-debugging-2020/
[2]: https://github.com/jdmichaud/dwarf-2-sourcemap
[3]: http://site.novidee.com/blog/blog-entry.html?article=2022082...
[4]: https://github.com/WebAssembly/wabt
Technically you can always write you own C compiler like this project https://github.com/ForNeVeR/Cesium. Obviosuly C++ is much more complicated journey and require real investment. But at this point this is not CoreCLR limitations mostly.
> Better interoperability
AFAIK, the examples you give all target a basic C ABI [0] or can be made to target the same ABI. In Rust, it means targeting wasm32-unknown-emscripten
The Rust team is also working on a "WASM ABI"[1] which would be useful in taking advantage of stuff like multi-value returns, and other compilers could just choose to target that. More likely, the C ABI on WASM will be updated to account for missing features, and that'll be the standard for interoperability in the WASM ecosystem.
[0]: https://github.com/WebAssembly/tool-conventions/blob/main/Ba...
[1]: https://github.com/rust-lang/lang-team/blob/master/design-me...
> Better interoperability
AFAIK, the examples you give all target a basic C ABI [0] or can be made to target the same ABI. In Rust, it means targeting wasm32-unknown-emscripten
The Rust team is also working on a "WASM ABI"[1] which would be useful in taking advantage of stuff like multi-value returns, and other compilers could just choose to target that. More likely, the C ABI on WASM will be updated to account for missing features, and that'll be the standard for interoperability in the WASM ecosystem.
[0]: https://github.com/WebAssembly/tool-conventions/blob/main/Ba...
[1]: https://github.com/rust-lang/lang-team/blob/master/design-me...