Hacker News Reader

Comment by hvidgaard | Hacker News Reader

It's not going to change that. No matter how efficient you make the JS engine, crappy JS will still steal all your ressouces.

View on HN

Yes. However, a crappy, leaky, JS engine running crappy JS code will steal all resources even quicker. I hope a JS engine built with Rust smart ptrs will be less leaky than one built in C/C++. In my experience, hand rolled memory pooling systems can be very leaky.

There's no plan to write a new JS engine at Mozilla, FWIW.

And they shouldn't...let's move forward... to WASM (Web Assembly)!

Which, also posted on front page of HN recently, a user's medium blog on compiling Rust to WASM. https://medium.com/@chicoxyzzy/compiling-rust-to-webassembly...

Except, like, JS isn't going to die any time soon, and realistically, implementing a new JS or WASM VM isn't actually that interesting to do: the big risk in a JITing VM that Rust cannot save you from is behaviour of your JITed code, which makes memory safety far harder to enforce.

Right, JS isn't going anywhere. But once WASM is able to run everywhere, anybody attempting to make high performance web apps would ideally want to write it in WASM. A lot of what JS does on the web is plenty fast and won't really benefit much from JS being multi-threaded/faster.

Sites using JS to run simple scripts or to fire api calls/etc. will continue to use JS, no reason to use WASM.

Also, I believe WASM is truly compiled code and not JIT ran? I may be wrong...but pretty sure that was the whole point of creating it. Native app performance in the browser... that will take a big bite out of the app stores that take a good cut of revenue and control what can and can not be in the store.

And sure, WASM can also have memory safety problems, especially with C/C++ being the primary languages to target WASM from. But that's also where Rust would shine, making it much more safe when compiled to WASM.

WASM isn't machine code: if it were, it wouldn't be universal which is a fundamental requirement of the web. (Well, okay, it's compiled code—it is, after all, compiled from C/C++/etc., but in the same way JS is compiled to byte code in VMs today.) As such, there's a further compilation step needed from WASM to machine code to get near-native performance out of it.

The existing WASM implementations do a mixture of JITing code at load-time and JITing code at first-call, depending on the size of the WASM blob, AFAIK. The gain performance wise over asm.js is primarily in parse-time, as far as I'm aware.

WASM VM itself is perfectly possible to be memory safe: WASM code cannot read outside of the memory allocated to it (and malloc/free are implemented on top of that memory allocated to the VM, hence there's memory safety at the VM level).

The big problems come when you need to guarantee your JIT code doesn't violate memory safety, and that's something Rust's type system cannot (currently) solve. You need guarantees that the generated code will never have any memory access errors, and will never race for memory reads/writes, because it's running with the privilege of the VM, not the limited powers of the WASM code running within it.

We have extensive leak checking in our testing for Firefox, so hopefully the JS engine is not "very leaky".

One part of Quantum, which does not have anything to do with Rust, is to figure out how we can spend less time running unimportant JS (like maybe in a background tab), which will hopefully reduce CPU usage.

I wonder if it would be possible to write a JS engine in Rust that would essentially make multi-threading JS possible... Use Rust's concurrency safety to pass resources around threads running JS. Doing this without making any changes to JS. Of course Node would then also be obsolete...

I consider the lack of parallelism[0] in JavaScript as a feature of JavaScript.

[0] Note: parallelism is not the same as concurrency.

JS does have proper parallelism, workers can run on separate threads and could be run on separate processors. There aren't as many primitives for dealing with cross-worker communication, but some exist and it's usable.

JavaScript does not have parallelism!

Browsers implement web workers and a "system call" which lets users initialize them through JS. A different implementation/deployment environment like Node does not have web workers. Through native modules, Node can have parallelism, but this is not a part of the language and Node isn't subject to implement web workers to be considered "running JavaScript". However, regardless of this JavaScript continues to have concurrency without parallelism. It would have been more accurate for my last message to have said: "I consider the lack of parallelism in JavaScript a feature given that it continues to have concurrency by default".

Similarly, I'd argue that C does not have parallelism (just system calls ...), but C doesn't even have concurrency. As such I do not consider the lack of parallelism a feature of C.

I guess. I was thinking from the POV of web browsers.

The challenges in parallelizing JS have very little to do with its implementation language and almost everything to do with JS itself. Rust can't help you there.

Js engines are really fast. The stuff they run is bad.

Yes, nowadays I think it is a fact of life like death, taxes etc.

I'm hoping it spurs a resurgence in real desktop apps, then we shouldn't have to worry about bloated javascript.

I think people forget the rather overwhelming amount of crappy bloated desktop apps we had (and still have). There isn't anything inheriently bad with JavaScript. Webapps have strong points, and weak points, and should be used where it makes sense.

But the developers developing bloated code are most visible in the last shiny thing, which happens to be web and JavaScript. Before that it was mobile apps.

Reply on news.ycombinator.com