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

61–70 of 79 posts

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

#61

Post by nimmer »

FridgeSeal wrote: post #47
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…

> 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 Rust gets faster access to the DOM than JS can provide, and is also a faster language than JS, Maybe a good way of kicking this off is if someone writes a DSL/hosted language that compiles/transpiles/whatever down into Rust. Have this language be nice and easy to writ…

Nim does that with JS. Wasm generation requires someone to write a compiler backend for it but it can be done.

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

#62

Post by [deleted] »

jcoffland wrote: post #46
vardump wrote: post #23

Earlier quoted context omitted.

I think IoT will push embedded development towards Rust. As well as security critical desktop/server code. Especially when said code needs to be a loadable library (.dylib, .so, .dll). While Rust certainly isn't the silver bullet, it demonstrably significantly reduces memory and concurrency related bugs. Yeah, the last firmware I developed was in C and assembler. No, I could not have done it in Rust, mainly due to no…

Since Rust does not yet really work on ARM Cortex or AVR it's still a long way from taking over IoT. Only devices with an OS, like a RaspberryPi, are properly supported by Rust at this point. That's a huge limitation. GCC can target literally hundreds of bare metal devices with C and even C++. Developers have been using C and C++ successfully in IoT devices for years now. Rust may be the bees knees but it has many hu…

[deleted]

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

#63

Post by vardump »

jcoffland wrote: post #46
vardump wrote: post #23

Earlier quoted context omitted.

I think IoT will push embedded development towards Rust. As well as security critical desktop/server code. Especially when said code needs to be a loadable library (.dylib, .so, .dll). While Rust certainly isn't the silver bullet, it demonstrably significantly reduces memory and concurrency related bugs. Yeah, the last firmware I developed was in C and assembler. No, I could not have done it in Rust, mainly due to no…

Since Rust does not yet really work on ARM Cortex or AVR it's still a long way from taking over IoT. Only devices with an OS, like a RaspberryPi, are properly supported by Rust at this point. That's a huge limitation. GCC can target literally hundreds of bare metal devices with C and even C++. Developers have been using C and C++ successfully in IoT devices for years now. Rust may be the bees knees but it has many hu…

ARM (thumb 2, Cortex M0-M4) is by far the most important target. Second is cores like Cortex A7 and A53.

I think AVR is pretty minor outside hobbyist circles. After ARM support, I'd rather first see MSP430 (amazing for low power), some FPGA softcores (like NIOS, microblaze, etc., common in low volume, industrial & medical devices) and even 8051 (these buggers seem to still be everywhere, but I guess targeting Rust for this arch is the ultimate challenge.).

I guess RISC-V would be cool as well, I can see this getting more popular in the future, eating ARM market share.

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

#64

Post by steveklabnik »

Vinnl wrote: post #56
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…

I don't really mind Javascript that much, although I do agree that there are definitely nicer languages, and that Rust is probably one (I haven't worked with Rust yet). That said, one really nice thing that I fear we'd lose is the interoperability of the ecosystem. There are a lot of good libraries available for Javascript that help doing webdev, and I wonder what effect fragmentation of languages could have on that.…

One project you'll hear about soon is wasm-pack; it's a tool that lets you take wasm-bindgen, compile your Rust to wasm, and then upload an npm package containing just the wasm, so that anyone using Node can use your stuff.

The real issue is the various runtimes, not the actual libraries themselves.

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

#65

Post by steveklabnik »

jcoffland wrote: post #46
vardump wrote: post #23

Earlier quoted context omitted.

I think IoT will push embedded development towards Rust. As well as security critical desktop/server code. Especially when said code needs to be a loadable library (.dylib, .so, .dll). While Rust certainly isn't the silver bullet, it demonstrably significantly reduces memory and concurrency related bugs. Yeah, the last firmware I developed was in C and assembler. No, I could not have done it in Rust, mainly due to no…

Since Rust does not yet really work on ARM Cortex or AVR it's still a long way from taking over IoT. Only devices with an OS, like a RaspberryPi, are properly supported by Rust at this point. That's a huge limitation. GCC can target literally hundreds of bare metal devices with C and even C++. Developers have been using C and C++ successfully in IoT devices for years now. Rust may be the bees knees but it has many hu…

