28 ms·

What does that even mean? When I use a container, I get all the stuff a Debian distro brings: A file system Process management My favorite databas

by TekMol 3y ago

What does that even mean? When I use a container, I get all the stuff a Debian distro brings: A file system Process management My favorite database (SQLite) My favorite webserver (Apache) My favorite runtime (CPython) A gazillion helpful applications and libraries (Like imagemagick) Tons of convenience glue (like /etc/hosts) I get all of that in a reproducible, isolated little universe. How does a "WebAssembly runtime" provide me with those?

paddw 3y ago
https://wasi.dev/ https://wasi.dev/ allegedly. Development seems slow though.
dboreham 3y ago
Wait until 2030.
preseinger 3y ago
wasm doesn't give you a vm, it gives you a process
- saidinesh5 3y ago
  To be more precise, if you wanted an isolated process, docker already gives you that. Along with the overhead of spinning up a new process for every request you want to handle. What wasm people seem to be interested in is to eliminate the process (and hence a language runtime) spawning overhead, and directly execute the specific function of your application.. "Write your serverless function in any wasm compilable language and our multi tenant runtime can host 1000s of such functions and invoke them without much delay".. Of course, that only makes sense for programs which are written in wasm compilable language. When they do crazy things like running js scripts on top of a quickjs interpreter compiled to wasm to run on top of a wasm interpreter "for portability and safety", it gets weird to see the benefits..
moonchrome 3y ago
By same logic why use containers ? You can just ship VM images. It's basically the same thing as using a language runtime vs using a generic container for Lambda, except WASM would be lower level (you would need to ship language runtime on top of WASM but that's probably order of magnitude less overhead than a container) Containers feel like a clever hack to get existing apps packaged up and reduce the overhead of VMs, but I'd much rather deploy runtime/app code only.
- throwawaymaths 3y ago
  Really? VM images take longer to spin up, both at the infra level and the devex level
  - moonchrome 3y ago
    Just like docker image vs specialized language runtime ?
    - throwawaymaths 3y ago
      Sure, but for many langs hermetic config is an issue, you want to be relatively sure what your devs are building against is what gets deployed.
      - moonchrome 3y ago
        So you'll develop directly on the wasm runtime locally which should be a platform abstraction ? The way I see it VM -> Containers -> WASM is a logical progression in the same direction from the perspective of deploying applications.
        deleted 3y ago
        [deleted]
        throwawaymaths 3y ago
        I mean i don't think you get it. Wasm doesn't ship with a filesystem, POSIX support tools, etc. You only get your language runtime, so they're not comparable. Bare metal, VM, and containers all "look the same", like from a UX perspective. Wasm does not.
kevincox 3y ago
You can have all of these things on WebAssembly. You just compile them. I think the view here is WebAssembly as another architecture. Instead of compiling for x86 or ARM (or both) you just compile to WASM and it can run anywhere.
- TekMol 3y ago
  Compile what? A whole Debian distro with a Linux kernel and all 7000 packages?
  - singularity2001 3y ago
    Compile glue code to the new kids favorite web stack: Their favorite database (SQLite) Their favorite webserver (Spin) Their favorite runtime (CPython) Hopefully some imagemagic, but definitely none of the linux clutter
  - kevincox 3y ago
    Probably no kernel, but everything else.
    - drowawaygpt 3y ago
      [flagged]
    - TekMol 3y ago
      So what does "everything else" do if it has no kernel below it? What does curl do if it cannot talk to a network stack? What does "touch" do if there is no filesystem to touch? What does "dd" do if there are no block devices?
      - kevincox 3y ago
        Think of a docker container, they don't include a kernel. There is still a kernel somewhere obviously.
kortex 3y ago
I could see this greatly benefitting python in particular. Compile cpython and all the dependencies against WASM/WASI, bundle WASM wheels, and wrap the whole thing up in a single .wasm binary. Python portability woes are basically solved, provided your environment has the appropriate WASI runtime.
- TekMol 3y ago
  But my Python code does not run in a vacuum. It gets executed by Apache, writes to a file system, makes use of a gazillion of libraries and programs that come with Debian. What would the Python "requests" module do if it has no Linux kernel below it to pass the requests to a network stack?
  - kortex 3y ago
    Your python code is executed by Apache? You mean like WSGI? Well either way, the bytecode alliance is working on things like fork/exec. > What would the Python "requests" module do if it has no Linux kernel below it to pass the requests to a network stack? Why does requests need a linux kernel? It's cross-platform. Strictly speaking it only needs the appropriate I/O calls. WASI provides a system interface to do I/O, network, files, etc. https://wasi.dev/ https://wasi.dev/ https://github.com/WebAssembly/wasi-sockets https://github.com/WebAssembly/wasi-sockets
- mike_hearn 3y ago
  Ironically this is solved already by the latest release of Graal, one of WASM's competitors: https://medium.com/graalvm/whats-new-in-graalvm-languages-161527df3d76With https://medium.com/graalvm/whats-new-in-graalvm-languages-16... You can now distribute Python applications or libraries as standalone binaries or JAR files without any external dependencies. The Truffle framework on which GraalPy is built, and the Sulong LLVM runtime that GraalPy leverages for managed execution of Python’s native extensions, enable virtualization of all filesystem access of Python applications, including those to the standard library and installed packages. So now you can build a standalone executable as follows: graalpy -m standalone binary - module my_script.py - output my_binary or a JAR file that runs on GraalVM and includes GraalPy as follows: graalpy -m standalone java - output-directory MyJavaApplication - module my_script.py The first form creates a fast starting native binary. The second is a portable bytecode standalone file. So this WASM dream is delivered already, just by a different group of people. Now, GraalPy is a different implementation to CPython so not all Python apps run on it yet. But obviously any WASMPy would have the same issue.
