19:05 <kentonv> so on the sandstorm.io / capnproto.org / alpha server (they're all backed by one machine...), I just replaced nginx with the soon-to-be-open-source Cloudflare Workers Runtime

19:36 <ocdtrekkie> neat!

21:41 <kentonv> everything seems to be going well, so it's now permanent

22:15 <ocdtrekkie> Does that open up anything for the future or any expected benefit? Future with less Google?

22:55 <kentonv> ocdtrekkie, not really. It just means I replaced a bunch of nginx config with JavaScript. Maybe that logic could run in Cloudflare now, but alpha.sandstorm.io itself is going to keep needing a VM...

22:56 <kentonv> open sourcing the runtime, though, could be interesting for Sandstorm. It'd be pretty easy to integrate the workers runtime into Sandstorm, since they are both built on Cap'n Proto / KJ. If we had a new workers-based app format, we could make grain startup time much, much faster for those apps...

23:04 <kentonv> of course... that requires apps to be written in a particular way. But given the recent convergence around JavaScript Workers as a server stack, maybe that's an easier sell then it would have been 5 years ago.

23:06 <ocdtrekkie> I mean, the best Sandstorm apps are built for Sandstorm anyways.

23:06 <kentonv> cold starts are really quite bad in Sandstorm today. :/

23:08 <ocdtrekkie> Gmail has trained users to tolerate some crazy load times.

23:08 <ocdtrekkie> I am pretty sure I can cold boot Windows 10 faster than Gmail loads now.

23:40 <isd> I think step 1 would be actually package/write some workers apps with vagrant-spk; the baseline grain startup time is Not The Bottleneck, and I expect performance would be fine without adding code to the TCB.

23:41 <kentonv> what do you mean by "not the bottleneck"?

23:42 <isd> I mean the apps where startup time is noticable, it's not spinning up a container and spawning a process that's the problem -- we have some apps that do just fine. Grains that have bad startup times it's because the framework is doing a bunch of other stuff, or they're doing a ton of disk io on startup, or...

23:43 <isd> I would love to be in a place where integrating the workers runtime into sandstorm was the low hanging fruit. I don't think that's where we are.

23:45 <kentonv> hmm... though arguably code that is designed to run on Workers is also naturally going to optimize for faster startup, since workers start on-demand

23:46 <isd> Agreed - but, as I said, step 1 would be a vagrant-spk stack. We may not even have to directly integrate the runtime to reap the benefits.