Our great sponsors
-
spin
Spin is the open source developer tool for building and running serverless applications powered by WebAssembly.
-
-
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.
-
-
SSVM
WasmEdge is a lightweight, high-performance, and extensible WebAssembly runtime for cloud native, edge, and decentralized applications. It powers serverless apps, embedded functions, microservices, smart contracts, and IoT devices.
-
-
cpp_weekly
The official C++ Weekly Repository. Code samples and notes of future / past episodes will land here at various times. PR's will be accepted in some cases.
-
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.
They’re VC-funded and will vendor lock-in you. See their response to my discussion:
https://github.com/fermyon/spin/discussions/861
With WasmEdge there is no vendor lock-in, it’s opaque and standards-based
WasmEdge contributor here. We had some last year.
Paper: A Lightweight Design for High-performance Serverless Computing, published on IEEE Software, Jan 2021. https://arxiv.org/abs/2010.07115
Article: Performance Analysis for Arm vs. x86 CPUs in the Cloud, published on infoQ.com, Jan 2021. https://www.infoq.com/articles/arm-vs-x86-cloud-performance/
Source code of test cases: https://github.com/second-state/wasm32-wasi-benchmark
See if these helps. (Kinda old so will be needing more updated ones)
Not to denigrate your work, it's good what you're working on... but I can create JS APIs in Rust with native V8 bindings, too: https://github.com/denoland/rusty_v8/blob/main/examples/proc...
Not OP but I was considering using it as well. I could see it going either way. If Fabrice stays interested in the project and keeps improving it, it could be a great win. If he moves on to other things, perhaps not.
I've been looking at quickjs issues and forks and see a lot of random fixes from various people and most of them don't seem to be accepted or responded to:
* https://github.com/bellard/quickjs/issues/131
This response is a mess, I apologize.
One can do lots of things. Yes all of those things are still issues, but in enumerating all the things as you have, you make a compelling argument not to use C++. If one picks something else like SML, Go or even Rust, it allows them to focus on those common areas of correctness and not also, all that other stuff.
I don't think you are apologizing for C++, but I hear this a lot, whatabout all the other parts that are fixed by a more sound system? My response is that we only have so many decisions we can make in the day, using a system that removes whole classes of problems allows me to focus on the non-accidental (forced) complexity.
> Rust as Wasmtime is, that alone wouldn't actually give me much more confidence that it's safe
I never made that argument. But let's say I did. Given two systems, one made in Rust and one made in C++. How do I audit the C++ code to ensure that it has the same level of safety as basically _anything_ else?
WasmEdge is using code coverage, good! https://app.codecov.io/gh/WasmEdge/WasmEdge
Only 80% coverage, not great.
I see mention of fuzzing being used, but I only get 69 hits in the codebase for "fuzz" and no documentation about how it actually works.
Wasmtime includes documentation on how to use their fuzzer, https://github.com/bytecodealliance/wasmtime/tree/main/fuzz
In my cursory look at the WasmEdge codebase I see
No application UBSan [1]
No application of control flow guard [2], either in the build or in the generated LLVM output.
Infact the only sanitization flags they are passing are -fsanitize=fuzzer,address
0 mentions of 'control flow' in the WasmEdge codebase, 65 mentions in Wasmtime. Although it doesn't appear that Wasmtime is itself being compiled with cfguard.
309 mention of spectre mitigations in Wasmtime, 1 link to a cloudflare blogpost in WasmEdge.
In my cursor look at Wasmtime, I see
Much better fuzzing support, 85 uses of unsafe in cranelift itself, 1400+ uses of unsafe in crates/*
The changelog and git messages for WasmEdge talk about type errors (those type errors look impossible in Rust), bus errors, out of bounds, etc.
It does not inspire confidence. C++ is already starting from behind. This software is targeted to be run on bare metal, embedded and widely distributed. It just doesn't have the level of detail around testing and correctness that I would expect for such a critical piece of infrastructure.
I am not saying that Wasmtime does not also have issues, that would be preposterous. But on the face of it, WasmEdge has a lot of work to do to catch up to where Wasmtime already is.
Wasmtime appears to care about the security properties of their dependencies with https://mozilla.github.io/cargo-vet/
It does not look like the WasmEdge project applies this basic list of practices as outlined by Jason Turner [n]
[1] https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
[2] https://www.zdnet.com/article/microsofts-control-flow-guard-... https://clang.llvm.org/docs/ControlFlowIntegrity.html
[n] https://www.youtube.com/watch?v=q7Gv4J3FyYE https://github.com/lefticus/cpp_weekly/issues/175
This response is a mess, I apologize.
One can do lots of things. Yes all of those things are still issues, but in enumerating all the things as you have, you make a compelling argument not to use C++. If one picks something else like SML, Go or even Rust, it allows them to focus on those common areas of correctness and not also, all that other stuff.
I don't think you are apologizing for C++, but I hear this a lot, whatabout all the other parts that are fixed by a more sound system? My response is that we only have so many decisions we can make in the day, using a system that removes whole classes of problems allows me to focus on the non-accidental (forced) complexity.
> Rust as Wasmtime is, that alone wouldn't actually give me much more confidence that it's safe
I never made that argument. But let's say I did. Given two systems, one made in Rust and one made in C++. How do I audit the C++ code to ensure that it has the same level of safety as basically _anything_ else?
WasmEdge is using code coverage, good! https://app.codecov.io/gh/WasmEdge/WasmEdge
Only 80% coverage, not great.
I see mention of fuzzing being used, but I only get 69 hits in the codebase for "fuzz" and no documentation about how it actually works.
Wasmtime includes documentation on how to use their fuzzer, https://github.com/bytecodealliance/wasmtime/tree/main/fuzz
In my cursory look at the WasmEdge codebase I see
No application UBSan [1]
No application of control flow guard [2], either in the build or in the generated LLVM output.
Infact the only sanitization flags they are passing are -fsanitize=fuzzer,address
0 mentions of 'control flow' in the WasmEdge codebase, 65 mentions in Wasmtime. Although it doesn't appear that Wasmtime is itself being compiled with cfguard.
309 mention of spectre mitigations in Wasmtime, 1 link to a cloudflare blogpost in WasmEdge.
In my cursor look at Wasmtime, I see
Much better fuzzing support, 85 uses of unsafe in cranelift itself, 1400+ uses of unsafe in crates/*
The changelog and git messages for WasmEdge talk about type errors (those type errors look impossible in Rust), bus errors, out of bounds, etc.
It does not inspire confidence. C++ is already starting from behind. This software is targeted to be run on bare metal, embedded and widely distributed. It just doesn't have the level of detail around testing and correctness that I would expect for such a critical piece of infrastructure.
I am not saying that Wasmtime does not also have issues, that would be preposterous. But on the face of it, WasmEdge has a lot of work to do to catch up to where Wasmtime already is.
Wasmtime appears to care about the security properties of their dependencies with https://mozilla.github.io/cargo-vet/
It does not look like the WasmEdge project applies this basic list of practices as outlined by Jason Turner [n]
[1] https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
[2] https://www.zdnet.com/article/microsofts-control-flow-guard-... https://clang.llvm.org/docs/ControlFlowIntegrity.html
[n] https://www.youtube.com/watch?v=q7Gv4J3FyYE https://github.com/lefticus/cpp_weekly/issues/175