indeed! it's crazy how many projects that essentially do the same thing are being built and maintained in parallel, just because of language boundaries
also abstracts away hardware, enabling platform agnostic code, which along with not having to fiddle around with platform-specific code for each platform, could enable us to break free from archaic operating systems and create a new one from scratch, as long as the new OS supports WASM also, it can allow for a programming language renaissance bc as long as you support WASM, you can ignore the number one thing (imo) that holds back programming languages, which is lack of libraries
I can't help but be reminded of Java's promise of "Write once, run anywhere." In my opinion, Java failed horribly on that front. This was mainly because you had to install a compatible version of the Java VM on each system. In many cases you have to install multiple different Java VMs for different Java applications. Most end users ended up having to install and maintain multiple flavors and versions of Java VMs. Often when installing a Java application you ended up installing the entire compatible VM along side it just to ensure it would run. Interestingly, where Java succeeded most is where the VM could be locked down to a specific, known flavor and version; like servers, embedded, Android, etc. If WASM is going to succeed, it absolutely MUST avoid that kind of fragmentation. It HAS to be the case that if you compile to WASM, it just works on every system. There does seem to be some hope for WASM. I'm crossing my fingers.
To add to your point - the JVM is really "heavy" both in terms of resource/performance overhead and in how it forces developers into a certain ecosystem. Initially this was the Java language, but even as more JVM languages were created, developers were still forced to use GC and other things the JVM included. Because WASM is not opinionated like the JVM was - ie it doesn't force you into a specific memory management model - it seems like this allows the runtimes to be lighter weight and thus hopefully be less prone to the fragmentation you're referring to Time will tell!
That is only partly true, JVM bytecode is ALWAYS upwards compatible, so if you run the latest Java (18 for example), you could run a Java 8 program just fine. The only problem would be internal APIs from com.sun packages or the like, which may have been deprecated/removed in newer versions.
Java has been providing backward compatibility. So at least by Java 8, newer version of JVM run any kind of older bytecode without problems. Since Java 9, Due to adoption of the module system, some legacy bytecode doesn't work with Java 9+. This is the one of the reason why couple of project still prefer Java 8 over Java 11+.
@@KitsuneAlex machine code will be always be upwards compactible too, given all the instructions are always available or in wasm's case it is proven to be possible to at least simulate the instruction. btw most of the time library/ os compactibility is the breaking point for most software instead of the language's
Wasm is a big step forward in the browser and extremely promising for servers but I don't think the docker comparison fully holds up. While wasm performance can be impressive, it is still noticeably slower than native code executed through docker. The sandboxing features in docker are supported by linux kernel features and run the actual CPU bound code with fully native performance. Nonetheless wasm is a pretty darn exciting technology
Great point about performance - has someone done benchmarks that we can take a look at? Docker is amazing, but I think it does add a bit of friction into the development process in that you have to think about a Dockerfile, creating an optimal image without too many extraneous binaries, and make building that container part of your dev process. Not a huge deal, but the idea that WASM might negate the need for all of that is interesting.
@@codetothemoon I am doing a research on that! To be honest, I am quite impressed by the performance of Web Assembly: it sometimes is as fast as containers (secure ones at least)! To explain a little better, SECCOMP can reduce performance by a lot in conatainers!
@@codetothemoon I don't know much about Wasm but I fail to see the comparison too, except they both offer a sandbox. Docker offers a native environment, if Wasm had to do that it would require an extra layer of OS in each package, making them huge and requiring a lot of JIT compilation. They're just operating at different levels.
Amazing tutorial, WASM just seems like "better" java (java *can* self optimize at runtime and get crazy performance, WASM would not). Not sure if it would replace docker for most of my uses though, unless I start running hardened kernels👍 Sure do love how docker makes an isolated virtual filesystem
This is really cool. I think the whole WASM ecosystem is going to be huge. One issue I see with it though is that for example in NPM, pretty much every package is in javascript. This allows for things like tree-shaking. If every WASM package is basically machine-code, that means multiple packages that have the same dependencies may not be able to use the same binary, or if they do there will be a lot of complex inter-weaving of communication between threads that will slow down the application. I wonder how they've solved the problems that arise from the dependency tree given that.
Nice, yeah I think it shows incredible promise. I haven't dealt too much with dependency resolution in the WASM world, but I *think* all WASM-based libraries would be statically linked and invoked in their own sandbox, such that we don't have to worry about dependency conflicts when leveraging them. Not 100% sure on this though.
Good point, although i assume tree shaking is less of an issue with wasm than with js due to smaller resulting packages (depending on compiler and config, of course). But you’re right that tree shaking would be very hard on the wasm level. The compiler could by recompiling your project and all its deps from source.
Right on. If there's one thing that beats Node.js, Java, Docker, .NET, WASM/WASI etc. in terms of being cross-platform and cross-architecture (not to mention being around longer), it's got to be dependency (hell) management. Regardless of whether one's dealing with DLLs, JARs, NPM packages, the issue pointed out by Peter always comes up. I suppose the people behind WASM/WASI are aware and probably have considered some solutions (mitigations might be a more appropriate term) but I guess a "perfect" alternative is either impossible of very hard to achieve. When possible, statically linking dependencies is a simple and effective solution. It doesn't really solve the dependency version conflict issue; instead, it forces you to deal with it beforehand.
Why did it take me almost 5 years to learn that web assembly does more than hasten the imminent demise of JS??? THANK YOU for sharing this, I can't even imagine all the possibilities this opens up for me! I'm about to finish a step in my project, and the next step is all about how to get a national network of bots running programs in various languages on various versions of Android with different versions of different locally stored packages (there are algorithms that analyze your packages and various other details of your device to "fingerprint" you in case you try to value your privacy and hide your personal data) to do what I want them to do, never fail, and if they do fail they still need to be reachable and thereby fixable. I wasn't sure how to go about that, but I figured I'd either need a custom package manager (I really DID NOT want to make that) or a controller that handles multiple package managers. This. Is. A. Godsend.. Thank you.
Looked at the title and thumbnail and thought "what the hell for?!?!" Watched the video and thought "Hmmmm.... this sounds like an interesting idea". It's funny how Java started as a cool new browser technology and eventually found a home on the server, and now WASM is following that path again.
Nice! Glad it evoked and subsequently satisfied that curiosity. It's true that server side WASM feels a bit like a less opinionated version of what Java was trying to achieve way back when.
@@codetothemoon it's becoming a really nice language. TypeScript on steroids with specialized extensions for WASM. Even things like external refs, ref types, pointers, sized integer types and even threads :)
semi-unrelated, but one thing I don't understand about new package managers - why don't they use (something like) IPFS. It seems so well suited for exactly packages. - less traffic for servers, deduplication, ease of sharing, more robust ... and it's all publicly available stuff...
"tea" is doing this (made by creator of homebrew). the project is also trying to enable funding of open-source software (even the packages buried under layers of dependencies!)
Thanks Adam - I agree, I feel like operating system level support for some kind of isolated container (maybe a WASM runtime) is something we might see in due time...
I would appreciate a curated list of sources in the description, so the viewer can have a looksie for themselves. Like where did you get the information about wapm from? Not just the homepage and a link to the docs. That would be awesome :3 Thanks in advance
Unfortunately I don't have much of a list, my resources were strictly the WAPM documentation as well as direct conversations with the Wasmer folks. They are very responsive on their Discord server, I'm sure they would be happy to help with any questions!
i think it will not replace docker is webassembly support running operating system like in docker in docker you can run almost anything safely including operating systems without conflicting on dependencies or libraries in docker image you can install ubuntu or centos
the nice thing about wasm is that the developer doesn't have to worry about operating system at all, as they do with Docker. I think most developers deal with operating system in a Docker context out of necessity, not because it is actually relevant to their application. So it winds up being more "boilerplate" configuration and setup that isn't really specific to the application being built.
I am skeptical. I do not see a compelling reason to move from containers, or to stop building native apps that run in containers. The promise of library interop is much more complicated than it is presented here. Just because a library built in another language can link into any other WASM binary, that doesn’t make them compatible. Different languages use different data structures, memory layouts, runtimes, and conventions. Unless WASI solves that issue, what we are really getting here is the ability to compile code that could be run natively to bytecode, then run less efficiently under WASM than it could when compiled natively and hosted in a container. Node/deno/bun solve a problem: Enable web technologies to be run outside the browser. WASM was created to enable “compiled” languages to run in the browser. But here there is no browser. That code could just be run natively.
I get your point, but containers are not the answer to everything either- though they are a wonderful thing. I cannot see how efficiency is higher with a container, than it is with WASM though.. If I want to run a Docker container, I have to have the Docker daemon running, download (or build) the image & create, then start the container. The container is a virtual environment, are we expecting bare metal performance? For WASM I can download (or build) the WASM file & run it. The other bonus is that I don't need to care about whether my Docker base OS image is up to date, it isn't needed. Not saying you are wrong, as I certainly haven't benchmarked them as a comparison, but perhaps the comparison you are looking at isn't really the reason for or against either, it just depends on the requirement for your tasks.
@@everyhandletaken Docker is not a virtualized environment. Containers use kernel namespacing to isolate processes and IO, but there is no virtualization occurring. For the most part, native code running in a container is bare metal. When processes under docket make system calls, those calls are intercepted and handled differently than calls from processes running outside containers, which does add some overhead. The overhead is minimal, and WASM environments will have their own overhead when making calls from the sandbox.
In a sense. The big differences are (1) that the JVM imposes a bunch of things on the application like a memory management scheme (garbage collection), and (2) it assumes that applications should be given full access to the host system. WASM resolves both of these issues.
comparing wasm with docker looks weird for me. they both provide isolation but on different level. it is possible that people will use wasm with docker.
They both aim to address the same problems, which are code portability and the "sandboxing" of untrusted code. The means by which they achieve these things is quite different, which is why WASI is so interesting. Docker seems like it would be unnecessary overhead for some WASI applications, as it's kind of a sandbox within a sandbox - but maybe there is a valid use case for that.
WasmEdge looks interesting! Mixed with CRI-O + Kubernetes for Stateless? Could be a great setup. I don't get much time to toy with those kinds of things anymore, though, unfortunately. Otherwise, I would!
Sort of - instead of "no gc" I would say "leaves memory management strategy up to the application". I'd also add that applications are run in a "sandbox" environment, where privileges have to be explicitly enabled, as opposed to the JVM which by default doesn't impose any restrictions.
Kubernetes is the king. Anything else is "too little, too late." All the major companies are backing Kubernetes and it has been involved DEEP AND WIDE in many corporations' server infrastructures.
@@codetothemoon It's mostly about IO (the lack of it) . Last time I tried wasi is still a pain in the ass for socket and file system. In order to migrate my Rust web apps to it I basically have to write a custom IO reactor for it. And it still ends up not working like I want it to be. If you look at the Rust ecosystem stuff like tokio and async-std still have no target for wasi yet.
@@everestshadow yeah those things are definitely big issues. still in the very early days like you said, it'll be interesting to see how things evolve.
“If web assembly existed in 2008 we wouldn’t have had to make Docker” Ummmm… no. Containers have many use cases and the majority of them are outside of the use cases for web assembly.
its infuriating how many pitfalls and headaches we could have avoided if we only adopted new technologies, I hate how strong money is involved as a barrier for these..
Yeah it's frustrating sometimes how hard it is to move from established systems and processes to newer ones, even in the case where they are clearly better
Docker became popular because it allowed running single-threaded Node apps as if they were separate systems, which pushed complexity onto the load-balancer/reverse proxy ... and it made life miserable for backend programmers if the authors of Docker support web assembly on the server then I'll skip it
Docker definitely adds a bit of friction to development, but man the portability it enables is pretty awesome. I think WASM-based platform would facilitate the same portability but with much less friction...
while it is obviously nice to get stuff running in the browser in a performant way, it's not the smartest idea on the server. depending on your language of course. a native rust binary will run quite a bit faster than a wasm package. why exactly would you throw away the extra performance when you have 1:1 the same development effort? to avoid packaging a little OS stub in docker? oh stop it. it's a few MB if you take alpine. even if it was a GB, i'd happily package it if it gives a 50% speed improvement over wasm. of course, "we" still had created docker, even if wasm was around 10 years before. how exactly are you going to package let's say postgresql otherwise? port it to wasm? that is nonsense. same for that idea of "all developers love each other and work together on a crypto lib, giving up their own ecosystem". hahahaha. sounds a bit like communism to me. that one did not work out. neither will this. obviously, in an ideal world, you are right. but this is not how humans work.
You blew my mind with that point of defragging the open-source library space. Huge boon for WASI
This is what hypes me up the most about this project honnestly. The idea of having language agnostic librairies is incredible.
indeed! it's crazy how many projects that essentially do the same thing are being built and maintained in parallel, just because of language boundaries
also abstracts away hardware, enabling platform agnostic code, which along with not having to fiddle around with platform-specific code for each platform, could enable us to break free from archaic operating systems and create a new one from scratch, as long as the new OS supports WASM
also, it can allow for a programming language renaissance bc as long as you support WASM, you can ignore the number one thing (imo) that holds back programming languages, which is lack of libraries
@@yes-vy6bn The Gary Bernhardt talk The Birth and Death of Javascript is along these lines, worth a watch if you haven't seen it.
I can't help but be reminded of Java's promise of "Write once, run anywhere." In my opinion, Java failed horribly on that front. This was mainly because you had to install a compatible version of the Java VM on each system. In many cases you have to install multiple different Java VMs for different Java applications. Most end users ended up having to install and maintain multiple flavors and versions of Java VMs. Often when installing a Java application you ended up installing the entire compatible VM along side it just to ensure it would run.
Interestingly, where Java succeeded most is where the VM could be locked down to a specific, known flavor and version; like servers, embedded, Android, etc.
If WASM is going to succeed, it absolutely MUST avoid that kind of fragmentation. It HAS to be the case that if you compile to WASM, it just works on every system. There does seem to be some hope for WASM. I'm crossing my fingers.
To add to your point - the JVM is really "heavy" both in terms of resource/performance overhead and in how it forces developers into a certain ecosystem. Initially this was the Java language, but even as more JVM languages were created, developers were still forced to use GC and other things the JVM included.
Because WASM is not opinionated like the JVM was - ie it doesn't force you into a specific memory management model - it seems like this allows the runtimes to be lighter weight and thus hopefully be less prone to the fragmentation you're referring to
Time will tell!
yes java can but the performance can't compare with rust
That is only partly true, JVM bytecode is ALWAYS upwards compatible, so if you run the latest Java (18 for example), you could run a Java 8 program just fine. The only problem would be internal APIs from com.sun packages or the like, which may have been deprecated/removed in newer versions.
Java has been providing backward compatibility. So at least by Java 8, newer version of JVM run any kind of older bytecode without problems. Since Java 9, Due to adoption of the module system, some legacy bytecode doesn't work with Java 9+. This is the one of the reason why couple of project still prefer Java 8 over Java 11+.
@@KitsuneAlex machine code will be always be upwards compactible too, given all the instructions are always available or in wasm's case it is proven to be possible to at least simulate the instruction. btw most of the time library/ os compactibility is the breaking point for most software instead of the language's
Wasm is a big step forward in the browser and extremely promising for servers but I don't think the docker comparison fully holds up. While wasm performance can be impressive, it is still noticeably slower than native code executed through docker. The sandboxing features in docker are supported by linux kernel features and run the actual CPU bound code with fully native performance.
Nonetheless wasm is a pretty darn exciting technology
Great point about performance - has someone done benchmarks that we can take a look at? Docker is amazing, but I think it does add a bit of friction into the development process in that you have to think about a Dockerfile, creating an optimal image without too many extraneous binaries, and make building that container part of your dev process. Not a huge deal, but the idea that WASM might negate the need for all of that is interesting.
wasm is still evolving. It takes a bit of time for a new technology to catch up.
@@codetothemoon I am doing a research on that!
To be honest, I am quite impressed by the performance of Web Assembly: it sometimes is as fast as containers (secure ones at least)!
To explain a little better, SECCOMP can reduce performance by a lot in conatainers!
@@codetothemoon I don't know much about Wasm but I fail to see the comparison too, except they both offer a sandbox. Docker offers a native environment, if Wasm had to do that it would require an extra layer of OS in each package, making them huge and requiring a lot of JIT compilation. They're just operating at different levels.
Wasm will be v3 of containers over time.
THE VIDEO I WAITED FOR!
WASM on the server looks so interesting 🤩♥️
Thanks, and I agree!
Hi, very interesting! I think it could easily replace any app store on mobile devices. Potential is huge!
Wow, that's true! I hadn't thought of that!
One can only hope.
Thank you for wasi intro.
I’ve heard of it but never thought it could or should run on servers.
Exciting time indeed…
Thanks for watching! Wasmer is very active in development and may have more tricks up their sleeve, stay tuned for that...
In the first few seconds I was thinking fad, but by the end I started realising the potential... Will be keeping an eye out
Yeah it'll be interesting to see where developers take this!
Amazing tutorial, WASM just seems like "better" java (java *can* self optimize at runtime and get crazy performance, WASM would not). Not sure if it would replace docker for most of my uses though, unless I start running hardened kernels👍 Sure do love how docker makes an isolated virtual filesystem
thanks! yeah we'll see how things play out, Docker is awesome but it'd be nice to have OS completely abstracted away from the build/deployment process
There are JIT interpreters for WASM. It'll get there. It's a newborn baby compared to old man Java
WasmEdge anyone?
Great content, this is California before the gold rush
Thanks Cameron! It might be!
This is really cool. I think the whole WASM ecosystem is going to be huge. One issue I see with it though is that for example in NPM, pretty much every package is in javascript. This allows for things like tree-shaking. If every WASM package is basically machine-code, that means multiple packages that have the same dependencies may not be able to use the same binary, or if they do there will be a lot of complex inter-weaving of communication between threads that will slow down the application. I wonder how they've solved the problems that arise from the dependency tree given that.
Nice, yeah I think it shows incredible promise. I haven't dealt too much with dependency resolution in the WASM world, but I *think* all WASM-based libraries would be statically linked and invoked in their own sandbox, such that we don't have to worry about dependency conflicts when leveraging them. Not 100% sure on this though.
Good point, although i assume tree shaking is less of an issue with wasm than with js due to smaller resulting packages (depending on compiler and config, of course). But you’re right that tree shaking would be very hard on the wasm level. The compiler could by recompiling your project and all its deps from source.
Right on. If there's one thing that beats Node.js, Java, Docker, .NET, WASM/WASI etc. in terms of being cross-platform and cross-architecture (not to mention being around longer), it's got to be dependency (hell) management. Regardless of whether one's dealing with DLLs, JARs, NPM packages, the issue pointed out by Peter always comes up. I suppose the people behind WASM/WASI are aware and probably have considered some solutions (mitigations might be a more appropriate term) but I guess a "perfect" alternative is either impossible of very hard to achieve. When possible, statically linking dependencies is a simple and effective solution. It doesn't really solve the dependency version conflict issue; instead, it forces you to deal with it beforehand.
Hi, thanks for the video. It's brief and helpful. Can you please make a video about how to send HTTP requests from WASM and WASI.
thanks, glad you found it valuable! I do plan to look into that space, maybe with Cloudflare workers which now seem to support WASM...
Awesome debrief of scope big hug from Australia
Thanks mate!
Why did it take me almost 5 years to learn that web assembly does more than hasten the imminent demise of JS??? THANK YOU for sharing this, I can't even imagine all the possibilities this opens up for me!
I'm about to finish a step in my project, and the next step is all about how to get a national network of bots running programs in various languages on various versions of Android with different versions of different locally stored packages (there are algorithms that analyze your packages and various other details of your device to "fingerprint" you in case you try to value your privacy and hide your personal data) to do what I want them to do, never fail, and if they do fail they still need to be reachable and thereby fixable.
I wasn't sure how to go about that, but I figured I'd either need a custom package manager (I really DID NOT want to make that) or a controller that handles multiple package managers.
This. Is. A. Godsend..
Thank you.
Nice Greg, glad this might be part of the solution to your problem!
Looked at the title and thumbnail and thought "what the hell for?!?!" Watched the video and thought "Hmmmm.... this sounds like an interesting idea".
It's funny how Java started as a cool new browser technology and eventually found a home on the server, and now WASM is following that path again.
Nice! Glad it evoked and subsequently satisfied that curiosity. It's true that server side WASM feels a bit like a less opinionated version of what Java was trying to achieve way back when.
I just recently adopted AssemblyScript into my collective's ecosystem, and it's been a pleassure working with WASM. This stuff is the future.
nice, I haven't actually tried AssemblyScript yet - seems interesting.
@@codetothemoon it's becoming a really nice language. TypeScript on steroids with specialized extensions for WASM. Even things like external refs, ref types, pointers, sized integer types and even threads :)
semi-unrelated, but one thing I don't understand about new package managers - why don't they use (something like) IPFS. It seems so well suited for exactly packages.
- less traffic for servers, deduplication, ease of sharing, more robust ... and it's all publicly available stuff...
"tea" is doing this (made by creator of homebrew). the project is also trying to enable funding of open-source software (even the packages buried under layers of dependencies!)
Running the binaries in the browser kinda blew my mind. It reduces the friction of testing a package massively.
This is awesome. I wonder if there will be an OS developed around it.
Thanks Adam - I agree, I feel like operating system level support for some kind of isolated container (maybe a WASM runtime) is something we might see in due time...
I would appreciate a curated list of sources in the description, so the viewer can have a looksie for themselves. Like where did you get the information about wapm from? Not just the homepage and a link to the docs. That would be awesome :3
Thanks in advance
Unfortunately I don't have much of a list, my resources were strictly the WAPM documentation as well as direct conversations with the Wasmer folks. They are very responsive on their Discord server, I'm sure they would be happy to help with any questions!
Fascinating and exciting!
I agree! I believe they've innovated quite a bit more since I made this video, possibly more on that in a future video...
i think it will not replace docker
is webassembly support running operating system like in docker
in docker you can run almost anything safely including operating systems without conflicting on dependencies or libraries
in docker image you can install ubuntu or centos
the nice thing about wasm is that the developer doesn't have to worry about operating system at all, as they do with Docker. I think most developers deal with operating system in a Docker context out of necessity, not because it is actually relevant to their application. So it winds up being more "boilerplate" configuration and setup that isn't really specific to the application being built.
I see a lot of promise in WASMER. What is needed is an orchestration system, and some proven distributed systems in WASM
what do you mean by orchestration system?
Some feedback I would give for WAPM: it’s confusing how you can use libraries
how so?
@@codetothemoon no examples on how you can use them and when you select “libraries” in the search, then no packages show up at all
Very interesting!
I agree!
Great video.Thank you a lot
thanks for watching!!
Wasm never ceases to flabbergast me
Same!
Great tutorial!!
Thanks, glad you liked it!
Thanks a lot!
thanks for watching!
12:40 how does this cross language library usage work? Are there any good examples of this?
new video on this very topic coming soon, stay tuned!
There's no end to this shit.
Cut back on the fiber maybe?
I am skeptical. I do not see a compelling reason to move from containers, or to stop building native apps that run in containers. The promise of library interop is much more complicated than it is presented here. Just because a library built in another language can link into any other WASM binary, that doesn’t make them compatible. Different languages use different data structures, memory layouts, runtimes, and conventions. Unless WASI solves that issue, what we are really getting here is the ability to compile code that could be run natively to bytecode, then run less efficiently under WASM than it could when compiled natively and hosted in a container. Node/deno/bun solve a problem: Enable web technologies to be run outside the browser. WASM was created to enable “compiled” languages to run in the browser. But here there is no browser. That code could just be run natively.
I get your point, but containers are not the answer to everything either- though they are a wonderful thing.
I cannot see how efficiency is higher with a container, than it is with WASM though..
If I want to run a Docker container, I have to have the Docker daemon running, download (or build) the image & create, then start the container. The container is a virtual environment, are we expecting bare metal performance?
For WASM I can download (or build) the WASM file & run it.
The other bonus is that I don't need to care about whether my Docker base OS image is up to date, it isn't needed.
Not saying you are wrong, as I certainly haven't benchmarked them as a comparison, but perhaps the comparison you are looking at isn't really the reason for or against either, it just depends on the requirement for your tasks.
@@everyhandletaken Docker is not a virtualized environment. Containers use kernel namespacing to isolate processes and IO, but there is no virtualization occurring. For the most part, native code running in a container is bare metal. When processes under docket make system calls, those calls are intercepted and handled differently than calls from processes running outside containers, which does add some overhead. The overhead is minimal, and WASM environments will have their own overhead when making calls from the sandbox.
era of union!
😎
Is it possible to create a web assembly app that runs in the browser that calls native swift macOS frameworks?
Unfortunately I don't think so, as far as I know (I could be wrong!)
look for Colin Breck's latest posts on Web Assembly, WA is very promising for IoT
will have a look thanks for the tip!
Isn't what exactly the JVM was for?
In a sense. The big differences are (1) that the JVM imposes a bunch of things on the application like a memory management scheme (garbage collection), and (2) it assumes that applications should be given full access to the host system. WASM resolves both of these issues.
comparing wasm with docker looks weird for me. they both provide isolation but on different level. it is possible that people will use wasm with docker.
They both aim to address the same problems, which are code portability and the "sandboxing" of untrusted code. The means by which they achieve these things is quite different, which is why WASI is so interesting. Docker seems like it would be unnecessary overhead for some WASI applications, as it's kind of a sandbox within a sandbox - but maybe there is a valid use case for that.
like using jvm inside docker?
WasmEdge looks interesting! Mixed with CRI-O + Kubernetes for Stateless? Could be a great setup. I don't get much time to toy with those kinds of things anymore, though, unfortunately. Otherwise, I would!
Took a quick look, it does look pretty interesting. How do you think it compares to Wasmer? Is the Kubernetes support a game changer for you?
It's like java bytecode with a more minimal runtime and no gc, right?
Sort of - instead of "no gc" I would say "leaves memory management strategy up to the application". I'd also add that applications are run in a "sandbox" environment, where privileges have to be explicitly enabled, as opposed to the JVM which by default doesn't impose any restrictions.
i noticed most of the tutorials like this
do we need mac to program?
i dont have alot of money
No need to use a mac, Wasmer works on all of the major platforms!
No, macs just seem to be the most popular dev machines.
Is it possible to write a Desktop Environment in wasm? Like gnome or kde.
It is interesting..
Please keep making such videos frequently..
Thanks Vivek! Will do!
Kubernetes is the king. Anything else is "too little, too late." All the major companies are backing Kubernetes and it has been involved DEEP AND WIDE in many corporations' server infrastructures.
That is fine for the corporate space, but it is incredibly complex & WASM fits into quite a different category IMO.
Sounds like Silverlight or Flash plugins for the browser..
Flash on the server! That would be something 🙃
LOL No. At least not in 5 years. I have finished multiple projects required to have a feature for wasm and it sucks.
Client side WASM or server side WASM? What sucked about it?
@@codetothemoon It's mostly about IO (the lack of it) . Last time I tried wasi is still a pain in the ass for socket and file system. In order to migrate my Rust web apps to it I basically have to write a custom IO reactor for it. And it still ends up not working like I want it to be. If you look at the Rust ecosystem stuff like tokio and async-std still have no target for wasi yet.
@@everestshadow yeah those things are definitely big issues. still in the very early days like you said, it'll be interesting to see how things evolve.
“If web assembly existed in 2008 we wouldn’t have had to make Docker”
Ummmm… no. Containers have many use cases and the majority of them are outside of the use cases for web assembly.
Which these use cases are outside the capabilities of a wasm sandbox?
@@codetothemoon looks like he is still thinking about an answer to this lol
its infuriating how many pitfalls and headaches we could have avoided if we only adopted new technologies, I hate how strong money is involved as a barrier for these..
Yeah it's frustrating sometimes how hard it is to move from established systems and processes to newer ones, even in the case where they are clearly better
BLAZOR
I’ve heard good things about it, what’s been your experience?
Docker became popular because it allowed running single-threaded Node apps as if they were separate systems, which pushed complexity onto the load-balancer/reverse proxy ... and it made life miserable for backend programmers
if the authors of Docker support web assembly on the server then I'll skip it
Docker definitely adds a bit of friction to development, but man the portability it enables is pretty awesome. I think WASM-based platform would facilitate the same portability but with much less friction...
Why would you do this 😭
Because portability! 🎉
@@codetothemoon Why? Because I can!^^
while it is obviously nice to get stuff running in the browser in a performant way, it's not the smartest idea on the server. depending on your language of course. a native rust binary will run quite a bit faster than a wasm package. why exactly would you throw away the extra performance when you have 1:1 the same development effort? to avoid packaging a little OS stub in docker? oh stop it. it's a few MB if you take alpine. even if it was a GB, i'd happily package it if it gives a 50% speed improvement over wasm. of course, "we" still had created docker, even if wasm was around 10 years before. how exactly are you going to package let's say postgresql otherwise? port it to wasm? that is nonsense. same for that idea of "all developers love each other and work together on a crypto lib, giving up their own ecosystem". hahahaha. sounds a bit like communism to me. that one did not work out. neither will this. obviously, in an ideal world, you are right. but this is not how humans work.
0:38 No DO_SOMETHING_BAD. I love the safety considerations a few secs before running a curl… | sh.
lol yeah
#amflearningbydoing #amflearning nice
nice!