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

JavaScript to Rust and Back Again: A Wasm-Bindgen Tale

hacks.mozilla.org

Post reply on HN
Print view View original

71–79 of 79 posts

Re: JavaScript to Rust and Back Again: A Wasm-Bindgen Tale

#71

Post by Can_Not »

flavio81 wrote: post #11
jerf wrote: post #7

Earlier quoted context omitted.

"Faster-than-JS DOM performance" That will be when the clock starts ticking on Javascript. Who'da thunk one language might eventually eat both a significant chunk of C and a significant chunk of Javascript someday? I'm not saying Rust will completely eat Javascript; there is no chance that all web developers would or even necessarily could switch to Rust. But the framework war will take a very interesting turn if Rus…

>Who'da thunk one language might eventually eat both a significant chunk of C and a significant chunk of Javascript someday? Erm... PSA: Rust isn't the only language that is compiling to WASM. I'm glad for Rust developers (How exciting is for them to be able to target WASM), but what is really exciting is to have alternatives; even more exciting if they have nothing to do with javascript.

> Erm... PSA: Rust isn't the only language that is compiling to WASM.

How many other languages are you expecting that most people really want to use but don't require a multi-megabyte VM?

Re: JavaScript to Rust and Back Again: A Wasm-Bindgen Tale

#72

Post by azakai »

kbenson wrote: post #52
azakai wrote: post #45

Earlier quoted context omitted.

C# etc. shipping a runtime is a current limitation of wasm and those ports to wasm. But in principle once wasm has GC support they can also compile to tiny binaries. Not for everything, of course - if you use certain C#/Java/Kotlin features you'll need bundled runtime support. But if you avoid them, you don't. For comparison, Rust can't emit tiny binaries if you use malloc/free, because it needs to bundle those. This…

