Live data from Hacker News

Maybe you don't need Rust and WASM to speed up your JS

mrale.ph

131–140 of 186 posts

Re: Maybe you don't need Rust and WASM to speed up your JS

#131

I'm continually surprised by the Rust -> WASM pressure. I see projects like Redox and Servo and ripgrep and Tokio and, well, native or systems level things being it's true calling. I don't want to write a webapp in Rust. It'll always be second class (though maybe that won't be a problem if the WASM apis get good enough...).

Think of it this way: wasm is pretty similar in many ways to an embedded platform. Rust wants to be good at embedded, so making Rust good at wasm fits. A lot of the work is identical.

I think that is a very post-hoc rationalization to justify the silliness that is/has been eating the JS world (emscripten and asm.js show that this sort of thing has been going on for a while), but is an entirely valid reason to indulge it for free interest and experience.

+1

Re: Maybe you don't need Rust and WASM to speed up your JS

#132

Earlier quoted context omitted.

Yes, this is because the JS spec requires that object keys are iterated in insertion order (with a bizarre exception for arrays).

Ah, I guess that explains it. Although that does not require the engine to have under-the-hood layout respect that, does it? They could just as easily choose to keep the memory layout in the same order. Although I suppose you're already required to have two separate hidden classes to distinguish these two kinds of objects anyway. > with a bizarre exception for arrays Wow, you weren't joking with how bizarre this gets…

Prior to Chrome's release, browsers preserved insertion order for numeric keys as well (but this was not in the ES3 spec).

Chrome/V8's team found they could get substantial performance improvements by diverging from the de facto standard, without too much of a cost to web compatibility.

Re: Maybe you don't need Rust and WASM to speed up your JS

#133
post #90
post #85

The problem with this kind of deep dive optimization is the cost of maintaining it in a long-lived project as the underlying javascript engines keep changing. What was optimal for one version of V8 can actually be detrimental in another version, or in another browser. It's precisely the unpredictability of JIT-driven optimizations that makes WASM so appealing. You can do all your optimizing once at build time and get…

It seems to me there is no reason we shouldn't be able to create an "optimizing babel" that could be doing performance optimizations based on the target JS engine and version, as a build step. I don't think we need to go to a completely different source language and a compilation to WASM in order to get permission to create such an optimization tool. Such a tool would give you the benefits you're praising about the W…

JS engines already do insane levels of optimization, and they do it while watching the code execute so they understand the code better than any preprocessing tool can hope to.

What could a tool like you're describing do that the engines don't do themselves?

Re: Maybe you don't need Rust and WASM to speed up your JS

#134

Earlier quoted context omitted.

It is good at neither. Union types and sum types are veeery different from each other.

To be clear, I was talking about tagged unions; TypeScript supports both tagged and untagged unions[1]. My understanding is that "tagged unions" and "sum types" are the same thing, and Wikipedia[2] seems to agree. [1] https://www.typescriptlang.org/docs/handbook/advanced-types.... [2] https://en.wikipedia.org/wiki/Tagged_union

> My understanding is that "tagged unions" and "sum types" are the same thing

Well, your understanding is wrong. Sum types satisfy a specific universal property, which union types don't.

Re: Maybe you don't need Rust and WASM to speed up your JS

#135
post #83

Earlier quoted context omitted.

Having micro-optimized and maintained JS code over years and dozens of browser versions, I cannot echo this enough. Tuning JS both the in face of fickleness of VM quirks and data/context is a losing proposition for all but the most speed- and core-functionality-critical code. The point of rust+wasm benchmarks is that one can write reasonable, maintainable, functionality-focused code (not to mention all the rust-speci…

I'm afraid it's easier to get started as a Javascript developer than a Rust developer. What if it's easier to learn JS optimization quirks than to become an average Rust developer ?

[deleted]

Re: Maybe you don't need Rust and WASM to speed up your JS

#136

Earlier quoted context omitted.

Think of it this way: wasm is pretty similar in many ways to an embedded platform. Rust wants to be good at embedded, so making Rust good at wasm fits. A lot of the work is identical.

I think that is a very post-hoc rationalization to justify the silliness that is/has been eating the JS world (emscripten and asm.js show that this sort of thing has been going on for a while), but is an entirely valid reason to indulge it for free interest and experience. +1

I don't think it's a reason that wasm exists, but I do think it's one of the (multiple) reasons for us to invest in making Rust -> wasm an excellent experience.

Re: Maybe you don't need Rust and WASM to speed up your JS

#137

Earlier quoted context omitted.

TypeScript intentionally strikes a balance between strict soundness and developer productivity, and I've personally been pretty happy with that balance. There's more to language design than soundness, and I've been happy with TypeScript's willingness to get out of my way for little snippets of unsafe code, especially when interfacing with external libraries. Within my own code, I've never had the unsoundness actually…

Honestly I only use TypeScript for its lovely autocomplete. I'm pretty certain that JavaScript autocomplete could never be this good.

Hear, Hear. At the same time, Typescript's type system is getting so complicated, and the syntax so fugly because of it, that I'm tempted to go back to straight ES6.

Re: Maybe you don't need Rust and WASM to speed up your JS

#138
I rely heavily on a decent JS performance baseline for http://8bitworkshop.com/, and I also rely on asm.js / WASM. But I need different things from them.

For JS, I need consistency and stability, because I'm dynamically generating code. Usually I'm pretty satisfied, but sometimes after recompiling code I get a huge performance hit for no reason.

For WASM, I know I have stability, but I need faster load times. On my Chromebook, for example, it takes 10-20 seconds just to load the WebAssembly. If this problem is solved, I might move everything performance-sensitive over to WASM eventually.

Re: Maybe you don't need Rust and WASM to speed up your JS

#139
post #9

I wonder if the performance gain is worth the effort. Surely you can always squeeze more performance from JS like from any other language but what's the point if you spend hours to match the performance you get for "free" from other languages? As far as WASM is concerned I'm more excited about the possibility to run any programming language on the web than the raw performance gains. So far it is still year(s) away fr…

> hours to match the performance you get for "free" from other languages? In a sense, you pay those hours that you saved up by using an easier, more intuitive language like JS. Or you can choose not to and still have pretty good performance and blazing fast dev cycles.

Huh? I think the best part of WASM is getting away from JS and its associated tooling.

Re: Maybe you don't need Rust and WASM to speed up your JS

#140

Earlier quoted context omitted.

> hours to match the performance you get for "free" from other languages? In a sense, you pay those hours that you saved up by using an easier, more intuitive language like JS. Or you can choose not to and still have pretty good performance and blazing fast dev cycles.

Can you elaborate on how JS is more intuitive than, say, Rust? I can give a simple counter example - make a JS object, assign another object as a key, copy it three times into a list (without deepcopy) and modify the object inside. Suddenly you've modified all three objects. Not intuitive at all, and easily missed if you're a less experienced developer. Rust would stop you in your tracks and force you to explicitly s…

JS has more than its share of problems, but I wouldn't consider that to be one of them. It's the same reference semantics as Java and Python, and people are used to it.
Post reply on HN