4 ms·
>> We believe that WebAssembly will be a crucial component for the future of software execution and containerization (not only inside the browser but also outsi
by _TA_12_ 6y ago
>> 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.
- vijaybritto 6y agoI 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
- pjmlp 6y agoJust like CLR, JVM and GraalVM, nothing new besides WebAssembly marketing.
- vijaybritto 6y agoAbsolutely. But I think wasmer is a lightweight VM compared to those.
- sagichmal 6y agoWasm is structurally similar to those things, yes, but is so much faster that it is actually categorically different.
- pjmlp 6y agoOf course it is so much faster, it does almost nothing.
- sagichmal 6y agoI hope your cynicism is a force for good in your life.
- pjmlp 6y agoIndeed, 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.
- nine_k 6y agoNo 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.
- kaba0 6y agoAll of it already exists with the JVM.
- jillesvangurp 6y agoThe 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).
- pjmlp 6y agoJava 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.
- flohofwoe 6y agoIsn'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?
- kaba0 6y agoIt may be. As far as I know GraalVM can compile it AOT, but I don’t know about it’s performance characteristics.