Comment by _TA_12_ | Hacker News Reader

Comment by _TA_12_ | Hacker News Reader

>> We believe that WebAssembly will be a crucial component for the future of software execution and containerization (not only inside the browser but also outside).

Why? I don't get that or maybe miss some crucial parts or maybe it's just a too enthusiastic statement. I understand the security issues of running external code. Those security issues can be reduced with a sandboxed environment like a WA runtime.

On the server side the vast majority of the industry is running their own code. There are already many options like lambda-functions, hosted container environments, hosted VMs or of course running your own. So why take this extra step? Running plain binaries of your code is easier, faster and more reliable. Building, distributing and running a Go service is actually one of the easiest parts in the whole development and operations chain. Same is true for Rust or .NET Core. Even with Java where you need a runtime I don't see how a WA runtime solves a problem at all when running your own code.

I see great potential where you need to run untrusted code. Customer plugins for some edge server. But that is really a niche in terms of overall market.

I see the main advantage in this as running a polyglot application as if its native. For example if you are making a Rust application, you can have a plugin architecture where the plugins run inside a wasm compiled python interpreter.

I dont know if doing this directly and cross platform is as easy without wasmer

Just like CLR, JVM and GraalVM, nothing new besides WebAssembly marketing.

Absolutely. But I think wasmer is a lightweight VM compared to those.

Wasm is structurally similar to those things, yes, but is so much faster that it is actually categorically different.

Of course it is so much faster, it does almost nothing.

I hope your cynicism is a force for good in your life.

Indeed, it helps me to stay away from hype tech until it finally settles mainstream adoption.

The good part is that I save lots of failed projects when that isn't the case, and get consulting gigs to port back into what everyone keeps using.

No need to recompile means you can run the same, guaranteed known, signed, etc code everywhere.

Purpose-built sandboxing means you can run untrusted code more safely — e.g. at the network edge, like a Cloudflare worker, a lambda, etc. Same for third-party plugins in apps, etc.

An open standard and open implementations gives you some assurance against lock-in, licensing changes, patent suits, etc.

All of it already exists with the JVM.

The JVM is rather heavy weight and typically slow to start even when you do have enough resources to run it. That rules out edge computing. Graal AOT compilation is more similar but not a general purpose thing currently as it only works with tools and languages optimized for that.

I say this as a Kotlin/Java developer. I know and love the jvm but it's just not a lightweight option suitable for edge computing or serverless computing (it works but the jvm startup overhead + binary size is annoying).

Java has had AOT compilation support since around 2000, when commercial JDK vendors started supporting it, what it lacked was free beer AOT compilation, as GJC never really did it without issues and was quickly abandoned when OpenJDK came into the scene.

Isn't the JVM too high level for compiled languages without garbage collection? E.g. can I efficiently compile C to the JVM without asm.js-style hacks which degrade performance?

It may be. As far as I know GraalVM can compile it AOT, but I don’t know about it’s performance characteristics.

Reply on news.ycombinator.com