Thus something like this would need a similar tool.
I have written a partial solution for C, though it is bespoke for my libclang bindings, and a very rough one for C++. Both of these require more work to really be ready-to-use tools however.
[1] libclang C binding generator: https://github.com/aapoalas/libclang_deno/blob/main/build/bu...
[2] C++ binding generator: https://github.com/aapoalas/txx
If a Deno user wants to use FFI to invoke system("rm -rf /*"), they can*, and they don't need to exploit a JIT bug to do so.
FFI with JIT is almost certainly a larger attack surface than FFI without JIT, but in practice I don't think it's a big difference.
*iiuc Deno is sandboxed by default, so presumably FFI capabilities (and the attack surface implications thereof) are something the developer needs to opt into from the start.
TL;DR: similar speedups! It works well
From the referenced file: https://source.chromium.org/chromium/chromium/src/+/main:v8/...
* Currently supported return types: * - void * - bool * - int32_t * - uint32_t * - float32_t * - float64_t * Currently supported argument types: * - pointer to an embedder type * - JavaScript array of primitive types * - bool * - int32_t * - uint32_t * - int64_t * - uint64_t * - float32_t * - float64_t
In this hypothetical, eventually being on node would become like still being on java 8 is today.
Deno needs a bit more than that for adoption.
Node compatibility is not something that will get me to switch to Deno. I will switch once I'm not restricted to the bundled TSC version, and there is a well supported bundler for client code.
