Why is so much of Deno written in JS/TS?

[ghost]

All of the code that runs on startup and all of the code the code that interfaces with V8 is compiled from Rust, but all of code that interacts with JS is... JS. I'm talking about code such as the V8 startup snapshot, and all of the builtins not provided by V8.

Can't they be written in Rust too? Most, if not all of Chromium's builtins are written directly in C++ (iirc there is a small bit of Rust too).

Writing the builtin code in Rust would provide much more predictable performance, memory usage, would be much safer, and would avoid "stupid" bugs, such as JavaScript prototype manipulation, as Rust/C++ would be able to directly interface with V8 to get information about objects passed in from the JS context.

Also doesn't JSON serialization-deserialization alone on every call to send/recv add unnecessary overhead?

Was there any explicit reasoning for the current decision to have used as much JS as is currently being used?

[kitsonk]

Can't they be written in Rust too?

Writing in Rust and injecting into the isolate is obtuse, especially for complex APIs. It is easier and faster to write these in JavaScript. Quite a lot of Node.js's runtime is written in JavaScript.

Also doesn't JSON serialization-deserialization alone on every call to send/recv add unnecessary overhead?

Most of the web standard runtime constructs don't op out to Rust. They stay totally within the isolate. Those that do, do at the edge, the "hot path" where they have to bind with the local system.

Was there any explicit reasoning for the current decision to have used as much JS as is currently being used?

The core team generally has made a conscious decision when dealing with implementing an API, but we have always avoided injecting objects into the isolate where we can avoid it. Deno.core is one of the few places. We worked out the op model, with a zero copy buffer for performance reasons and then have kept track of benchmarks. Some of were recently talking about looking at potentially implementing a u16 zero copy string buffer to speed up the JSON serialization/deserialization.

An example of iteration over time is TextEncoder/TextDecoder, the original implementation was 100% JavaScript, because it was easier to build. But it was identified that for utf8, the hot path could be moved to Rust. Now we have the best of both worlds, we have all the runtime construct, with this very narrow bit of it implemented in Rust. If we had implemented all of it in Rust, there is just loads and loads of "crap" we would have to put in Rust to get the right behaviour in JavaScript.

[ghost]

Writing in Rust and injecting into the isolate is obtuse, especially for complex APIs. It is easier and faster to write these in JavaScript. Quite a lot of Node.js's runtime is written in JavaScript.

I had assumed that some constructs would be harder to write in JavaScript than Rust.
I was aware that Node.js was heavily built on JS too, but do you believe that was the correct decision? Should Deno follow Node.js' design?

Most of the web standard runtime constructs don't op out to Rust. They stay totally within the isolate. Those that do, do at the edge, the "hot path" where they have to bind with the local system.

Yet, many of the runtime constructs indirectly call JS that ends up opting out to Rust anyway, so it's just indirectly doing what direct calls could be doing.

If we had implemented all of it in Rust, there is just loads and loads of "crap" we would have to put in Rust to get the right behaviour in JavaScript.

Can you elaborate on this? How bad might it look?

Technicially, the current implementation doesn't have correct behavior either, due to what I had said earlier, stuff like "JavaScript prototype manipulation," can break a JS implementation of anything, where it wouldn't break the native code or even a WebAssembly equivalent.

For example, if I were to override anything in the %TypedArray%.prototype, then most of Deno's builtins would break.
The alternative would be to make heavy use of local caching, indirect calls, and heavy type assertions to avoid global corruption, prototype manipulation, etc. I.e. you have to write un-intuitive, ugly JS to actually get correct behavior, whereas native code interfacing with V8 would have correct behavior while probably being more maintainable.

[kitsonk]

I had assumed that some constructs would be harder to write in JavaScript than Rust.

A bad assumption in my opinion. Having done some of the big APIs in Deno, I can assure you it is a lot easier in JavaScript.

stuff like "JavaScript prototype manipulation," can break a JS implementation of anything,

It can, but if we were really worried about that we would grab references to those globals when the code innited. So there are ways to address this. @bnoordhuis has mentioned this in passing and we have discussed freezing intrinsics before, but why take that tool out of users hands plus cause web compliance issues. I am just not sure this is more of a worry. Streams does now do some of this, but the motivation was more out of compliance with the spec.

There is a reason Deno has a security model outside of the sandbox. Poisoning typed array wouldn't only break built in code, but pretty much every userland program. So having one bit of code "safe" while everything else is broken buys you once? We have a lot of tools outside the sandbox to ensure what gets in there is predictable and wanted with a backstop of a 0 trust permission system.