> Only devices with an OS, like a RaspberryPi, are properly supported by Rust at this point.

You must be confused, as this isn't true. https://www.tockos.org/ is even an OS written in Rust for ARM boards.

ARM Cortex stuff already works, AVR is coming.

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

#66

Post by steveklabnik »

vardump wrote: post #63
jcoffland wrote: post #46

Earlier quoted context omitted.

Since Rust does not yet really work on ARM Cortex or AVR it's still a long way from taking over IoT. Only devices with an OS, like a RaspberryPi, are properly supported by Rust at this point. That's a huge limitation. GCC can target literally hundreds of bare metal devices with C and even C++. Developers have been using C and C++ successfully in IoT devices for years now. Rust may be the bees knees but it has many hu…

ARM (thumb 2, Cortex M0-M4) is by far the most important target. Second is cores like Cortex A7 and A53. I think AVR is pretty minor outside hobbyist circles. After ARM support, I'd rather first see MSP430 (amazing for low power), some FPGA softcores (like NIOS, microblaze, etc., common in low volume, industrial & medical devices) and even 8051 (these buggers seem to still be everywhere, but I guess targeting Rust fo…

MSP430 already works, as far as I know. RISC-V is there too.

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

#67

Post by steveklabnik »

azakai wrote: post #45
steveklabnik wrote: post #19

Earlier quoted context omitted.

Rust has some significant advantages compared to languages like Kotlin, Java, and C# here. A really big one is binary sizes. To get those languages to work, you have to ship the entire runtime. For example, see https://www.infoq.com/news/2018/01/mono-cs-webassembly > (the "hello world" example is 10 megabytes) The "hello world" example in Rust is ~100 bytes . Some applications and some people can pay these costs, it'…

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.

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

#68

Post by steveklabnik »

maxxxxx wrote: post #43
steveklabnik wrote: post #39

Earlier quoted context omitted.

> Doesn't the small size only apply if you compile to assembly? If you compile to webasm shouldn't things be different? I'm not sure what you mean, could you re-phrase maybe? The article is talking about compiling to WebAssembly already.

A previous poster states that a "hello world" in Rust is 100 byte. Is that Rust compiled to machine or webasm? Simple C# compiled to an exe is bigger but by not much. But you need a big runtime. Now if you compiled C# to webasm you potentially wouldn't need the .NET runtime so the result should be quite similar to the Rust code. In addition if you modified the C# compiler to have a real linker that only includes code…

That's Rust compiled to WebAssembly.

> Now if you compiled C# to webasm you potentially wouldn't need the .NET runtime

Why not? How does C# work without the runtime? As the docs for .NET Native say:

> You can continue to take advantage of the resources provided by the .NET Framework, including its class library, automatic memory management and garbage collection, and exception handling.

So you still have that runtime code in your binary, even if it's not JITted.

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

#69

Post by steveklabnik »

pjmlp wrote: post #51
steveklabnik wrote: post #31

Earlier quoted context omitted.

I don’t doubt they’ll get some reduction, but it will always be more than zero.

Yep, as I stated it is never going to be as small as Rust. Still, it might be small enough. Check the new version of Unity for browser deployment. https://youtu.be/EWVU6cFdmr0 796 KB for a Flash like game, with the productivity of all Unity's tooling, is already more than good.

That's awesome!

I still think that's an order of magnitude too high for a lot of use cases, but much easier to swallow for sure.

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

#70

Post by Vinnl »

steveklabnik wrote: post #64
Vinnl wrote: post #56

Earlier quoted context omitted.

I don't really mind Javascript that much, although I do agree that there are definitely nicer languages, and that Rust is probably one (I haven't worked with Rust yet). That said, one really nice thing that I fear we'd lose is the interoperability of the ecosystem. There are a lot of good libraries available for Javascript that help doing webdev, and I wonder what effect fragmentation of languages could have on that.…

One project you'll hear about soon is wasm-pack; it's a tool that lets you take wasm-bindgen, compile your Rust to wasm, and then upload an npm package containing just the wasm, so that anyone using Node can use your stuff. The real issue is the various runtimes, not the actual libraries themselves.

That's a good point, and good news!
Post reply on HN