Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comparing Rust and JavaScript

chaotic.netlify.app

Post reply on HN
Print view View original

71–80 of 97 posts

Re: Comparing Rust and JavaScript

#71

Post by gwbas1c »

azangru wrote: post #39
gwbas1c wrote: post #28

I wish there was an "about" blurb. Perhaps 2-6 paragraphs explaining what's going on? Although it's obvious that you're comparing JavaScript and WASM performance, the devil is in the details. What exactly are you comparing? There's quite a bit of overhead in calling out from WASM to the DOM; how are you making WASM faster? How much "JavaScript" is involved in the WASM version? Are you manipulating a Canvas? Generatin…

> There's quite a bit of overhead in calling out from WASM to the DOM; how are you making WASM faster? If you check out the code, you will notice that wasm isn't talking to the DOM. Its purpose is to generate the image data as a Uint8Array, which is then passed to the canvas [0], same way the javascript implementation does it [0] - https://github.com/dmaynard/chaos-screen-saver/blob/93187f84...

> If you check out the code

That's why you need an "about" blurb.

Re: Comparing Rust and JavaScript

#72

Post by throwaway894345 »

kaba0 wrote: post #62
atwood22 wrote: post #22

Earlier quoted context omitted.

Go is a GC language, but it doesn’t need a VM. It’s a native, statically linked binary that contains the Go runtime.

And that distinction is completely meaningless. It still has to replicate the runtime, the same way as any other managed language.

Since we're being pedantic, all mainstream languages (even Rust) have a runtime, so your "managed vs unmanaged" language distinction is completely meaningless. :)

If there is a salient distinction, it's whether the runtime is easily and practically distributed as part of the compiled artifact, which is true for C, Rust, Go, etc but not so much for Python or JS (nor probably Java or C#, although there are efforts for static, native compilation for those platforms which probably come with significant caveats).

Re: Comparing Rust and JavaScript

#73

Post by throwaway894345 »

conradev wrote: post #58
atwood22 wrote: post #22

Earlier quoted context omitted.

Go is a GC language, but it doesn’t need a VM. It’s a native, statically linked binary that contains the Go runtime.

and because that statically linked runtime does a lot of things, it contains a lot of code and adds a megabyte or two to the final WASM product: https://dev.bitolog.com/minimizing-go-webassembly-binary-siz... Larger runtimes not only add bloat to the final WebAssembly, but they also can make interoperating harder because they often require more (i.e. any) bookkeeping when sending stuff back and forth. also worth ment…

> also worth mentioning is that this is why people build projects like TinyGo and MicroPython – they love the language, but can't work with the trade-offs that the designers chose

It's not like small runtimes are fundamentally better in this regard. They work better for constrained environments, but they often make tradeoffs which are inappropriate for other use cases. It's hard to make a runtime that works for everything, and it's not necessarily even a worthwhile goal--you can use TinyGo when you're working in a constrained environment, use Go when you're not.

Re: Comparing Rust and JavaScript

#74

Post by drawfloat »

hajile wrote: post #40
tjelen wrote: post #16

The innermost rendering loop in the JS seems to create and destruct an array instance for every single pixel iteration (see https://github.com/dmaynard/chaos-screen-saver/blob/master/s... ). I guess that this could be potentially optimized away by the JIT, but it will make things slower or at least less predictable.

Last I checked, destructuring created 4-5x as many bytecode instructions and a potential GC pause. I'd think this could be detected and optimized easily enough, but I guess there are bigger problems for the JIT devs to solve. A quick profiling seemed to indicate that just a bit less than 10% of the JS time is being spent on the DOM rather than the calculations at hand. I wonder how much of that could be reclaimed sim…

I actually thought Math.max was faster in modern Chrome than a ternary.

Re: Comparing Rust and JavaScript

#75

Post by davidatbu »

user249 wrote: post #66

Rust is a great solution to the memory safety problem, but is more difficult to use and slower to compile than some other languages. I'm wondering why I would use Rust for WebAssembly, which doesn't have memory safety issues?

My impression here is that (1) you don't want a language that you'd have to ship a runtime with (any interpreted language, Go, Swift), (2) Rust WASM tooling/documentation is (much?) better than tooling for other languages, and (3) most people would prefer memory safety when it comes to a purely memory-safety-to-compile-time trade-off.

Re: Comparing Rust and JavaScript

#76

Post by davidatbu »

bearjaws wrote: post #54

Ah yes, all the 3d websites and 3d information I use regularly. IMO we need to start building UI frameworks that are powered by WASM, and then benchmark those as compared to JS equivalent.

The JS Framework Benchmark[0] has got your back. The link below pre-filters to my subjective "picks" that I think give a birds-eye view of the wasm-to-js comparison for DOM manipulation:

My picks: SolidJS > Vue > Sycamore-rs > Svelte > React > Yew

SolidJS is a truly reactive JS framework. Sycamore-rs can be thought of as the Rust-clone of SolidJS, and Yew can be thought of as the Rust-clone of React.

">" means "is faster than".

[0] https://krausest.github.io/js-framework-benchmark/current.ht...

Re: Comparing Rust and JavaScript

#77

Post by davidatbu »

The JS Framework Benchmark compares benchmarks (both WASM and JS) in the more usual setting of DOM manipulations.

The link below pre-filters to my subjective "picks" that I think give a birds-eye view of the wasm-to-js comparison for DOM manipulation:

My picks, ranked descending by performance: SolidJS > Vue > Sycamore-rs > Svelte > React > Yew

SolidJS is a truly reactive JS framework. Sycamore-rs can be taught of as the Rust-clone of SolidJS, and Yew can be taught of as the Rust-clone of React.

[0] https://krausest.github.io/js-framework-benchmark/current.ht...

Re: Comparing Rust and JavaScript

#78

Post by jpgvm »

bearjaws wrote: post #54

Ah yes, all the 3d websites and 3d information I use regularly. IMO we need to start building UI frameworks that are powered by WASM, and then benchmark those as compared to JS equivalent.

Unless we get a DOM API for WASM it's probably not going to be worth it.

Which will basically relegate WASM to games, cryptography and parallel data processing (i.e SIMD).

Right now it's not looking like a DOM API will eventuate.

Re: Comparing Rust and JavaScript

#80

Post by marcosdumay »

teucris wrote: post #64
stared wrote: post #61

Earlier quoted context omitted.

From the user-experience perspective, it matters that it is Rust. Unless you directly write WASM code, which is rarely (ever) the case. Rust is a language that compiles to WASM. Sure, there are other options to compile to WASM, but they differ by interface (programming language, library, tooling) and (likely to a lesser degree) - performance.

Given the title I had expected this to be a comparison between the js and rust in terms of development, not performance. I learned nothing new about rust by visiting this page. All I learned was that compiled WASM is faster than js.

> All I learned was that compiled WASM is faster than js.

You learned that Rust compiled into WASM is faster than JS. That won't be the case for every language. (We had an example yesterday on the front-page where it wasn't. Ironically, its title implied that it was a generic comparison with WASM.)

Post reply on HN