Live data from Hacker News

Spin 3.0 – open-source tooling for building and running WASM apps

fermyon.com

31–40 of 44 posts

Re: Spin 3.0 – open-source tooling for building and running WASM apps

#31
post #28

Earlier quoted context omitted.

WASM is basically similar to JVM bytecode. So the comparison would be like using compiled code from Java, Scala and/or Kotlin for example. The source language only determines how the code is expressed in WASM and whether or not it also needs to bundle / compile-in some runtime code baggage for it to work.

I develop the Scala-to-Wasm compiler, and also maintain the JVM backend of Scala. I can tell you that Wasm is very different from JVM bytecode. The fundamental difference is that the JVM bytecode has an object model . When they talk to each other, Java, Scala and Kotlin do so at the abstraction level of the JVM object model. You can directly call methods between them because virtual dispatch of methods is a concept w…

Yes, in retrospect I should have mentioned "Components" in my comment and just compared it to "Java" in general instead. I felt that was implied due to the thread and topic of discussion.

From a pragmatic end-user point-of-view explanation, I would still stand by saying WASM Component Model may be similar to working within the JVM multi-language ecosystem. One can work with code compiled from multiple different languages, but the generated code may be different because of the different compilers.

Re: Spin 3.0 – open-source tooling for building and running WASM apps

#32
post #10

Earlier quoted context omitted.

wasmtime works as long as you make sure to include the lib directory % wasmtime run --dir .::/ python.wasm -c 'print("hello world")' hello world disclaimer: I run a code execution API service ( https://riza.io/playground ) that does this and more (HTTP, packages, etc.)

> .::/ whats this magic

Wild speculation based on very little understanding of WASI/WASM:

Perhaps "--dir .::/" means treat the host directory "." as the guest directory "/"?

Re: Spin 3.0 – open-source tooling for building and running WASM apps

#33
post #20
post #16

Earlier quoted context omitted.

Is that something I can run on my own laptop? It says it's "open source" but the docs seem to be for client libraries that need an API key.

everything, including the infra is open-source (below), but it currently requires more than just your laptop (gcp, nomad, firecracker, postgres, etc.) this way, we're able to run millions secure sandbox environments i appreciate asking though and will be forwarding to my team to see if we can come up with a way for users to emulate the execution locally source code: https://github.com/e2b-dev/infra

Sorry for asking a possibly noob question. Doesn't firecracker vms requires bare metal instances? And does gcp support provisioning bare metal instances? Or is it that you are able to run firecracker on normal vm instances in gcp ?

Re: Spin 3.0 – open-source tooling for building and running WASM apps

#34
Asking a question here that I long wanted to ask. Is it possible to have a python handler function that uses duckdb to query a S3 hosted parquet file and that uses pandas for some data manipulation, run as a WASM app? (leveraging all features of duckdb like predicate pushdown etc)

Re: Spin 3.0 – open-source tooling for building and running WASM apps

#35
post #30
post #28

Earlier quoted context omitted.

I develop the Scala-to-Wasm compiler, and also maintain the JVM backend of Scala. I can tell you that Wasm is very different from JVM bytecode. The fundamental difference is that the JVM bytecode has an object model . When they talk to each other, Java, Scala and Kotlin do so at the abstraction level of the JVM object model. You can directly call methods between them because virtual dispatch of methods is a concept w…

I am confused. You are referring to wasm modules here? And Component Model / WASI / WIT will give us polyglot interface-based programming then, right? Call each other's methods through the WIT interface between components.

Even the component model has nothing to say about the concept of methods. All you have are top-level functions with immutable arguments and immutable results. You can't hold on to an instance of an object created by the other language. You could hold an integer handle, but then you don't get garbage collection across the two languages.

So no, we're still a long way from the abstractions of a JVM, even taking the component model into account.

It's a good step in the direction of better interoperability between languages, though, don't get me wrong.

Re: Spin 3.0 – open-source tooling for building and running WASM apps

#37

Purple and green some to have become the colors of dev tooling. I'm seeing that color scheme everywhere.

I can see that at least Vite also uses those colors. In part inspired by terminal colors but purple (instead of black) makes it feel more modern and sophisticated.

That's the neat thing about trends, the next wave of colours will always feel more modern and sophisticated.

Re: Spin 3.0 – open-source tooling for building and running WASM apps

#38
I like the idea of CLI-first. But then could the tooling make it simple & convenient to run the exact same configuration in a browser ? With the choice of either (a) a shell-like prompt, or (b) an auto-generated basic GUI with the appropriate input widgets ?

Re: Spin 3.0 – open-source tooling for building and running WASM apps

#40
post #20

Earlier quoted context omitted.

everything, including the infra is open-source (below), but it currently requires more than just your laptop (gcp, nomad, firecracker, postgres, etc.) this way, we're able to run millions secure sandbox environments i appreciate asking though and will be forwarding to my team to see if we can come up with a way for users to emulate the execution locally source code: https://github.com/e2b-dev/infra

Sorry for asking a possibly noob question. Doesn't firecracker vms requires bare metal instances? And does gcp support provisioning bare metal instances? Or is it that you are able to run firecracker on normal vm instances in gcp ?

GCP supports nested virtualisation
Post reply on HN