ape4 3y ago
The trend is to put more and more things into browsers and presumably WASM will have access to all that. But, yah, seems like a long way off.

by TekMol 3y ago

paddw 3y ago

https://wasi.dev/ https://wasi.dev/ allegedly. Development seems slow though.

dboreham 3y ago

Wait until 2030.

preseinger 3y ago

wasm doesn't give you a vm, it gives you a process

saidinesh5 3y ago
To be more precise, if you wanted an isolated process, docker already gives you that. Along with the overhead of spinning up a new process for every request you want to handle. What wasm people seem to be interested in is to eliminate the process (and hence a language runtime) spawning overhead, and directly execute the specific function of your application.. "Write your serverless function in any wasm compilable language and our multi tenant runtime can host 1000s of such functions and invoke them without much delay".. Of course, that only makes sense for programs which are written in wasm compilable language. When they do crazy things like running js scripts on top of a quickjs interpreter compiled to wasm to run on top of a wasm interpreter "for portability and safety", it gets weird to see the benefits..

moonchrome 3y ago

By same logic why use containers ? You can just ship VM images. It's basically the same thing as using a language runtime vs using a generic container for Lambda, except WASM would be lower level (you would need to ship language runtime on top of WASM but that's probably order of magnitude less overhead than a container) Containers feel like a clever hack to get existing apps packaged up and reduce the overhead of VMs, but I'd much rather deploy runtime/app code only.

throwawaymaths 3y ago
Really? VM images take longer to spin up, both at the infra level and the devex level
- moonchrome 3y ago
  Just like docker image vs specialized language runtime ?
  - throwawaymaths 3y ago
    Sure, but for many langs hermetic config is an issue, you want to be relatively sure what your devs are building against is what gets deployed.
    - moonchrome 3y ago
      So you'll develop directly on the wasm runtime locally which should be a platform abstraction ? The way I see it VM -> Containers -> WASM is a logical progression in the same direction from the perspective of deploying applications.
      - deleted 3y ago
        [deleted]
      - throwawaymaths 3y ago
        I mean i don't think you get it. Wasm doesn't ship with a filesystem, POSIX support tools, etc. You only get your language runtime, so they're not comparable. Bare metal, VM, and containers all "look the same", like from a UX perspective. Wasm does not.

kevincox 3y ago

You can have all of these things on WebAssembly. You just compile them. I think the view here is WebAssembly as another architecture. Instead of compiling for x86 or ARM (or both) you just compile to WASM and it can run anywhere.

TekMol 3y ago
Compile what? A whole Debian distro with a Linux kernel and all 7000 packages?
- singularity2001 3y ago
  Compile glue code to the new kids favorite web stack: Their favorite database (SQLite) Their favorite webserver (Spin) Their favorite runtime (CPython) Hopefully some imagemagic, but definitely none of the linux clutter
- kevincox 3y ago
  Probably no kernel, but everything else.
  - drowawaygpt 3y ago
    [flagged]
  - TekMol 3y ago
    So what does "everything else" do if it has no kernel below it? What does curl do if it cannot talk to a network stack? What does "touch" do if there is no filesystem to touch? What does "dd" do if there are no block devices?
    - kevincox 3y ago
      Think of a docker container, they don't include a kernel. There is still a kernel somewhere obviously.

kortex 3y ago

I could see this greatly benefitting python in particular. Compile cpython and all the dependencies against WASM/WASI, bundle WASM wheels, and wrap the whole thing up in a single .wasm binary. Python portability woes are basically solved, provided your environment has the appropriate WASI runtime.

TekMol 3y ago
But my Python code does not run in a vacuum. It gets executed by Apache, writes to a file system, makes use of a gazillion of libraries and programs that come with Debian. What would the Python "requests" module do if it has no Linux kernel below it to pass the requests to a network stack?
- kortex 3y ago
  Your python code is executed by Apache? You mean like WSGI? Well either way, the bytecode alliance is working on things like fork/exec. > What would the Python "requests" module do if it has no Linux kernel below it to pass the requests to a network stack? Why does requests need a linux kernel? It's cross-platform. Strictly speaking it only needs the appropriate I/O calls. WASI provides a system interface to do I/O, network, files, etc. https://wasi.dev/ https://wasi.dev/ https://github.com/WebAssembly/wasi-sockets https://github.com/WebAssembly/wasi-sockets
mike_hearn 3y ago
Ironically this is solved already by the latest release of Graal, one of WASM's competitors: https://medium.com/graalvm/whats-new-in-graalvm-languages-161527df3d76With https://medium.com/graalvm/whats-new-in-graalvm-languages-16... You can now distribute Python applications or libraries as standalone binaries or JAR files without any external dependencies. The Truffle framework on which GraalPy is built, and the Sulong LLVM runtime that GraalPy leverages for managed execution of Python’s native extensions, enable virtualization of all filesystem access of Python applications, including those to the standard library and installed packages. So now you can build a standalone executable as follows: graalpy -m standalone binary - module my_script.py - output my_binary or a JAR file that runs on GraalVM and includes GraalPy as follows: graalpy -m standalone java - output-directory MyJavaApplication - module my_script.py The first form creates a fast starting native binary. The second is a portable bytecode standalone file. So this WASM dream is delivered already, just by a different group of people. Now, GraalPy is a different implementation to CPython so not all Python apps run on it yet. But obviously any WASMPy would have the same issue.

ape4 3y ago

The trend is to put more and more things into browsers and presumably WASM will have access to all that. But, yah, seems like a long way off.