8 ms·
So, let me get this straight… WASM is a language independent byte code that runs in browsers, like “assembly but for browsers” that multiple languages can comp
by wokwokwok 3y ago
So, let me get this straight…
WASM is a language independent byte code that runs in browsers, like “assembly but for browsers” that multiple languages can compile to instead of there only being javascript.
…but that ran in a browser sandbox, and people wanted to use it in containers, so they invented WASI, which lets WASM assembly code interact with the base system, sidestepping the container of the browser; but it needs a runtime on the host system (not a browser) to run.
Now this is WASIX which added more non standard extensions to WASI so that more programs can run on it.
We had an entire full stack cross platform runtime (browsers) to run our code in, but instead we now need to get a new set of “low level” runtimes to run the same code for, eg. containers?
Sounds a lot like java to me; byte code, runtime, “cross platform binaries”, write once, run anywhere…
How is this meaningfully different?
The only remarkable difference appears to be you can target it with existing c++ code?
- bmacho 3y agoI don't think it is meaningfully different than JVM. Why? Should it be?
- jinwoo68 3y agoI think you're basically correct. But wasm isn't tightly coupled with a single programming language, like Java did. Of course, other languages can target JVM too, but there's not much momentum there. With wasm, we have many different implementations written in many languages running in many different platforms. I think it's a good thing.
- inadequatespace 3y ago> not much momentum Scala? Kotlin? To be fair these came into play WAY after the JVM
- greenyoda 3y agoAlso Clojure.
- throwaway894345 3y agoThese are all languages that were designed expressly to run on the JVM, whereas WASM aspires to support existing languages. I'm not familiar with JVM bytecode (and would love to hear from someone who is), but I'm guessing the JVM bytecode offers less in the way of low-level control over memory allocations and so on which would be required to compile C, C++, Rust, Go, etc programs with reasonable performance characteristics?
- brabel 3y agoJVM bytecode assumes the GC allocates and frees memory, so no, you don't have direct access to memory... though the Java standard library does let you allocate bytes and manage those yourself[1], not sure if you would consider that "more control over memory allocations". JVM bytecode is quite approachable: https://en.wikipedia.org/wiki/List_of_Java_bytecode_instructions https://en.wikipedia.org/wiki/List_of_Java_bytecode_instruct... And does look superficially similar to WASM instructions. When WASM gets GC, I have trouble seeing what's fundamentally different between the two, to be honest... even something like (parts of) the Java stdlib will be available to WASM with the WASI API, making the difference too small to distinguish them into different categories IMO. [1] https://blogs.oracle.com/javamagazine/post/creating-a-java-off-heap-in-memory-database https://blogs.oracle.com/javamagazine/post/creating-a-java-o...
- throwaway894345 3y ago> though the Java standard library does let you allocate bytes and manage those yourself[1], not sure if you would consider that "more control over memory allocations". That's interesting. So if you wanted to build a C compiler targeting the JVM, you would just request a big byteslice from the API and implement your own stack + heap on top of it (such that you never actually use the JVM GC)? > And does look superficially similar to WASM instructions. When WASM gets GC, I have trouble seeing what's fundamentally different between the two, to be honest... even something like (parts of) the Java stdlib will be available to WASM with the WASI API, making the difference too small to distinguish them into different categories IMO. It sounds like the fundamental distinction is that WASM will have both manual memory management APIs as well as GC APIs while Java will only have GC APIs.
- ecnahc515 3y agoThose languages are very much designed around the JVM though. You have Scala, but not eg: C++, because the JVM itself is much higher level than what many languages would want to target.
- brabel 3y agoThe GraalVM JVM can run LLVM bitcode, hence C++: https://www.graalvm.org/22.0/reference-manual/llvm/ https://www.graalvm.org/22.0/reference-manual/llvm/
- duped 3y agoArguably, JVM languages have much better tooling for them to be designed and interoperable (through Truffle and GraalVM) than WASM where everyone has to write a backend (or use LLVM which has its downsides).
- pjmlp 3y agoExcept JVM never was the only bytecode format in the history of computing.
- reyqn 3y agoAnd with existing .Net, C, Go, Rust, Lua, Zig, Crystal, D, Elixir, also Java, JavaScript, Kotlin, Lisp, Nim, Pascal, Perl, PHP, Python, R, Ruby code (non-exhaustive list). That's a lot of flexibility
- pjmlp 3y agoJust like the CLR in 2001!
- deleted 3y ago[deleted]
- doodlesdev 3y agoSo here's the thing, CLR is still here (now called CoreCLR as of the move to .NET Core), how does it differ technically from WASM/WASI, and why aren't we using it instead? I should note I haven't spent much time studying either of them.
- pjmlp 3y agoMostly because Micro$oft shenanigans, or the fear thereof. As if the VCs baking up all those WASM products are doing it from the warmth of their hearts.
- garganzol 3y agoThey will do all the mistakes that have to be done. WASM GC is one of them.
- pjmlp 3y agoProbably, then again if it was only for C and C++ style workloads, even one more reason to stick to the past. https://en.wikipedia.org/wiki/Architecture_Neutral_Distribution_Format https://en.wikipedia.org/wiki/Architecture_Neutral_Distribut... Just one example out of many others, for C and C++ based workloads.
- pie_flavor 3y agoJava is a language with a particular view of the world, and the JVM is a heavyweight runtime for executing that particular view of the world. The core idea of the JVM is great, and WASM executes that without assuming anything about your language, or requiring a great big tightly integrated second-banana-to-the-host-language's-stdlib system library, or anything else Java-y.
- garganzol 3y agoAnd this why WASM is so great. No opinions on a language, APIs, or anything; just pure execution. Well, WASI and WASIX are APIs but they are not strictly obligatory.
- frant-hartm 3y agoWhen a wasm runtime supports garbage collection and all the already proposed APIs it will be comparable to nodejs or JVM.
- garganzol 3y agoLet's hope that will never happen because it will lead to an imminent WASM death by making it opinionated. I would also suggest to officially separate WASM from any notion of API. So that any working group anywhere in the world could design whatever API they want/need - but it would not wreck the purity of WASM as a result. WASI/WASIX initiatives are good in that regard.
- tlarkworthy 3y agoThe worse thing is that WASI doesn't support browsers as a target anymore. Edit: this supports browsers!!! Amazing!!!
- deleted 3y ago[deleted]
- flohofwoe 3y agoWASI (or rather POSIX) was never a good fit for the browser application model though. Emscripten did a pretty good job providing an incomplete "POSIX emulation layer" to get things rolling, but for WASM that needs to run in the browser it's better to go with Emscripten's web API mappings.
- preseinger 3y agowasi was never intended for browsers wasm isn't a browser-only thing
- samsquire 3y agoI think we're always looking for the silver bullet that shall make computer software development easy. The following technologies were all silver bullets: * ActiveX, COM Object model, XPCOM * Unified Modeling Language (UML) * Extensible Markup Language (XML) * Computer-aided software engineering (CASE) * Java Virtual Machine * Ionic, React Native, Qt, Gtk, Flutter Something tells me that the problem is bigger than anyone can chew and the abstraction solution is sometimes more complicated than the underlying thing being abstracted. I think WASI and WASIX is an EXTREMELY important API for the future of computing. It's a chance to create a superior operating system runtime interface.
- lifty 3y agoWhy does it have the chance to be superior?
- samsquire 3y agoCompiling native application to operating systems that Wasmer is compiled for including the browser and have the code seamlessly work in all of them, I think that's really promising. JVM forces you to write in Java or a JVM targeted language but WASM lets you compile any language that creates a WASM backend.
- vineyardmike 3y agoThis > JVM forces you to write in Java or a JVM targeted language And this > WASM lets you compile any language that creates a WASM backend Are basically the same thing. There’s no fundamental reason that all these languages couldn’t target JVM byte code instead of WASM. It never happened, not nearly as much as WASM backends are, but it could’ve.
- ShroudedNight 3y agoIt seems that NIH also manifests generationally: ? -> CORBA -> RMI -> SOAP -> REST -> GraphQL? ? -> SOA -> Microservices ? -> EDI / X12 -> XML -> JSON p-code -> ? -> JVM -> WASM
- postalrat 3y agoExisting c++, zig, rust, etc isn't the goal, it's the start.
- pjmlp 3y agoGot to get all that VC money, while trying to resell old ideas.
- deleted 3y ago[deleted]
- throwaway894345 3y agoThe JVM expects that languages will conform to its bytecode specification, which is designed first and foremost for Java. WASM's bytecode specification is designed to support the existing ecosystem of languages including Rust, C, C++, Go, etc which can't easily target the JVM. Relatedly, the body which manages the JVM specification is comprised of major Java vendors and users; they don't represent developers of other languages even if the JVM nominally supports a few of them.
- kgeist 3y ago>WASM's bytecode specification is designed to support the existing ecosystem of languages including Rust, C, C++, Go, etc which can't easily target the JVM Microsoft's .NET allowed you to compile C++ to pure CIL (.NET's bytecode) and run it inside a VM since the early 2000's. It wasn't very popular so it was deprecated. People compare WASM to JVM, but to me it looks like a more lightweight reinvention of Microsoft's CLR (Common Language Runtime) which was designed to support multiple languages (C#, C++, VB) from day 1.
- TUSF 3y ago> Microsoft's .NET There's your problem. Sure, .NET is technically cross-platform, but that's a relatively recent development, and WASM has runtimes that let it run in most environments, even microcontrollers. Also, looks like C++/CLI had conflicting syntax with standard C++, so it might not have worked on some applications without some patches.
- stephc_int13 3y ago>The only remarkable difference appears to be you can target it with existing c++ code? That changes everything. Coupling the VM and the language was IMHO a huge mistake. Wasm + WASI(X) + WebGPU is what the Java VM should have been. I guess we were not ready at the time.
- pjmlp 3y agoWe were ready plenty of times, Java wasn't the first.
- paulddraper 3y ago> Sounds a lot like java to me; byte code, runtime, “cross platform binaries”, write once, run anywhere… 100% WASM is "Java byte code for the 21st century." > How is this meaningfully different? It's lower level, making it a lighter, more flexible target platform for a variety of languages. No classes, typing, GC (yet), required runtime, etc. Whereas Java byte code is really only meant for Java (and variants -- Groovy, Clojure, Scala, Kotlin)
- sroussey 3y agoIt’s different from the browser sandbox in that it is targeting servers not clients. That said, you can run a large subset in the browser.
- pjmlp 3y agoSo basically CLR in 2001.
- paulddraper 3y agoBasically. A key difference is that it's actually gaining traction on multiple platforms. IDK if CLR tried and failed to do that, or just didn't try.
- pjmlp 3y agoMono, Xamarin, Project Rotor,...
- moonchrome 3y agoEvery thread about WASM is "this is just JVM". No it's not. If you want to know how it's meaningfully different - go look look high level overview of JVM and WASM - and if you still don't get it - then you're probably not the target audience for either and you should just be using whatever the tool stack it's targeting them. A bus and a cargo truck are not the same just because they have similar wheel base/size and abstractly do the same thing.
- jeroenhd 3y agoTo me WASM just seems like the JVM without special OOP instructions. It never started out that way, but it certainly is ending up that way. Everything that made WASM stand out from the traditional bytecode VM is being patched back in through extensions like WASI and now WASIX. I was originally excited for WASM because it started out as a fully sandboxed system. No I/O other than flat memory buffers, so no chance whatsoever of escaping its sandbox. Now WASIX introduces networking, file system I/O, mutltithreading, forking, even TTY support. It's not as powerful as the JVM yet, but give it a few years and I'm sure you can use them interchangeably in a few years.
- ShroudedNight 3y agoThis reminds me of the old adage that the most secure computer is one that has never been, and can never connect to anything. It's also rather limited in its usefulness.
- jeroenhd 3y agoThe limitations are what made WASM attractive to me. If I want a fast component to re-encode images, or to render a 3D scene, or to analyze and transform data, I don't want to have to set up a network namespace, alternate file system roots, and all the other annoying stuff that comes with sandboxing. WASM not being able to do or access anything you don't manually provide allows for quickly and easily hooking in executable code without the normal risks. Add enough extensions to the runtime everyone uses and you end up with another JVM. The JVM is very good and so is the .NET runtime and any other bytecode runtime you can think of, but the distinctions start to fade as more features get tacked onto WASM.
- vbezhenar 3y agoYes, it is "JVM reimagined". It has very little with browsers, though. IMO this is wrong direction. Better direction is to move into browser. Add arch/wasm to linux kernel. Compile it to wasm. Compile systemd to wasm, glibc or musl, with docker in the end. Now you can run linux in your browser. You could run it before, but this way makes it as native to browser as possible. Probably will be very fast and suitable for work. Now with docker ask people to compile their software to wasm. Now you can run postgres and kubernetes in your Chrome tab. All you need is some escape hatch for network ingress/egress which is not hard to implement. May be implement virtio-gpu with webgpu and you can easily run full-fledged Gnome in your browser tab. Not hard to sync your disk to S3, so you can open this VM from any computer and run it locally. Basically VM in your browser, cross-platform, cross-architectured.
- laxd 3y ago> Now you can run postgres and kubernetes in your Chrome tab. This is what the world has come to.
- paulddraper 3y agoSooo.....a VM?
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- pookha 3y agoI think it's more about streamlining application deployments and removing the containerization hurdle...The dream seems to be a universal byte-code (WASM) vm that would open the door so that Python, Node, Java 58LTS, Rust, C or freaky Lua scripts could run on the same runtime -- easily -- without container wrappers that each have to be secured (patches) and with a startup penalty.
- kelp 3y agoI think server side WASM has the potential to be the next thing after containers. And yes, lots of echoes of Java's "write once run anywhere" but as lots of people have pointed out, wasm is language agnostic, and many languages have support for it. Since I've been web applications and distributed systems, the evolution has been something like this. 1. Copy files around, into the web or application servers directory. This was simple but isolation, repeatability and testability was hard. The application dependencies were directly tied to the host, so you had to be very careful about your upgrades breaking applications. The lack of isolation is not suitable for multi-tenant environments for security and capacity planning reasons. It's pretty hard to run multiple-applications (1) 2. Things like bundler, and other language specific tools that let you bundle your application dependencies together. Avoids some of the host OS related upgrade issues, but again, no real isolation. 3. VMs. The whole cloud industry started on this. You get true isolation of your whole application at the cost of complexity and weight. Scheduling new VMs is not a fast process because you're copying around or at least booting a whole OS. You still have to manage OS images. There is also generally a tax on memory that you have to pay, so you waste some resources with VMs to get the isolation. Amazon invested in Nitro to avoid paying a lot of this tax. 4. Containers. Lighter than VMs, good enough isolation in a lot of cases, especially inside of an organization. Lower tax than VMs. More testable. But containers are still fairly heavy, startup time can be slowish. So you have some limitations on how fast you can scale up and down in response to load. Also isolation isn't good enough for some workloads. So we see things like firecracker VMs being used to improve isolation. 5. Wasm on the server side. Much lighter than containers. Less memory overhead, way less startup time. Probably faster startup time than even firecracker. So for lambda like workloads you could could have a lot better cold start latency. You probably have good enough isolation that you don't need to resort to things like firecracker to isolate customer workloads. Because of the fast startup time you could probably pack your long tail of workloads even tighter to get better effective utilization out of your server infrastructure. (1) In the early 00s I worked at a place where we wrote our own simple process supervisor and used some tricks with LD_LIBRARY_PATH to let us bundle all application dependencies with the application. So you could run multiple application that needed different libraries on the same host, and upgrade your host without as much worry about host OS library changes breaking our applications. It was a kind of proto-container, without all the other isolation cgroups give you.
- preseinger 3y agowasm targets more than just browsers