> by deploying WASM in V8 sandboxes, you get all of the developer benefits of microservices with all of the runtime benefits of monoliths
No oversimplification to see here.
WASM will replace containers
271–280 of 371 posts
Re: WASM will replace containers
#272One benefit of being an old engineer is watching how excited people get when they rediscover something that has gone around the bend over and over again. I swear if you fuckers reinvent DCOM I will shit in your hats.
I actually didn't mind COM and DCOM. I didn't overuse it, so it never bit me. I guess it's why I love using Microsoft Orleans. The virtual actor model is enough for me to solve almost every problem. If Cloudflare Durable Objects ( https://developers.cloudflare.com/durable-objects ) can reduce latency they might have the winning product.
On that note, do you mind helping me understand something I haven't been able to glean from Microsoft's docs? Does Orleans give you a way to globally address a thread?
With Durable Objects, two clients on either side of the world can both request a websocket connection to an object with the same unique identifier, and all the bytes from those clients will land in one single process somewhere inside a CloudFlare data centre.
I am pretty sure the answer is yes, but the docs seem a bit less direct than CloudFlare's web focused use cases.
Re: WASM will replace containers
#273"The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated."
Funny. The most obvious place for WASM is a web browser and yet WASM STILL cannot access the browser DOM. Its only been, what? At least 8 years of promises about it coming soon and how people are working on it.
Re: WASM will replace containers
#274[deleted]
Re: WASM will replace containers
#275"The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated." Funny. The most obvious place for WASM is a web browser and yet WASM STILL cannot access the browser DOM. Its only been, what? At least 8 years of promises about it coming soon and how people are working on it.
Who exactly has promised it's "coming soon"? People like to make arguments against imaginary arguments for some reason.
Besides, you can already send data from/to BrowserWASM context which seems to at least solve most use cases people was imagining for WebAssembly back when it was just asm.js.
Re: WASM will replace containers
#276I need contributers for this Wikipedia page - https://en.wikipedia.org/wiki/User:Dr.SeemaMidha Fellow Wikipedians may show their interest in the comment section.
How May I Help You?
Re: WASM will replace containers
#277>A very obvious argument against WASM succeeding is the Java Virtual Machine (JVM). It's almost exactly the same promise: write once, run anywhere. [...] The biggest limitation is that JVM bytecode cannot run in a web browser
The draw of WASM is to be able to have your code run in a browser tab exactly as it can run on your local hardware, as it can run if you embed it in your own application, with the only thing moving being custom syscalls between the 3
The biggest limitation of the JVM was that it's closed
You can spin up your own WASM interpreter and integrate it anywhere you like. It wouldn't be an impossible bridge to cross, it's RISC, it's open, there's many open implementations. Is it even possible to write your own JVM from scratch?
Re: WASM will replace containers
#278I need contributers for this Wikipedia page - https://en.wikipedia.org/wiki/User:Dr.SeemaMidha Fellow Wikipedians may show their interest in the comment section.
How May I Help You?
The Wiki page you want to create is disallowed by the Wiki Bots.
The exact uniform resource location of the concerned Wiki page is https://en.wikipedia.org/w/index.php?title=User:Dr.SeemaMidh...
The displayed uniform resource location of the concerned Wiki page is https://en.wikipedia.org/wiki/User:Dr.SeemaMidha
Re: WASM will replace containers
#279This webdev notion of abstracting 30 layers of complexity just to run bytecode is borderline lobotomizing and should be blamed for 8,000,000,000 Bytes of RAM not sufficing for a slightly-above-average desktop computer nowadays.
Re: WASM will replace containers
#280Unikernels were meant to take over the world, the problem is, the extra bits of faux linux that docker provides are usually time savers.
The problem with modern containers is not the container (well it kinda is) its the thing that works out how to run and connect that container.
Kubernetes is a shit to configure, insecure unless you spend effort tracing and managing permissions, expensive to run.
But it is cool.
Apart from the networking. Thats just fucking batshit.
TLDR: Containers aren't the problem its the stupid orchestration layers people insist on building.