Hacker News Reader

Hacker News

Comment by Waterluvian | Hacker News Reader

Full thread

Waterluvian

What's a solid language choice for targetting wasm if I want to kick the tires? Go?

View on HN

Rust has a pretty great WebAssembly story:

https://rustwasm.github.io/book/

Learning Rust at the same time as Rust+WebAssembly might be a bit of a reach, though.

Is there documentation on Rust+WebAssembly that is presented more like a conventional book or tutorial?

I don't do well with example-driven documentation like these. Resources like the original rust book are excellent though.

Is there really that much to learn?

You can just target WebAssembly like this:

cargo +nightly build --target wasm32-unknown-unknown

Okay, then how do I run that? How do I interface with the JS/DOM world? (Those are rhetorical questions. I just mean to show that there is, in fact, more to learn.)

Try (after installing of rust and cargo via rustup):

  # Install support for "wasm" command for cargo:
  cargo install cargo-wasm
  # Install wasm target and wasm-gc tool:
  cargo wasm setup
  # Create new wasm project:
  cargo wasm new hello_world

and then in hello_world directory:

  # Build and run wasm project:
  cargo wasm run

I'm going to have to be that guy and say, did you try googling it?

Here's one guide: https://hackernoon.com/compiling-rust-to-webassembly-guide-4...

I was under the impression that the wasm emscripten target was deprecated in favor of the rust-specific wasm target. Am I wrong?

You're not. Well, it's not officially deprecated, but it pretty much is, yeah.

https://rustwasm.github.io/book/

C or C++. Everything started with C and the first language for everything will be C.

https://webassembly.org/docs/c-and-c++/

"WebAssembly is being designed to support C and C++ code well, right from the start..."

I just started playing with Go's WebAssembly support last night. Support is still nascent but I was able to get up and running very quickly, and the API is dead simple: https://github.com/golang/go/wiki/WebAssembly

On the Go front, TinyGo (a subset of Go targeting embedded dev) recently added Wasm support:

https://github.com/aykevl/tinygo

It's output files are very small (~1kb for the toy examples), as it does dead code elimination, which is missing from the mainline Go approach (for now).

Both Go and TinyGo are in very early stages of their Wasm support though, so things are changing and updating fairly quickly. :)

The go compiler does dead code elimination. I'm not familiar with TinyGo but from the readme one thing it does do differently is drop the whole scheduler if there are no blocking go routines.

> The go compiler does dead code elimination.

For Wasm output? It really doesn't seem like it. Output binaries from the mainline Go compiler (atm) are ~2MB. Most of which is dead code.

Rust or C++ were easiest when I tried it last.

.Net with Blazor.net is pretty neat.

C# doesn’t get a lot of love on HN, but we’re launching our first Blazor app in production this week and it’s been pretty easy to use.

Blazor is (currently) using the mono .net interpreter compiled to WebAssembly. This seems to me more of a proof of concept than something you would really want to use.

With garbage collection support landing in WebAssembly we might see compilation of .net IL to WebAssembly, but that’s still out in the future.

We found it good enough to build internal apps. Better than our current JS setup because it’s far more productive.

It’ll make its way into .net core 3.0, so I think it’s more than just a poc.

It’s early of course and not very flexible, if you want to build something it wasn’t meant for, it breaks.

what's the performance penalty of the mono VM?

Performance is fine, but it’s still too big for slow internet. A simple form for turning in signed data and starting an internal service is easily a few MB. Which isn’t a problem for internal solutions that never leave the administrative network, but we’ll keep doing vue and graphql Apollo for our apps that have to function on mobile networks for the time being.

The really cool thing about Blazor is currently with a couple small changes, you can switch it to a server side "Razor Components" app. The idea behind the server side concept is that it uses Web Sockets to tell the browser what changes to make. All the logic happens on the server side.

There are a lot of pros & cons here to this way. Some pros are a fast initial render & small amount of bytes needing to be sent. Cons are you need internet access & render changes aren't as fast as client side.

This biggest pro I see though is being able to develop a front end app that you can later switch to Blazor/Web Assembly with the client taking over part of the logic when Blazor & Web Assembly are less experimental. For internal apps, or apps where you know the internet/network connection should always be good, this is a great way to go.

We had a look at Blazor at work the other week. My colleagues liked it, but on my computer the tooling crashed when asked to build the standard template project.

Like a lot of things these days, Blazor has a website way more polished than the actual product. It's very interesting, but I'm surprised you find it ready for use in production.

Currently, the c++ wasm tool chain is the most mature one.

Go has a large footprint with 2.5MB hello world wasm and some glue dependency.

Rust has a similar footprint at first sight but can be shrinked significantly:

wasm-gc test.wasm # 1.7MB -> 100 bytes

IMHO the rust language is quite ugly, so you might take a fresh look at c++ which became surprisingly readable with its new features (auto, initializer_lists, nice for loops, ...)

I wrote a PoC tool the other day that can shrink the Go emitted WASM by a little bit: https://github.com/cretz/go-wasm-bake

C++ is already used in production by big companies. It currently is deployed as asm.js. But you can use an equivalent toolchain to create WebAssembly.

This way you can create production-ready code and be ready to move to WebAssembly as soon as it gets feature ready.

The fine control that C++ offers will help you to understand the underlying architecture and put its performance to test.

Pretty good list https://github.com/appcypher/awesome-wasm-langs

C++

Go doesn’t have thread support yet AFAIK.

While it may not support atomic ops yet, it still supports all language concurrency via suspend points throughout the WASM.

Depending on what you are doing you shouldn't dismiss Unity3D and C#.

Adding multi-threading support for WebAssembly is on the roadmap for 2019.1

Reply on news.ycombinator.com