This is one of the approaches for FFI taken by other runtimes, however it has the issue that without binding generators (jextract, P/Invoke code generators, ctypesgen), the type declarations are a pain to write.

Thus something like this would need a similar tool.

deno_bindgen exists which can be used to do this from Rust.

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

I see, thanks for the heads up.

it is refreshing to witness deno surpasses bun in a benchmark!

Honestly I feel like they should work first on API compatibility with NodeJS just so that it can be easier to adopt/migrate seamlessly, then try more improvements in the runtime. It's nice that they have performance optimizations but what are they good for when I can't use Deno because it's not compatible/missing APIs?

This feature and these APIs have been in Demo for a few years at this point.

This is only one strategy to get adoption. The other is to have better apis/more features so that new projects gradually move to your runtime.

In this hypothetical, eventually being on node would become like still being on java 8 is today.

Except node, like Java, moves along, making those that made a bet being a better Java 8, seem irrelevant with time, unless they happened to have a platform holder sponsoring their existence.

Deno needs a bit more than that for adoption.

As a heavy Node user, I think it was a mistake for Deno to try to bake in a compatibility layer with Node. It's a moving target, and will detract from other valuable work.

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.

We built something similar for pypy! See the blog post: https://bernsteinbear.com/blog/typed-c-extensions/ and paper: https://arxiv.org/abs/2403.02420

TL;DR: similar speedups! It works well

There have been a lot of security bugs in Chrome related to this layer of V8, most of them caused by some form of type confusion. Is there worry about increasing the size of Deno's attack surface by adding this capability?

JIT is a large attack surface, but it's mostly an attack surface from the perspective of migrating from "untrusted" javascript execution, to arbitrary native code execution (e.g. malicious js on a webpage, breaking out).

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.

This only seems to speedup value functions (not struct/callback or other C functions.)

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