Nah, it depends on your use case. Sure, it’s probably not ideal case for a site making 10,000+ hits per day. For many companies though having a dead simple “back office” web app is an ideal use case. I’m thinking dashboards with lots of graphics or “interactivity” but without needing a full SPA app. Just requires considering the trade-offs.
I use LiveView to do menus and other user interactions on embedded devices (RPi3’s) that only every have a few users at a time. It greatly simplifies creating data analysis tools. It works well and only needs to scale to a half a dozen users at a time. That’s a cake walk for LV even on an RPi3.
Yeah, it’s still early days. Overall though, I’m “bullish” on WebAssembly (whether it’s Rust, Lumen, AssemblyScript, etc.). I’m optimistic that these “runtimes” for GC languages will get optimized (especially if / when WebAssembly includes GC), and the tooling will mature.
WebAssembly has a lot of great momentum behind it. It’s exciting! I think also having a library to run WASM "NIF"s on the BEAM would be great as well. The NIF architecture is well suited to it since NIF’s essentially get serialized data. Also, alongside Rust you should add Nim – it’s a GC language but using ARC so it can live well in WASM. I’m using it for microcontroller’s and it’s worked out really well there so WASM should be a great fit for it.
I think WASI would be the target in that case. The BEAM can already communicate with C and Rust (eg. via NIF/Rustler), but there might be reasons to go the WASI route even for those languages – in addition to opening up a whole world of other languages that may eventually be able to target WASI.
