Obviously you either love wasm or you’re paid to love it, but consider whether or not the articles you’re posting are meaningfully different from what’s been posted already. At this point I think we know that docker and redhat are pleased to support wasm in docker.
Hi I am still learning which is encouraged and which is not. Thanks for the feedback. 🙏
Seems like the content has a lot of restrictions. Maybe I should delete this but I do not see a delete button
Ever since I became aware that Wasm is marketed for that purpose, I wonder what makes Wasm more suitable compared to, say Java Bytecode? The points mentioned in the article’s “What’s great about Wasm?”, open, fast, secure, portable, efficient, polyglot; all, more or less, and some probably subjectively, also apply to Java (Bytecode). Java also has JIT and AOT compilation. It seems like one could largely s/Wasm/Java/ in the article. And in fact, I believe Java VMs are popular as VMs within Docker.
I wonder how much of the “Wasm in Docker” hype is “Forget everything we already have, Wasm is the new hotness”, and I really like to see a good technical discussion about the advantages of Wasm and where Wasm is different from Java (e.g., garbage collection? better C(++) to Wasm support?), instead of, what reads like marketing material.
I’ve long said WASM is a better JVM. It even started out for a purpose similar to one the JVM used to have (native code in webpages).
WASM is much lighter than JVM, doesn’t require a GC, an object system, a type system beyond primitives, threads, etc.
WASM is also more secure by default than JVM (for the relevant value of secure, which is things escaping the sandbox) – WASM by default can do no IO at all just pure computation. If you want other abilities (threads, printing to terminal, etc) you need to define an interface and pass it in to the WASM from outside.
WASM also has many very embeddable implementations, so passing in arguments by eg writing directly to the virtual memory space instead of exposing some IO operation is an option in many cases.
So you are right, but I still think WASM is a big improvement on JVM for many uses.
Thanks, that matches would I expected the answer would be.
I am unsure about the “Wasm is more secure” part. Of course, if you do not allow I/O, then it is super secure, but also useless. Java is a memory safe language, Wasm, being very much low-level, appears to be not. So I see here an advantage on Java with regard to security (in the absence of Java calling native code). Ultimately, the process in which the Wasm or Java code runs appears to be relevant mechanism for security. Unless you have multiple tenants within the same processes, which seems insecure regardless if you use Wasm or Java.
I am also skeptical about the “better JVM” part. Both seem to target different audiences and are placed on different ends of the design spectrum.
if you do not allow I/O, then it is super secure, but also useless
if you do not allow I/O, then it is super secure, but also useless
Having built an entire extension mechanism for a large SaaS product where we used WASM with no I/O allowed, I wouldn’t call it “useless”. But also if you need some IO you can very tightly restrict it because you pass in exactly the capabilities to allow. So for example, not a socket factory but just a method for making API calls to your own system’s API.
And yes, the memory safety thing is relevant and why I said “for the relevant value of secure, which is things escaping the sandbox”. It is easier on average to attack a WASM blob from the outside and pwn its insides than a well-secured program (though JVM with reflection attacks etc isn’t always much better here), however once you are inside it is harder to break out of a WASM blob than out of a JVM image. So it depends on your threat model.
“No I/O” for me means literally nothing can get in or out. Obviously your definition seems different. Could you elaborate on that? I am also not sure how what you described is better than, e.g. restricting the process by means of the operating system. I really like to understand the advantages Wasm in this regard
Sure, I’ll give an example of what “no IO” meant in the system I designed. We would take an API call in to our service (written by us in rust, not the wasm part yet) and write a representation of that into the memory space of a loaded wasm blob (written by a 3rd party extension dev) then we would run the blob and it could only do computation, but of course had access to this data (appearing as a function argument) that was in its own memory space. Then it would finish, leaving the return value/result in it’s memory, our service would read it out of there and return it as the API result.
Restricting process by OS means you need to remember to restrict everything, the process can still try to make the syscalls but if properly restricted will error. If there is an OS bug or similar you can escape, or if you forget a needed restriction, etc. With WASM the code cannot make the syscalls, not because it is prevented from doing so but because there is no way in its language to even try.
There’s actually a great response to this question here.
The tl;dr is:
wasm is better suited as a target for compiled languages like C, whereas the JVM is inherently tied to garbage collection and a higher-level bytecode. The JVM was never intended as a target for other languages, whereas this is the primary use case of wasm.
WEBASSEMBLY FOR THE JAVA GEEK https://www.javaadvent.com/2022/12/webassembly-for-the-java-geek.html
Thanks for pointing to this. This article has greater technical depth and hence is more what I was looking for. But let point out that invokedynamic was also added for efficient support of Lambdas in Java. Dynamic JVM-based languages like JRuby benefit from invokedynamic for similar reasons.
please don’t use the story text to summarize the link.
OK. Thanks! Though it is not the story text?
Please don’t use the story text to editorialize, either.
Haven’t run the numbers myself, but wondering how this compares to a static built Rust x86 program on scratch? Would expect better performance and probably slightly lower space usage?
Based on https://ricochetrobots.kevincox.ca/ I found that wasm was about half the speed of native. Not this was about 4 years ago so newer wasm instructions and better compilers may be closing tbe gap.
Of course this is a very compute heavy use case so if you are doing more IO the performance is likely closer.
Ok, it looks like wasm has got much better. Testing again I got 10.4s native and 11.7s wasm. That’s remarkably close!
I don’t think WASM runtimes are caught up with performance yet since it is another translation layer and may not ever get to native but I can see it getting pretty close. And the benefits of re-introducing the “write once run anywhere” concept seems valuable.
What I don’t really understand is who’s asking for this. WASM still feels like a solution looking for problems. But it’s early days, I think running untrusted code for plugins/extensions/addons/etc in browser/client/server environments is the most interesting use-case.
I think the biggest attraction of WASM is the ability to define new, thin platform layers. Something that can run WASM + WASI with a network device, or WASM + a hook to handle HTTP requests and generate responses can be incredibly thin in comparison to a Linux VM. The thing I’m missing is what value Docker adds here (but then, I didn’t understand the value Docker added to the Linux ecosystem until a good few years after every else, so I might have missed something).
I think Docker is using their clout to keep WASM from being an existential threat. By using Docker as a “common runtime” (being a bit loose conceptually) they can remain in dev workflows.
what value Docker adds here
what value Docker adds here
With the support of Wasm, Docker brings the same workflow that developers know and love to Wasm. For example, you can build an OCI image, share the OCI image using an OCI-compliant registry, and run the OCI image using a WASI runtime. See slide 21: https://static.sched.com/hosted_files/cloudnativewasmdayna22/9f/Wasm%20Day%20NA%202022_%20Docker%20%2B%20WasmEdge.pdf
I don’t think anyone loves the docker ecosystem and it’s ways. I would argue people mostly tolerate it
It makes my job much easier so, as much as one can “love” a technology, I’m definitely in that demographic (as are most of my peers/coworkers/friends)
It not clear to me that the Docker model is a good fit for the kinds of WevAssembly systems that I expect to emerge. I don’t expect the, to provide a local filesystem in most cases, so the image is a single binary and there’s no point in having multiple layers or any of the other things that a container image provides in such a model. I expect them to provide rich strongly typed interfaces to the host, which means that you will have a lot of configuration state that is external to the container image. Perhaps more importantly, I expect them to be deployed as fleets of tiny components, which may or may not run on the same host, so the container abstraction provides a bundling mechanism that is in exactly the wrong place.
First time posting. I gotta say I find it hard to find many tags. Like cloud/ cloud native, K8s, edgecomputing, docker, cncf to name a few…
That is by design
To elaborate on fs111’s comment a bit, the normal thing here is to err on the side of too few tags rather than too many. The original purpose of tags on lobsters was actually to enable people to hide stuff they didn’t want to see, rather than to enable discoverability. If you put more tags on, your story is likely to be seen by fewer people.