|
| WhereIsTheTruth wrote:
| Lovely, also cross-compile to X86 and arm for all major platforms
| in just 30seconds
|
| Try it yourself, clone their repo and ``make dist``
|
| That's what I love about Go
| vira28 wrote:
| What are other such web assembly runtimes and how does Wazero
| compares to those?
| pyrolistical wrote:
| Zig can directly compile to wasm. Since most of zig's std is
| pure zig, you can use it as is. It's also zero dep
| evacchi wrote:
| as far as I know wazero is the only zero-dependency Wasm
| runtime written in Go.
|
| This is not just one of those "written in $LANG" kinda deal:
| most other runtimes require linking against a native library;
| this in turn plays against a lot of the killer features of Go,
| such as good tooling, easy cross-compilation, goroutines [0];
| so, not requiring Cgo means a team may bring wazero to their Go
| project without a second thought.
|
| As for other features, we may not be as bleeding edge as other
| projects, but we are a rather tiny team. If you expect support
| for WASI (preview 1) we have it :) we try to concentrate our
| effort on high-quality support of stable specs.
|
| EDIT: oh, and a huge shout-out to Stealthrocket, they are
| building a lot of cool stuff on top of wazero:
|
| - wzprof, a wasm profiler integrating with pprof
| https://github.com/stealthrocket/wzprof
|
| - timecraft, a wasm time-traveling runtime
| https://github.com/stealthrocket/timecraft
|
| [0] see "CGO is not Go" https://dave.cheney.net/2016/01/18/cgo-
| is-not-go
| vira28 wrote:
| Thanks. My question is more of other runtime not specifically
| about the ones written in Go.
| alecthomas wrote:
| There are a few, but I suspect the most widely used would
| be wasmtime. It's written in Rust and can be used from Go
| [2] but requires CGo (as mentioned by GP).
|
| [1] https://github.com/bytecodealliance/wasmtime [2]
| https://github.com/bytecodealliance/wasmtime-go
| caust1c wrote:
| We're using it at RunReveal and I've got to say that we're
| extremely happy with it.
|
| At Segment I always wanted a good sandbox environment for running
| customer code. This is the ideal solution, and the fact that it
| doesn't require CGo: :chefs_kiss:
|
| Happy to answer any questions people considering using it might
| have!
| verdverm wrote:
| CUE recently added initial WASM support, glad to see it was this
| library!
|
| https://github.com/cue-lang/cue/blob/0520a3f9e73e63d77e43c9b...
| kinghajj wrote:
| I'm curious, what's the use case for CUE in a WASM environment?
| So that web apps can compile configuration at runtime?
| verdverm wrote:
| This is WASM in CUE, to unlock more possibilities while still
| preserving the language semantics.
|
| You can already do CUE via WASM, this is how the playground
| works.
|
| https://cuelang.org/play/?id=#cue@export@cue
| stanleydrew wrote:
| Haven't looked at it, but I assume the use-case is opposite
| of your suggestion, i.e. CUE wants to offer some kind of
| plugin integration and embedding a WASM runtime is the safest
| way.
| verdverm wrote:
| It's also to enable you to do non-CUE things in CUE or do
| things more efficiently (in the long run). Think of things
| like topological sort or processing a value recursively.
| Places where an imperative system is so much easier to do
| something.
| babelfish wrote:
| Wow, could this be used to run an HTTP server on a Cloudflare
| Worker?
| nikivi wrote:
| Also curious about this, can I use Wazero to compile Go to
| WASM?
|
| Or it replaces cloudflare workers instead?
| evacchi wrote:
| wazero is a wasm _runtime_ , not a wasm compiler. For a
| compiler Go -> Wasm you should use tinygo or Go proper :)
| nmhancoc wrote:
| I used this to run ML models I compiled down to WASM from Go.
| Really useful to put generic, high performance HTTP / JSON
| handling in front of some common interchangeable code.
| cube2222 wrote:
| I've used wazero for a pet project (raw wasm generation from
| simple query plans) and it was really nice to work with!
|
| I also had to play around a bit with wasm relocations and the
| encoding/decoding libraries they've built are very readable, too,
| so I was able to hack together what I needed.
|
| Fingers crossed for the optimizing compiler that's planned for
| some point!
| pdyc wrote:
| what are you using for generating wasm? tinygo or new go
| runtime support of wasm? what are the sizes of wasm binaries?
| last i checked helloworld was in the order of few MB's.
| cube2222 wrote:
| The project was a custom compiler to turn a simple query plan
| (think select, where, group by) into wasm. So it was
| basically hand-written raw wasm generation.
|
| I did compile some helper functions from Rust though, which
| also served as the "skeleton" of the wasm artifact I was
| later generating my wasm into, since wasm doesn't have any
| kind of proper dynamic linking right now.
| eudoxus wrote:
| Love to see what this looks like if its available to look
| at somewhere (Github?). Sounds super interesting, even as a
| toy project
| cube2222 wrote:
| Never got it to anything close to a finished state,
| instead moving on to doing the same prototype in llvm and
| then cranelift.
|
| That said, here's some of the wazero-based code on a
| branch - https://github.com/cube2222/octosql/tree/wasm-
| experiment/was...
|
| It really is just a very very basic prototype.
| evacchi wrote:
| tinygo still wins for size, and the reflection story got
| better (json works!). The traditional Go compiler produces
| larger binary but OTOH it's super-fast, as fast as native
| builds!
| skybrian wrote:
| I count one dependency, on wazero itself.
|
| Also, the Go SDK. There is also the OS and the hardware.
|
| I think what they mean to say is that their module has no
| additional dependencies on other modules. But, how much should
| users care? Go is pretty good at managing dependencies and
| they're okay within reason.
|
| It seems like an odd way to name your module? I guess it shows
| commitment. But if they later decide on adding a dependency, they
| could rename it.
| evacchi wrote:
| The "zero-dependency" in this context really means zero
| dependencies from Cgo :) see
| https://news.ycombinator.com/item?id=36552401
| skybrian wrote:
| "Pure Go" seems like a fairly common way to talk about that.
|
| But I suppose generated Go code should be okay? Definitions
| are hard.
| evacchi wrote:
| it's a bit more nuanced than that, we are also trying to
| actually limit third-party dependencies, you can read more
| about it here https://github.com/tetratelabs/wazero/blob/ma
| in/RATIONALE.md...
| skybrian wrote:
| That's a pretty deep rabbit-hole. Thanks!
| circuit10 wrote:
| There's a section on the site for this:
|
| "Why zero?
|
| By avoiding CGO, wazero avoids prerequisites such as shared
| libraries or libc, and lets you keep features like cross
| compilation. Being pure Go, wazero adds only a small amount of
| size to your binary. Meanwhile, wazero's API gives features you
| expect in Go, such as safe concurrency and context
| propagation."
|
| Though that seems to be more about specifically C dependencies
| koreanguy wrote:
| [dead]
| aatd86 wrote:
| Nothing much to say apart from me being really hyped about this
| project.
|
| It's almost time I dive in. I would like to be able to call
| android/iOS routines with this.
|
| Wondering what the overhead would be too.
| evacchi wrote:
| Hey I am on the dev team if someone has questions :)
| segphault wrote:
| Any plans to support the WebAssembly GC proposal? Binaryen
| supports GC structs and arrays now, but there aren't a lot of
| runtimes that have it yet. It would be cool if Wazero could do
| it in a way where managed structs can be seamlessly shared
| across the Wasm/Go boundary using the native Go GC.
| evacchi wrote:
| We are tracking the evolution of most proposals but we are a
| tiny team so we try to concentrate our efforts on those that
| have a higher degree of maturity, but I am sure we will at
| some point :)
| verst wrote:
| I'm one of the Dapr (Distributed Application Runtime)
| maintainers which has a wazero based wasm integration. The
| wazero team contributed this integration.
|
| I just wanted to say that the wazero team has done a great job
| keeping the integration up to date and have been very
| responsive. For example, our project also supports Linux Arm32
| and wazero was initially not testing against that architecture
| which led to a compile issue for us. Once we pointed this out
| they fixed this and added this architecture to their CI tests
| as well.
|
| EDIT: Also because our project can be compiled for any common
| O/S and architecture combination the pure Go implementation is
| critical. We do not accept use of CGO.
| kouteiheika wrote:
| How does the performance compare to wasmtime or wasmer?
| evacchi wrote:
| wasmtime and wasmer are basically state-of-the-art. Our
| compilation backend is a fast, but straightforward translator
| from wasm to binary (think v8 liftoff vs turbofan), so it's
| faster than interpreting, but still slower than a well-
| crafted optimizing compiler. However depending on your use
| case, that kind of performance may not be everything: e.g.
| when I/O dominates .
|
| The good news is an optimizing backend is being worked on as
| we speak and should be available very soon :)
| kouteiheika wrote:
| I don't suppose you have any concrete benchmark numbers,
| e.g. coremark? (:
|
| Also, how do you sandbox the guest program? Just bounds
| checks on memory accesses? Do you use the same trick as
| wasmtime does where they map a ton of inaccessible address
| space and depend on a SIGSEGV to catch violations? What
| about potential stack overflows - how do you protect
| against those?
| evacchi wrote:
| so as for the first question, I'll refer to Adrian's
| reply on an older thread
| https://news.ycombinator.com/item?id=31415317
|
| as for the second, that's an excellent question but I'll
| have to be honest and tell you that I am the n00b of the
| team and I don't know the answer :D
|
| I can refer you to these possibly related docs
|
| - https://github.com/tetratelabs/wazero/blob/main/RATIONA
| LE.md...
|
| - https://wazero.io/docs/how_do_compiler_functions_work/
| (e.g. traps are handled on the Go side)
|
| ...and then my awesome team mates might get back to you
| with a proper answer later when they wake up :^)
| dilyevsky wrote:
| Probably dumb q - are there security implications of using aot
| for untrusted workloads? Are there plans to do jit?
| evacchi wrote:
| It depends on what you mean for JIT. wazero is _load-time_
| AoT; i.e. we compile the module in-memory on load, for
| efficient execution later, when you instantiate, it is not
| AoT in the sense that we produce a stand-alone executable,
| the runtime is always hosting that executable code that is
| generated, and we go back-and-forth between translated wasm
| and "Go space" at run-time in many cases. It is AoT in the
| sense that we do not tune the generated code depending on
| tracing or profiling information, because we don't track it
| for compilation.
|
| The Wasm model itself gives a certain degree of safety: e.g.
| you do not have complete control over the host OS, because
| you have to explicitly expose functions to the gues module;
| we also provide a certain degree of control over e.g.
| execution time (you can instantiate a module in such a way
| that executions can be cancelled or set a timeout) and memory
| space.
|
| We also provide an interpreter for all platforms where Go
| runs, and Takeshi (the founder of the project) is also
| working on bootstrapping an optimizing compiler that should
| soon land on main, and more work will happen in that space.
| carom wrote:
| Does the AoT compiler target Go's assembly language or do
| you have arch specific targets?
| evacchi wrote:
| we have our own assembler for arm64 and asm64
| circuit10 wrote:
| JIT/AOT just refers to the time that compilation is done, it
| doesn't necessarily have anything to do with security.
| empressplay wrote:
| Note that if your Go code doesn't actually use CGO, you can just
| compile to WebAssembly, nothing else required
| stanleydrew wrote:
| Pretty neat. Maybe I'll take a crack at replacing wasmtime with
| this in sqlc.
| ejcx wrote:
| Happy wazero user here in production. The team supporting the
| project has been really helpful and it's a very solid project.
| Fire-Dragon-DoL wrote:
| Oh, this might be how we finally get plugins in Go
| nilslice wrote:
| keep an eye on https://github.com/extism/extism for a pure Go
| option that does plugins well
|
| we embed wasmtime in your Go right now, but not for long...
| evacchi wrote:
| you mean like this? https://github.com/knqyf263/go-plugin ;)
|
| wazero under the hood, by one of our awesome community members
| Fire-Dragon-DoL wrote:
| Nice, oh damn the limitations are still heavy. Sigh
| candiddevmike wrote:
| What's your definition of a plugin? =D
| Fire-Dragon-DoL wrote:
| Yeah, should have been more precise. Code that can be loaded
| at runtime, does not need to be compiled together with the
| host application, can be loaded by just providing a path to a
| file/directory and can be executed in the host, ideally
| securely (not a strict requirement for my usage). The plugin
| ideally runs with performance very close to host performance
|
| go plugin package gets close, but the compile part is
| completely broken, where in reality the plugin has
| dependencies that can collide with the host. It would be fine
| if it was just the go runtime requirement that must match,
| but in reality it forces usage of cgo and a set of problems
| that make it really hard to use.
| candiddevmike wrote:
| Have you looked at https://github.com/hashicorp/go-plugin?
| Fire-Dragon-DoL wrote:
| I looked at every option out there and none of them
| satisfy all the requirements at the same time, sadly
| hugozap wrote:
| A dynamic routine that can run in a secure sandbox invoked
| from the host.
___________________________________________________________________
(page generated 2023-07-01 23:00 UTC) |