3 ms·

I didn’t mention rust, I don’t know Rust and if I were trying to start a similar project I might do so in .NET Core because of my familiarity with .NET. I’m ask

I didn’t mention rust, I don’t know Rust and if I were trying to start a similar project I might do so in .NET Core because of my familiarity with .NET. I’m asking because I don’t know if there is a reason it would not be viable, is the garbage collection too much of a hurdle to get decent performance while trying to interpret JavaScript? Is there too much overhead tracking claims on memory and doing the bounds checks? I’d assume the same checks eventually have to be written in C++ too?

alexvitkov 2y ago
I apologize - when people mention "memory safe" nowadays 95% of the time they're talking about Rust, I made an assumption. Interpreting JavaScript at all it at all is a problem. Ladybird's LibJS compiles it to bytecode and interprets that (which is usually better than intereprting the AST). The bytecode interpreter is written in C++, and it's still pretty damn slow - websites take a long time to load, and LibJS is the main bottleneck. The reality is, modern websites throws so much junk at your JS implementation, that you basically need to JIT-compile it in order to have any sort of reasonable performance. And with JIT all memory safety guarantees are thrown out of the window - it doesn't matter if you write your compiler in Rust, C++ or a .NET language - if there's an exploit it's disproportionately more likely to be in the output assembly than it is to be in your compiler. Browsers nowadays make a best effort, and they have a stack of other mitigations in case the JIT leaks: https://chromium.googlesource.com/chromium/src/+/main/docs/design/sandbox.md https://chromium.googlesource.com/chromium/src/+/main/docs/d...
- voidwtf 2y ago
  This may be the biggest gap in my understanding. I didn’t realize that at some point the JavaScript is turned into instructions running directly on metal, I thought everything occurred within a synthetic/virtual environment.

alexvitkov 2y ago

I apologize - when people mention "memory safe" nowadays 95% of the time they're talking about Rust, I made an assumption. Interpreting JavaScript at all it at all is a problem. Ladybird's LibJS compiles it to bytecode and interprets that (which is usually better than intereprting the AST). The bytecode interpreter is written in C++, and it's still pretty damn slow - websites take a long time to load, and LibJS is the main bottleneck. The reality is, modern websites throws so much junk at your JS implementation, that you basically need to JIT-compile it in order to have any sort of reasonable performance. And with JIT all memory safety guarantees are thrown out of the window - it doesn't matter if you write your compiler in Rust, C++ or a .NET language - if there's an exploit it's disproportionately more likely to be in the output assembly than it is to be in your compiler. Browsers nowadays make a best effort, and they have a stack of other mitigations in case the JIT leaks: https://chromium.googlesource.com/chromium/src/+/main/docs/design/sandbox.md https://chromium.googlesource.com/chromium/src/+/main/docs/d...

voidwtf 2y ago
This may be the biggest gap in my understanding. I didn’t realize that at some point the JavaScript is turned into instructions running directly on metal, I thought everything occurred within a synthetic/virtual environment.