Live data from Hacker News

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

mrale.ph

21–30 of 186 posts

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

#21
post #3

I'm excited about compiling to WASM not for performance but for correctness. Typescript is better than nothing but it really can't compete with the safety and ease you get from a language with a really good type system.

One thing I've been confused with about transpiled languages is how does correctness transfer? How do types or lifetimes etc. transfer to WASM, for instance? Or does it just depend on the correctness to be verified in the pre-compilation/transpilation stages?

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

#22
post #17
post #3

I'm excited about compiling to WASM not for performance but for correctness. Typescript is better than nothing but it really can't compete with the safety and ease you get from a language with a really good type system.

What would you consider to be a "good type system"? I find typescript to have one of the most sane and still strict type systems of all languages that doesn't fall into the extreme functional spectrum or those that care about memory ownership.

Any language that doesn't have first-class support for ADTs is a waste of my time. And I say that as someone who's working with TypeScript all day long, and try to push it in my team, even though it sometimes requires verbose code and boilerplate. But I take that over plain JS any day. It took long enough for my coworkers to recognise the benefit of a type system. Can't push them too hard too far too quickly.

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

#23
post #15
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…

It seems to that WASM is more suitable for non-browser work like Node.

No offense meant, but that couldn't be more wrong. If you're writing for the server, you can already use whichever language best suits the problem at hand. WASM will eventually allow the same choice in the browser.

The extent to which WASM could be used in the Node ecosystem would essentially be an indictment of how badly the Node community has bungled FFI. (node-ffi[0] should absolutely be added to Node core, not be independently maintained and always trailing compatibility with newer node releases, right now you have to choose between security or compatibility)

[0]: https://github.com/node-ffi/node-ffi

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

#24
post #14
post #12

Earlier quoted context omitted.

I am looking into TypeScript right now and I think it's just a hard problem to integrate a typed language into a dynamic environment like JavaScript. The transitions between JavaScript and the typed language will always be tricky and error prone.

Typescript does a better job than most that I've seen.

PureScript doesn't do a bad job either. And even Haskell (GHCJS) has good FFI into JavaScript (I'd argue even better than PureScript!). How bad can you make interop between a higher-level language and JS? What are the bad examples?

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

#25
I think this is an interesting exploration because I really enjoyed the description of profiling and improving performance, but I came away feeling exactly the opposite of the title. I think it's really cool that JS optimization can provide so many wins, but this article makes it seem fairly fickle and if they're not familiar with VM internals I would not expect most developers to complete this journey. Using wasm+rust/c++ is interesting in part because you can get so much more predictable performance out of the box. When the performance comes from language features instead of VM-specific optimizations the performance might be easier to maintain across revisions and hopefully will be less subject to regression from VM changes.

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

#26
post #15

Earlier quoted context omitted.

It seems to that WASM is more suitable for non-browser work like Node.

No offense meant, but that couldn't be more wrong. If you're writing for the server, you can already use whichever language best suits the problem at hand. WASM will eventually allow the same choice in the browser. The extent to which WASM could be used in the Node ecosystem would essentially be an indictment of how badly the Node community has bungled FFI. (node-ffi[0] should absolutely be added to Node core, not be…

No offense taken! I am pretty new to the JS world.

"WASM will eventually allow the same choice in the browser."

When will that actually be? That's the big question.

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

#27
post #3

I'm excited about compiling to WASM not for performance but for correctness. Typescript is better than nothing but it really can't compete with the safety and ease you get from a language with a really good type system.

One thing I've been confused with about transpiled languages is how does correctness transfer? How do types or lifetimes etc. transfer to WASM, for instance? Or does it just depend on the correctness to be verified in the pre-compilation/transpilation stages?

Correctness is typically checked long before code generation happens. This does mean the code generation backend must be trusted, whether the target be x86 or wasm. Just as you have to trust CPUs to not expose processes' memory to each other (oops).

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

#28
post #17
post #3

I'm excited about compiling to WASM not for performance but for correctness. Typescript is better than nothing but it really can't compete with the safety and ease you get from a language with a really good type system.

What would you consider to be a "good type system"? I find typescript to have one of the most sane and still strict type systems of all languages that doesn't fall into the extreme functional spectrum or those that care about memory ownership.

It's not: the TypeScript type system is unsound (accepts code that violates it), and there are no runtime checks, so it doesn't actually guarantee anything: a TypeScript variable may in fact contain any value regardless of its declared type.

I'd say the best type systems are found in Rust (naturally models zero-cost abstractions but doesn't have dependent types) and Idris and Coq (have dependent types but don't naturally model zero-cost abstractions).

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

#29
post #3

I'm excited about compiling to WASM not for performance but for correctness. Typescript is better than nothing but it really can't compete with the safety and ease you get from a language with a really good type system.

One thing I've been confused with about transpiled languages is how does correctness transfer? How do types or lifetimes etc. transfer to WASM, for instance? Or does it just depend on the correctness to be verified in the pre-compilation/transpilation stages?

edit: I misread the question, my comment was geared toward languages transpiled to JS.

It's compile-time safety. Virtually none of the type knowledge exists in the runtime. Still, it's far better than nothing, with the self-documenting nature of typed code being one of the biggest wins IMO.

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

#30
post #3

I'm excited about compiling to WASM not for performance but for correctness. Typescript is better than nothing but it really can't compete with the safety and ease you get from a language with a really good type system.

One thing I've been confused with about transpiled languages is how does correctness transfer? How do types or lifetimes etc. transfer to WASM, for instance? Or does it just depend on the correctness to be verified in the pre-compilation/transpilation stages?

>how does correctness transfer?

The same way it transfers when the language is compiled to x86 instructions! By adding a pre-written and pre-compiled runtime.

Post reply on HN