Is it really on the roadmap to support GC before a simple API level malloc/free? It seems like the sane progression path would be to have WASM support an API for malloc/free first (which would be useful any system that supports a pluggable memory allocator, as Rust is getting), them an API for requesting garbage collected bytes of memory (which I assume, with fairly little prior knowledge, malloc/free would be useful…

I'm not aware of any plans to support a malloc/free API currently. GC plans are already underway.

Thinking about it, it's actually not that obvious how to support a malloc/free API. It seems like it would need to be deterministic to fit properly on the Web. But writing a spec for that is not easy since efficient malloc/frees are fairly complex and detailed. And once specced out, it could never be improved.

GC on the other hand already exists on the Web, and all the complexity is not noticeable (except for things like proper weak refs and finalizers, which is why those have not been added to the Web yet) so the spec is fairly simple and it allows constant optimization on the implementation side.

Re: JavaScript to Rust and Back Again: A Wasm-Bindgen Tale

#73

Post by azakai »

steveklabnik wrote: post #67
azakai wrote: post #45

Earlier quoted context omitted.

C# etc. shipping a runtime is a current limitation of wasm and those ports to wasm. But in principle once wasm has GC support they can also compile to tiny binaries. Not for everything, of course - if you use certain C#/Java/Kotlin features you'll need bundled runtime support. But if you avoid them, you don't. For comparison, Rust can't emit tiny binaries if you use malloc/free, because it needs to bundle those. This…

Yeah, the question is, how much can you realistically not use those features? I don't actually know. You don't have to give up any of the Rust language. It's true that you need to ship malloc/free, but that can be really tiny too; https://github.com/fitzgen/wee_alloc is less than a kilobyte.

> You don't have to give up any of the Rust language.

I don't know Rust that well, but what about unwinding and multithreading for example - don't you need to give those Rust features up if you don't want to ship any runtime code?

> It's true that you need to ship malloc/free, but that can be really tiny too

True, yeah. It's a tradeoff, though, tiny mallocs will be much slower than an optimized malloc (like dlmalloc) on real-world benchmarks.

Re: JavaScript to Rust and Back Again: A Wasm-Bindgen Tale

#74

Post by maxxxxx »

kbenson wrote: post #50
maxxxxx wrote: post #44

Earlier quoted context omitted.

"I halfway agree. More evidence is always welcome, but the nature of that evidence will almost always be subjective, and I'm not sure a lot of language adherents even care all that much when the evidence is objective. So more is better, but "clearly demonstrate" may be pie in the sky thinking." One way to clearly demonstrate this in my opinion would be big projects that are implemented in Rust. I remember when Java c…

In that respect, I think Servo and Firefox is the big project. Unfortunately (or fortunately, depending on the direction you look at it from), due to Mozilla's putting good engineering principles ahead of marketing and pulling in proven pieces of Rust code from Servo piecemeal, most people will likely never know. The best we can hope for is not that it's just a win, but that it's such a large, obvious win that when p…

" putting good engineering principles ahead of marketing and pulling in proven pieces of Rust code from Servo piecemeal, most people will likely never know"

That's really not a good strategy. At work I can't just start using Rust without justification but if I can point at large projects being written in Rust suddenly has credibility.

Re: JavaScript to Rust and Back Again: A Wasm-Bindgen Tale

#75

Post by kbenson »

maxxxxx wrote: post #74
kbenson wrote: post #50

Earlier quoted context omitted.

In that respect, I think Servo and Firefox is the big project. Unfortunately (or fortunately, depending on the direction you look at it from), due to Mozilla's putting good engineering principles ahead of marketing and pulling in proven pieces of Rust code from Servo piecemeal, most people will likely never know. The best we can hope for is not that it's just a win, but that it's such a large, obvious win that when p…

" putting good engineering principles ahead of marketing and pulling in proven pieces of Rust code from Servo piecemeal, most people will likely never know" That's really not a good strategy. At work I can't just start using Rust without justification but if I can point at large projects being written in Rust suddenly has credibility.

For marketing a language? No, unless you ruthlessly capitalize on every small change.

For iterating on large changes to a stable secure web browser used by many millions? It seems to have worked well for them so far.

Re: JavaScript to Rust and Back Again: A Wasm-Bindgen Tale

#76

Post by maxxxxx »

kbenson wrote: post #75
maxxxxx wrote: post #74

Earlier quoted context omitted.

" putting good engineering principles ahead of marketing and pulling in proven pieces of Rust code from Servo piecemeal, most people will likely never know" That's really not a good strategy. At work I can't just start using Rust without justification but if I can point at large projects being written in Rust suddenly has credibility.

For marketing a language? No, unless you ruthlessly capitalize on every small change. For iterating on large changes to a stable secure web browser used by many millions? It seems to have worked well for them so far.

The problem is that if Rust doesn't establish itself in the broader market then the effort of developing it and adding to the browser is pretty questionable. You generally don't want code in a language nobody else uses.

I hope rust will make it but it's very hard to establish a language long-term.

Re: JavaScript to Rust and Back Again: A Wasm-Bindgen Tale

#77

Post by mmstick »

steveklabnik wrote: post #21
wffurr wrote: post #12

Earlier quoted context omitted.

Do you see any reason why it won't eventually do so?

It's still too early. There's tons of good reasons to write C code today for many projects. Furthermore, there's so much C code out there that even if nobody wrote a single new line of C today, it'd be decades before it would go away. It's really about growing the pie rather than replacement anyway, in my opinion.

Although, a lot of us are working towards replacement of C in a lot of areas. Being able to say you've written something in Rust is one thing, but having the whole stack Rust all the way down is something else. Not to mention, it's fairly simple to create C bindings from Rust libraries using Cargo workspaces and cbindgen.

Re: JavaScript to Rust and Back Again: A Wasm-Bindgen Tale

#78

Post by mmstick »

pjmlp wrote: post #49
runevault wrote: post #13

Earlier quoted context omitted.

Even if it is objectively better in every way (not saying it is, only going for the most extreme end point for purposes of making a point) it is not guaranteed to replace C. Too many people have invested too much time mastering C and learning to deal with its quirks to simply give it up. There may come a day where basically 0 new C projects are made. I do not think that will be in my lifetime. And I say that as someo…

Until we replace UNIX derived OSes and throw away POSIX compatibility that day will never come.

We've already thrown away POSIX compatibility. Linux isn't POSIX. Mac OS X isn't POSIX. Windows isn't POSIX. POSIX only continues to exist in varying degrees at different times.

Re: JavaScript to Rust and Back Again: A Wasm-Bindgen Tale

#79

Post by mmstick »

azakai wrote: post #73
steveklabnik wrote: post #67

Earlier quoted context omitted.

Yeah, the question is, how much can you realistically not use those features? I don't actually know. You don't have to give up any of the Rust language. It's true that you need to ship malloc/free, but that can be really tiny too; https://github.com/fitzgen/wee_alloc is less than a kilobyte.

> You don't have to give up any of the Rust language. I don't know Rust that well, but what about unwinding and multithreading for example - don't you need to give those Rust features up if you don't want to ship any runtime code? > It's true that you need to ship malloc/free, but that can be really tiny too True, yeah. It's a tradeoff, though, tiny mallocs will be much slower than an optimized malloc (like dlmalloc)…

Rust doesn't have a runtime, so there's no runtime code to ship in the first place. It's as low level as C, but with a modern syntax and accompanying core and standard libraries. Thread support is done by using existing OS primitives for threading.
Post reply on HN