3 ms·

I'm guessing (it appears to be true) that every single one of the people writing about their issues here (1) didn't try Spin, because (2) they're intent on targ

by yebyen 3y ago

I'm guessing (it appears to be true) that every single one of the people writing about their issues here (1) didn't try Spin, because (2) they're intent on targeting a web browser as a runtime environment, and (3) Spin does not run there. The DX in Wasm is pretty complicated, but it gets a lot better IMO through Spin. But that was a marketing name and a campaign that worked apparently too well. I try to think of it as a naming failure, and tell everyone I can that Wasm isn't for web browsers. I mean, it can run in a web browser, sure, but if what you're building is a server, the chances that you're going to want to run it in a web browser in the end are practically nil, aren't they? (I guess for the author, that wasn't exactly true.) And everyone I know is building servers, or something like a component that should sit behind a server, or libraries for command line. Nobody I know is building flash games, or planning on extracting compute out of their users who arrive via web-browser, none of our code needs to run in the browser sandbox, and nobody I know would pick up Wasm for that reason (unless by some fluke they really needed to do that, and it was the thing they had been told that Wasm was supposed to do. Which many people apparently have been told by now!) It is for sure a thing that has been promised (Wasm is for web browsers) and must be delivered, but I don't think it's where the implementation of Wasm is going to take off right now. I think people need to take their server-side apps and achieve those 1000x performance gains that have been promised, reshape their runtime profiles to be serverless-capable as it's done with the Spin runtime, and then I really do think things will start to improve for the rest of us as the tooling matures. If you spend a lot of money on servers and you can spend less money on servers by making them start up very quickly, and shutting them down when they're not actively serving requests, then you can save a lot of money. That's the story that Spin is telling, and that's where I expect to see the movement happening at first, especially if we are heading into a recession as has been predicted by almost everybody. If you are spending money on waste, now is a great time to try and cut it out. Web Assembly has great potential to help with this.

josteink 3y ago
> I mean, it can run in a web browser, sure, but if what you're building is a server, the chances that you're going to want to run it in a web browser in the end are practically nil, aren't they? We’ve been able to compile almost any language to native code runnable on a server for several decades. That problem is solved. We don’t need any new tech here. The big thing about WebAssembly was that it promised us the ability to do that in the browser too, where we until recently were cursed with JavaScript as our only option to run code. So yes. People intend to use WebAssembly in the browser. For many people that is its primary and only use-case.
- yebyen 3y ago
  > That problem is solved. We don’t need any new tech here. Solved by who exactly? You can't tell me with a straight face if I can show you a way that you can spend 1/100 of what you currently do on servers that run full-time by changing the architecture into a serverless one, with web assembly providing the faster startup times required to make it perform acceptably, that you're not interested in saving that money. Performance is always a goal. Anyone that tells you performance is a solved problem is lying. But perhaps we've heard "serverless is going to save you" one too many times from AWS and friends, and now we don't want to hear it anymore. News flash, AWS and Azure both want to sell you more servers. So they cloud providers are all not going to seriously invest in serverless. It's not a solved problem at all. They'd all love it if serverless was an abominable failure altogether. Which is how I'll bet you actually perceive all that mess, am I right? Give me more servers, they actually fucking work. The goal for me has never been to run code in web browsers. It has always been to write code in whatever language suits me, and run it wherever, especially libraries for reuse. To avoid rewriting the same code over and over. I never pick the browser as a target, because it puts so many things irredeemably outside of my control (which it must, because it's not my machine.)

by yebyen 3y ago

josteink 3y ago

> I mean, it can run in a web browser, sure, but if what you're building is a server, the chances that you're going to want to run it in a web browser in the end are practically nil, aren't they? We’ve been able to compile almost any language to native code runnable on a server for several decades. That problem is solved. We don’t need any new tech here. The big thing about WebAssembly was that it promised us the ability to do that in the browser too, where we until recently were cursed with JavaScript as our only option to run code. So yes. People intend to use WebAssembly in the browser. For many people that is its primary and only use-case.

yebyen 3y ago
> That problem is solved. We don’t need any new tech here. Solved by who exactly? You can't tell me with a straight face if I can show you a way that you can spend 1/100 of what you currently do on servers that run full-time by changing the architecture into a serverless one, with web assembly providing the faster startup times required to make it perform acceptably, that you're not interested in saving that money. Performance is always a goal. Anyone that tells you performance is a solved problem is lying. But perhaps we've heard "serverless is going to save you" one too many times from AWS and friends, and now we don't want to hear it anymore. News flash, AWS and Azure both want to sell you more servers. So they cloud providers are all not going to seriously invest in serverless. It's not a solved problem at all. They'd all love it if serverless was an abominable failure altogether. Which is how I'll bet you actually perceive all that mess, am I right? Give me more servers, they actually fucking work. The goal for me has never been to run code in web browsers. It has always been to write code in whatever language suits me, and run it wherever, especially libraries for reuse. To avoid rewriting the same code over and over. I never pick the browser as a target, because it puts so many things irredeemably outside of my control (which it must, because it's not my machine.)