วีดีโอ

Did they compile from Rust or C?

@@chokosabe yes, we published version 0.1.0 of the plugin ~2 weeks ago

@@cloud-native-corner thanks. 🙏🏻. We‘re in the process of creating and publishing an article that guides you through everything.

@@glitchinLife that’s a fair point. However I (Thorsten) was working with many corporations, which required persistence of data on-premises. If one is facing regulatory compliances like that, it could be handy to offload inferencing, while having compute and persistence on-premises.

Thank you 🙏🏼

In the case of rust, yes! But spin itself is language agnostic. No matter which language you use, you end up with a simple “spin build”

Thanks for the great feedback

Thanks for the feedback! We’ll ensure that font sizes will be big enough in future streams

Thank you <3

Glad I'm not the only one who noticed that one

100% agree!

Thank you! Do check out Spin

Glad you liked it!

Thank you!

The k3s guide is on k3s dot io. Should be straightforward to get that started. Let us know if you run into any issues there.

It absolutely is! Check the keynote from Kubecon Paris where ZEISS spoke about how the use Wasm in production - th-cam.com/video/tu8a-GefJL8/w-d-xo.html They also did a livestream here recently: th-cam.com/video/BwaXNjzbIeI/w-d-xo.html And yes, Spin does support Redis triggers.

You can specify the number of replicas you need. For the video, we chose 2 for load balancing purposes.

Great to hear that!

Thank you! Here you go: github.com/fermyon/code-things It's a year old, so it probably uses SDK v1. Feel free to add a GitHub issue or put in a PR for it if something is borked :)

Leptos is great <3 Thanks for watching

💯💯

Thanks! That's just Google Slides / Powerpoint :-D

That's a good suggestion. Will perhaps do a livestream about it in the near future :)

The security in Wasm is about the sandboxed environment. Each WebAssembly module executes within a sandboxed environment separated from the host runtime using fault isolation techniques. So you can run Doom in a Wasm module which will execute independently, and can’t escape the sandbox without going through appropriate APIs. At the same time, no buggy or malicious modules can access this Doom app unless explicitly given permissions to do so.

A binary format does not necessary mean machine code. It just means that it is not text-based. For example wasm and protobuf (used grpc) are binary formats, the underlying bytes do not conform to a text-representation. On the other hand wat and json are text formats, if you look at them in a text editor, you see textual characters that should means something. So wasm is both a binary-code format and a bytecode format. It is binary-encoded and represents some sort of machine-understandable computation, although on a higher level that machine-code itself, but lower level that programming languages. Wat would be a text-based bytecode format. It still represents some sort of computation, but now encoded in a textual-representation. Keep in mind that these terms are not perfectly defined and there are a lot of edge cases that would break these definitions. For example most people would assume that a bytecode format also is encoded as binary, but if you look up wikipedia for a definitions, it did not say whether a bytcode as to be binary, just that it needs to be efficiently interpretable by machines, whatever that mean. But then its just wikipedia, and binary encodings are usually faster for machines than textual.

Glad you enjoyed it

'spin build' runs two commands. The syntax used for this works on Linux and Mac, but not on Windows. If you’re a Windows user, you’ll need to copy the two commands (separated by &&) out of spin.toml and run them separately by hand.

The dividing line between JIT and AOT is whether you're compiling code while executing. Wasm's AOT is basically classical compilation but delayed a bit, but still before the program starts. JIT comes out of the land of interpreted languages, as a way to make interpreters faster. You can JIT everything, while not everything can be AOT compiled. AOT has less runtime overhead but also less flexibility, in the end restricting wasm to features supported by AOT means that implementations can choose between both approaches. It also makes supporting heavily dynamic languages (say, lua or python) quite a bit more involved but that can be dealt with by extensions to the AOT-capable core, no need to make everyone use JIT which would be rather pointless if your source language is C or Rust or such. As to JIT being faster due to being able to collect stats: Not really. Java is blazing fast for a dynamic language (reflection and everything) but it still doesn't compete at the very top end. Your CPU is already tracking lots of stats, including what's necessary to predict branches. If you want to exploit that kind of thing to get faster than plain AOT native code an off the shelf JIT probably won't gain you anything, you have to roll something specific to your algorithm so that it can exploit domain knowledge.

@@aoeuable Thanks a ton for the detailed response. > while not everything can be AOT compiled. Is this because the target architecture is NOT known in advance? I am assuming that wasm bytecode does not have any dynamic behaviour (like JVM bytecode which poses a challenge for AoT compilation) > no need to make everyone use JIT which would be rather pointless if your source language is C or Rust This is interesting and definitely makes sense. For languages like Java, JS because of their dynamic nature JIT can generate actual machine code based on the invocations stats (dynamic dispatch for eg). Definitely not needed for C / Rust as the targets are known during compilation time.

@@GK-rl5du wasm bytecode indeed isn't dynamic and in the video they're kinda mixing up AOT and JIT (or at least not making the same distinction as I). While wasm doesn't know the architecture in advance it still compiles everything before starting execution, which is AOT, just a bit later than usual. Or, differently put: While native compilation usually goes source -> intermediate representation -> native code, WASM does source -> (probably intermediate representation) -> portable interchange format (i.e. .wasm files) -> (possibly intermediate representation) -> native code.

@@aoeuable When we execute a wasm module via a wasm runtime (wasmtime for eg) the runtime interprets the wasm bytecodes? Or would it compile wasm module to native code, put it in some tmp dir and fork a process out of it?

@@GK-rl5du That depends on the implementation. But wasmtime compiles directly into memory and then executes it.

Thanks for tuning in!

Check out the componentize-py livestream that we did recently for a deep-dive on how that works.