Hacker News new | ask | show | jobs
by notheguyouthink 2895 days ago
Yes.. sort of. For that scenario, we need a lot of things in place that are down the road for WASM. Technically it would work today, but you'd have to ship a Python runtime with every "app". That's a lot of overhead, so much so that it's basically a non-starter for many people.

In the future it may work, because a built in GC is on the roadmap for WASM. Unfortunately I'm not sure that it will work great for most scenarios. For example, Go(lang) ships with its own GC which is very tailored to its use case. Defaulting to a WASM GC could work, in theory, but would it impose difficulties such as unexpected performance characteristics with longer GC pauses or whatever?

There's a lot of edge cases that will have to be covered for this stuff to work instead. Perhaps shared WASM binaries would be the best solution, allowing runtimes to be offloaded and cached regardless of user land code running.

2 comments

When many websites are already shipping down megs of crap, I don't think the few extra megs of a python runtime would matter that much to the end user, especially if it's cached. Especially if it's marked by the browser as cross-site 'cached' (perhaps by verifying a signature and installing it as a plugin) so it's only done once per version. You can go further with more browser support, for instance browsers could bundle popular runtimes with their own distribution (Chrome + Flash).
> Especially if it's marked by the browser as cross-site 'cached'

That runs into the problems that have generally prevented browsers from cross-site caching common scripts already.

I feel like browsers would just cache these runtimes like they do with many js libraries so it wouldn't be a problem.

I am really excited at the prospect of writing my front and backend in a sane language like C# or kotlin.

Well yea, that's what I said. If WASM shared libs works, then we can cache runtimes, that's why I said it's the best solution. However shipping runtimes with user code, means it's basically not cache-able in a generic, multi-app sense.