Hacker News Reader

Go has to embed it's runtime and GC into builds, so build size and performance will take a hit here. Same goes for most popular languages.

For me Rust offers the best WASM experience and tooling at the moment.

Rust has no GC and (almost) no runtime.

It also has official wasm build target support out of the box, including generating Typescript definitions for Rust types.

The ecosystem is somewhat well-developed:

* wasm-bindgen for general interop in both directions

* js-sys / web-sys for (low-level) type-safe and surprisingly efficient browser API bindings

* wasm-bindgen-futures for easy Promise <-> Future interop

* wasm-pack for easy building

* ...

Getting the code size low is still a challenge though.

A Rust implementation of the Krausest frontend framework benchmark takes a top 4 spot [1]. Despite this benchmark not favouring wasm at all since it requires little computation and mostly does FFI calls.

(ps: C++ is in a decent state as well)

[1] https://rawgit.com/krausest/js-framework-benchmark/master/we...

It is still much smaller than most SPA used to display static text.

> Go has to embed it's runtime and GC into builds, so build size and performance will take a hit here

I expect that WASM doesn't have the concurrency model required by a modern concurrent garbage collector like Go's, but perhaps I'm wrong.

It's likely much slower, but it should be able to run just fine single threaded as well.

> C++ is in a decent state as well

I’d still choose Go or Rust over C++, though, because they’re memory-safe. This recent discussion shows that’s still important in the context of WebAssembly: https://news.ycombinator.com/item?id=24216764

Sure, for new projects I choose Rust over C++ whenever feasible.

But a huge amount of the worlds software is written in C++, and will remain so for decades.

Getting some of that code to run well in WASM can be a big win for certain domains.

Modern C++ has a lot of memory safe operations if you use them (smart pointers, atomics, actually using RAII properly and universally), although I'm not sure how much overhead they might add to a wasm blob. Rust seems almost perfect for it though, but no reason to discourage C++ people; it can be a relatively modern language if you let it.

As someone that loves still having C++ on the toolbox, that is unfortunately only true if you have 100% control over the source code and have all team on modern C++ mindset.

> it is pretty magical seeing something written as a CLI tool running in a browser with minimal changes.

Years ago, I wanted to write some code that could run both as part of a command-line app and an in-browser tool. I asked what language I should use for this shared code and was told, basically, that there was no suitable language.

Now, thanks to WASM, there are lots!

This is indeed nice but in fact you could run C/C++/Rust before too, with asm.js. Not to mention the languages that target JS and can run on Node or the browser.

How come? I have done that eons ago with Java.

Perhaps if you like TypeScript and still want compile to WebAssembly you might be interested in AssemblyScript which stricter subset of TypeScript which compile to wasm

I poked a similar project a while back. If I can just as easily have understandable, easily debug-able JavaScript as output target, I believe that’s preferable. Particularly where extreme performance is not a concern.

Tools like GopherJS, Elm, Dart and such output JavaScript no human could reasonably interpret. WASM seems logical for them. TypeScript outputs very human readable JS (for the most part) and WASM seems to have little virtue.

As someone who learned JavaScript in the late 90s / early 2000s reading websites code, outputting readable JS feels like giving back.

> Most of my early excitement for WASM circled around “Hey, I can finally use a decent language on the web”

This has been true for years, various languages can compile down to JavaScript. Kotlin and Dart, for instance.

Also, doesn't WASM lack a garbage collector? I imagine porting a language to WASM is still quite a task, and presumably a GC written in WASM is going to be far inferior to one provided by the browser, as with JavaScript. (Corrections welcome if I'm wrong about that.) That's not to dismiss the potential for performance gains in situations well suited to WASM.

(I see the_duke already mentioned the GC situation.)

>> non statically validated, frustrating experience of trial-and-error that somewhat undermines the joy of a statically typed language.

That's because officially Go has not support for web APIs(as wasm has no access to web apis) so you have to callback through JavaScript. However once you build the right wrappers around JS APIs and the tools to deal with HTML the experience is pretty nice.

As another poster said-- C++, C or Rust may give you better luck when compiling to WASM. You could also try TinyGo. Vanilla Go's embedding of its entire runtime and GC is ... a lot.

does it matter much after it's cached locally though? I mean say for single page web apps. I could see that not being a big issue, but if you have to reload the page a lot it might, but loading 1 Mb into memory is nothing to most modern CPUs if it's pulled off the hard drive.

I started working on a game in Go (with Ebiten-- which is an awesome engine for native!) and hit perf issues in simple scenes that just worked flawlessly with similarly trivial code in C++ with SDL. It wasn't about the size as much as the performance overhead of having a GC and just generally maybe more lax runtime overhead philosophy than Rust / C/C++. I think deterministic memory management and memory layout control is the main perf benefit you get with WASM over JS for the type of stuff I was working on-- both things there's more natural methods for in Rust and C++. I also prefer being able to monomorphize generic code and have it inline etc. (esp. with entt) vs. the vtable stuff you tend to see with Go interfaces (this is totally up to coding style / practices and both are doable in both...).

You can also see this with Gio UI library in Go where they try to minimize GC overhead yet one keeps hitting GC pauses in WASM. The author talks about some of the issues with Go on WASM here: https://changelog.com/gotime/128

It did help that after diving back into the new stuff in 'modern C++' with auto, lambdas and move semantics I was able to write quite ergonomic code without any actual manual memory management stuff going on.