71–76 of 76 posts
Do you offer any hosted services? Spin looks amazing but I don't want to manage my own server.
what are the benchmarks?
(one of the authors of Spin here.) WIth the disclaimer that this is really early, and we don't have extensive benchmarks yet, there are a few things we are tracking for HTTP workloads (you can see the actual benchmark apps here — https://github.com/fermyon/spin/tree/main/crates/http/benche... , and the rendered results here — https://fermyon.github.io/spin-benchmarks/criterion/reports/ ): - the response times — here…
On a lighthearted unscientific note: After getting absolutely bombarded with traffic today (5-10x normal, YAY!), we noticed: - No increased latency in responding to requests - Flat memory usage at 130MB per worker (we run Nomad) - Spiky CPU traffic (which is expected when starting and stopping Wasm modules hundreds of times a second), but never really over about 60% of the CPU on a small VM size on AWS - No Wasm downtime (though we did have a non-Wasm load balancer hiccup at about peak load, cause unknown)
Earlier quoted context omitted.
But that's sort of moving the goal posts now. Original claim for WASM was that it allows hot reloading. Which is a thing you can do with DLLs just fine.
No, the original claim of Wasm definitely isn't only one side point about development. The original claim of Wasm is that all of these features are packaged in a well thought out whole + the success of this platform (thanks to browsers mostly) is what's so interesting about it.
"Hot reloading is a good example."
Again. You don't need WASM for hot reloading.
Earlier quoted context omitted.
No, the original claim of Wasm definitely isn't only one side point about development. The original claim of Wasm is that all of these features are packaged in a well thought out whole + the success of this platform (thanks to browsers mostly) is what's so interesting about it.
No, not original Claim about WASM but your original Claim that about hot reloading and WASM. "Hot reloading is a good example." Again. You don't need WASM for hot reloading.
BTW not my words.
Earlier quoted context omitted.
This is so true. I think this project feels like breathe of fresh air and also forced you to think different on how to go about building serverless stuff. Someone mentioned about carbon footprint of increase due to containerization and the kubernetes culture during discussion about dagger [1]. Cloud cost, cloud waste and climate impact of current cloud computing setups are some biggest problem of this decade that are…
Hi! (Another one of the Spin authors here) We have been talking about the efficiency/footprint thing a lot. So many things sit idle in the datacenter, consuming electricity without a good reason. WebAssembly is so fast to startup and shutdown that we think we can actually make a sizable dent into amount of compute required (and hence, amount of electricity consumed) if we can build this tooling right. Spin took a fir…
I've been excited about WebAssembly being a new back-end target when someone on HN (I forgot whom) pointed out, hey dont be fooled by the name, it's not just for browsers. I know some people will cry that it is just Java in the browser or whatever, but it really is much more than that. It is way more secure, far more minimal, and people can build their own run times for it. I am excited to see where WASI goes moving…
When I first wrote WAGI, I just wanted to show people that WebAssembly could be run efficiently on the server. Basically, like you were saying, I wanted something to demo to people and say, "Look, Wasm can do a lot more than crypto-mine in a browser tab!" Now with Spin we are able to go beyond those first assumptions made with Wagi and explore exactly how far we can push it. It has been so much fun to explore how to…