 Hello everyone, good afternoon. So we are here, we are so excited to hear with you to talk about Golang and Wazi. So I'm going to tell you about the agenda, what we wanna talk about. So we'll delve into, I mean, Wazi and discuss a bit about history about Wazi and how it was added to Golang in 1.21 release. And then we'll start presentation with WebAssembly architecture and Wazi, I mean, WebAssembly interface. We'll go deep dive into Wazi, how it works and all. And then we'll go through a little bit about Golang, like Golang tool chain and Golang ecosystem. Then we'll cover few use cases of Wazi in Go application today. We'll show Golang, I mean, plug in, how we build plug-in using Wazi and Golang. And finally, we want to talk a bit about ongoing development in Golang and Wazi, like Wazi preview tool. And the next steps for Golang and Wazi to continue their journey together. So we'll be discussing more about the histories and all. So my name is Rajiv. I'm originally from Bihar, India. And I'm currently work as a software engineer at Epimolar Musk. So I'm a part of platform engineering team. I'm located in Bangalore, India. I did my colleagues in Bangalore, India from GSS College of Engineering, GSS College of Academy, Bangalore. I have a degree in information science and engineering department, department. And I started working with Go in 2020. So I was part of a program called Google season of docs. I did Gshort with GRPC gateway. So there I learned about Golang. And obviously I am open source enthusiast. I contributed to open source projects and program like season of docs, LFX mentorship and summer of code. I work with companies like Lumore, Redbus and Economize. So in my college days, so I'm here with Arshil. Do you want to tell us a bit about yourself Arshil? Sure. So my name is Arshil. I am originally from France. I'm really happy to have you all here. But I flew here, I'm based in San Francisco now. I've been a Go developer for almost 10 years and I started working on the Go compiler in 2023. I do a lot of open source work. I contribute to Wozero, maintain several libraries, some of them that you might be using. Last year I joined the team that develops and maintains the web assembly port of Go. And I'm also the co-founder of dispatch.run where we're working on a platform to create reliable distributed systems. So Rajiv and I come from very different places. We connected online in the Go community and thought it would be nice to come and tell the stories of Go and web assembly to a broader audience. So open source is really core to the story we're here to tell. Not only because Go is powered by an open source community, but because it's thanks to this community that the world we're here to talk about today happened. So web assembly originated in the browser. It's byte code that is executed by a virtual machine. The VM is also referred to as the host or the runtime. And by default web assembly is purely just memory and compute, but the runtime can expose functions to the guest module and those are called host functions. In recent years, standalone runtimes have emerged like was zero, wasm time, wasmer or wasm edge. And while these runtimes can be used as in to run compiled web assembly modules, they can also be embedded into existing applications. And this is a very powerful model. For example, you can write a plugin in Rust, compile it to web assembly and embed it in a Go application. Web assembly runtime also offer fairly strong sandboxing. So in some case, we can even run untrusted code as extensions to our applications. And however, for all these capabilities to work, there needs to be a common interface that's spoken by both the runtime and the modules. And this is the web assembly system interface. So from now on, I'm going to abbreviate web assembly system interface as WASI. And WASI is the ABI that compilers can target to produce web assembly modules. And the runtimes implement WASI to provide access to system resources. In a way, it makes possible to create very lightweight containers in user space without assistance from the kernel. The host application can choose which environment variables, fast and mount points are exposed to each instance of the modules. And there are currently two released version of WASI called preview one and preview two, that are often referred to as WASI P1 and WASI P2. And at this times, compilers that target WASI have mostly implemented preview one. So we're talking about fairly bleeding technology here with a lot of active development in the space. And like I was saying earlier, we need WASI because we need a portable interface that compilers and runtimes can work with. If we only supported tool chain was the combination of one compiler and one runtime, there would be no need for standard specification. Moreover, a specification for accessing system resources is important because those resources are important. Programs need files, sockets, environment variables, clocks. I mean, I don't know what kind of useful program we can write without these primitives. So now that we have a sense of what's WASI and why we need it, Rajiv, how about you tell us about it? Yeah, thank you, Ashil. So let's start with what is Go? So Go is a statically typed, compiled, garbage collected language. So development started in 2007 at Google and it was publicly released in 2009 in Google, obviously. So Go is a multi-paradism primary language oriented towards needs of developing secure and production quality applications. It is language developed and maintained by Google as an open source project, I said earlier. So, but instead of telling you a long story, let me show you an example. So this is a Go program that prints a hello all, hello masses. As you can see, it is quite simple. Even if you have never looked at Go program before, you will able to make sense of the code and this is a value of Go. Go is easy to pick up. Go has a very standard library, advanced concurrency primitives built in languages like Go Routines, Channels. And it's also very portable. So it compiles to multitude of targets, including WebAssembly. So the Go program is an entry point of Go Toolchain. Basically, Go Toolchain standardized how developers maintain and build their application. I have listed a few commands that I use day-to-day with Go. So as you can see, it provides a lot of standard tooling for building, managing dependency, testing and formatting the code, but also more advanced stuff like CPU profiling, memory profiling. So you can profile the program and optimize as much as you can. But Go is a lot more than a language. I mean, it's an ecosystem of high quality open source tools and libraries that largely contribute to developer productivity. Beyond that, it's also a tool with very wide breadth of application. I'm mentioning all this because when using Go, the entire tool chain is available when compiling to WebAssembly. So, Ashil, how about how you tell us how Avaji was developed in Go? All right, so since a lot of you here, I imagine are software developers, I'm sure you're gonna enjoy the story. In particular, because you've probably lived through similar ventures before. WebAssembly support was first added to Go in 1.11 and that shipped in 2018. But the Wasi compilation target was released last year in Go 121. This is five years and 10 versions apart. And that's because Go is, for a big part, developed by its community and for a while, there weren't enough contributors available to work on Wasi. And that changed in 2023 when Johan Brandhorst posted a message on the Go for Slack asking if anyone was interested in forming a team to maintain the WebAssembly port. So, my co-founder replied and a few days later, we had a little group of 14 members ready to pick up the work. But imagine the situation. Four engineers who had never worked together on the Go compiler or runtime. And we picked up an abandoned branch that was started few years before to add Wasi and had massively diverged from upstream. So let me tell you, we weren't necessarily set on a path for success. Our task was first to split out the compiler from the runtime changes so we could submit individual proposal to the Go project and deliver incremental results. We submitted a first proposal to add a compiler primitive called Go Wasm Import which allows developers to declare Go functions as host imports. And a second proposal to add a new compilation target for Wasi preview one that we called Wasi P1. And as a side note, we heard that more language are adopting the terms Wasi P1 and Wasi P2 and I personally really enjoy this cross language collaboration that we have in the community. So while we were going through the development of Wasi P1, a major challenge was dealing with the difference of interpretation of the Wasi spec in various languages and compilers. The alternative compiler TinyGo, which is built on LLVM, had support for Wasi for a few years already. So since TinyGo already supported it, I felt this is great. I could use the combination of TinyGo and WasmTime as a reference. However, the file system implementation of Wasi in TinyGo was only partially completed. So while we were working on bringing Wasi P1 to big Go, I also took a side quest to finish the Wasi P1 implementation in TinyGo in order to have a reference I could compare to. But through the perseverance of the team, and after a couple of months, we had the Go Wasm Import directive merged in, which we could use to implement Wasi P1 in Go. And as we made progress on the Wasi P1 implementation, more developers tagged along to contribute improvements. And at this stage, we started getting a lot of support from the Go team as well, and it really felt like we were gonna pull it off. And finally, the Wasi P1 target went live in Go 121, which was released in September of last year. Now I want to take a minute to thank all the contributors who have participated in creating the Wasi P1 port of Go. There's way too many to name them on the slides, but if you're watching this talk, you know who you are, and you know the amazing role that you took in making this a reality. That's truly a team effort from people when mostly never met in person. And to me, this is a great showcase of the power of open source communities. And now I'll head it over to Rajiv to tell us more about what we can do with Wasi and Go. Thank you, Ashil. So we mentioned that the first edition was a compiler directive, Go Wasm Import, and this is how we use it in Go. So the program declares a Go function signature without the body of the function and preceded with the directive declaring the names of Wasm modules and the export ex functions that it links to. So we can pass pointer in a linear program memory and other primitive types. So and compilers take care all the translation to web assembly types. As you can see, this is fairly low level directive. Only library maintainers usually care to use it. And would expose higher level API that invokes the imports. So now let's take a look at how we can build Go program targeting Wasi P1. So the Go Arc and Go OS environment variables are used to control the target platform. So we set them to Wasm and Wasi P1 to build Wasi module. And it doesn't get much simpler than that to build a Go program for Wasi P1. So in this program, the Go Asm Import directive is used underneath by the Go runtime to interact with the host. And then we run that program with runtime like was zero. We are, I use was zero to run this program. We can use any other runtimes too. So we see our, when we run the program, we see our messages in the console like hello Wasi P1. So let me talk about the use cases of Wasi P1. So there are many applications of Wasi P1. I selected this one because it highlights the plugin model of WebAssembly. So Wasi is currently primarily useful for writing plugins in any language that can compile to Wasm or Wasi and then executed in any language using Wasm or Wasi virtual machines. So there is a project called SQLC. So we generate a types of code from SQL. And in this project, they need differential plugin to make things happen like SQLC, Django, SQLC, Python, SQLC, Kotlin, et cetera. So for every release, they extract the Go, Python, Kotlin, et cetera's code gen into standalone respective particular language plugins. What I mentioned like Django, GenPython, and Kotlin, which are then compiled. I mean, basically, which are then built using Wasi P1. This allows people to customize the output by forking the particular language plugin, but not the whole repository of SQLC. Go can be compiled both as a plugin and as a plugin runner like Wasi. For example, in the case of SQLC, they can run plugins compiled to Wasi and then write their own plugins to Go and compile them to Wasi. The main reason for using Wasi P1 in the SQLC is that it's much smaller code chains. I mean, amount of code to change to write plugins. So this is the main reason they use Wasi P1 in SQLC project. So let me talk about the another use case, like we have a Kube scheduler, Wasm extension. So WebAssembly enables the execution code written in diverse language with a secure environment. And its hostility allows developers to leverage existing code base to Wasm for various purposes. And integrating WebAssembly into Kube scheduler empowers the extent of Kube scheduler functionality, like basically through custom plugins compiled to Wasm binaries. This approach enriches the Kubernetes scheduling capability with necessities to changes to code without changing the code implementers of Kube scheduler. So by embedding the WebAssembly runtime like Wasi and basically directly into scheduler, the process of incorporating the custom plugins became like very streamlined. I mean, configuration based loading and of these plugins further simplifies the, basically further simplifies the custom customizing process for users. So today the, I mean, we can extend the Kube scheduler using a scheduling framework too, but it's not trivial, right? I mean, once you develop your scheduler and there is additional deployment and configuration work together to integrate into your cluster. And this is not one time task. It needs to be repeated for every cluster upgrade. So basically the Kube scheduler to Wasm extrinsen project alleviates the burden by enabling the default scheduler to load custom plugins in Wasm. I said, you write this eliminates the challenges like what I said, like changing, we don't have to change the core implementation of the Kube scheduler or like that. So additionally, it also opens the possibility for writing languages other than Go. So now we'll head over to Arshel to tell us about the qualities and limitation of Wasi P1. Thank you. So Go is a language with native concurrency built in. And when compiling to Wasi, we use non-blocking file descriptors to integrate with the Go runtime and allow concurrent operations to make progress without blocking one another. This also integrates with other runtime features like timers. So we get access to a very powerful programming tool. A notable absence in Wasi preview one is a complete implementation of network sockets which limits supports for key features of the Go standard library like HTTP clients and servers. However, there are WebAssembly runtimes like Wasmer or Wasm Edge that have introduced networking extensions. And although these extensions are not integrated into Go, we can use third-party libraries to leverage them. And these libraries are also great examples of using the Go Wasm import directive to invoke host functions. And so now we actually have two Go compilers that can target Wasi. So when should we use one or the other? The primary reason to use TinyGo is for the smaller binary size that it produces. If you're shipping code to a browser, for example, this is something that matters a lot. Another reason is that it generally implements features ahead of big Go. So for example, TinyGo had support for Wasi long before Go did. Now, TinyGo makes some trade-offs and it won't support 100% of the Go standard library or the tool chain. So if you need the portability guarantees, this is when you should use the main Go compiler. So to wrap it up, I wanna take a quick look at what's happening today in Go. At this time, two proposals have been accepted by the Go team and are being worked on. The current WebAssembly architecture in Go uses a 64-bit address space, even though all WebAssembly hosts assume 32 bits. So this hybrid model complicates interaction with the host a lot. We're working on addressing this in a new Wasm32 compilation target. The second proposal we're working on intends to address one of the current limitations. We're adding a Go Wasm export compiler directive that would allow developers to declare Go functions that are exported in the compiled WebAssembly module. And finally, I also want to mention the work that is being done on TinyGo to add experimental support for Wasi Preview 2. So Go is becoming a big player in the Wasi ecosystem and we're always looking for more friends to join us on this journey. So if you're inspired, you want to get involved, use Wasi P1, join the Go for Slack and come talk to us. Thank you. We have some time left, so we can take some questions if you have any. Tess? Hi, yeah. Thank you for your talk. I think this was really inspiring. And if I get this correctly, like the majority or even the entire team which was working on Wasi P1 where like first time contributors to Golang, do you have advice to people who like seek their way into Golang contribution or like how did you start out actually? So you're asking as an aspiring contributor, like what are the first step to take? I think joining the Go for Slack is great by getting to know the people, offering help and also Go has a lot of material online to teach you how to become a contributor. So getting familiar with this as well. And I think there's much more than this. Like I say, we're always looking for contributors who can help us out. You can help with documentation, with testing, with more advanced work that we're doing on the runtime. So whatever your skill set is, I think we can use more hands. Thank you. Yeah, I'd love to hear what you consider like the biggest challenges in terms of the work that needs to be done. Like what areas as you go through or like is it a lot of work, but it's boring or are there theoretical areas you need to make progress in? And I just love to hear what you're thinking. So you're asking what are like the main challenges that we face in the future development of Go and WebAssembly. So like I was saying, WebAssembly, especially the way that it's starting to be used outside of the browser is very new. It almost feels like a very new field of computing. And so there's a lot of unknowns. And I feel like the most difficult part is making the right decisions to continue evolving the technology in the right direction. So that requires a lot of collaboration from different communities, making sure that all the technical choices, especially those that go into the specification, are going to be compatible with the various ways that languages are implemented. So mostly design, I wanna say. And yeah, I guess that's the main one that comes to mind. Hey, thank you very much for your talk. So I have very little experience with WebAssembly. So it's really, this has been an eye opening. So thank you for this talk. But so as a Go developer currently, if I go get the package, I would expect it to compile locally. But I saw that Go import statement, how does a WebAssembly module reach my machine for compilation? Yeah, so you're asking about the compatibility guarantees that you get when you target WebAssembly compared to other regular Go builds, right? Yes, exactly. The entire Go standard library is going to compile. Now, like I was saying, some features aren't available, like networking is only available as an extension through a third party package. Most packages out there, unless they have tight dependencies to the operating systems, will also compile and run the same way you would run them on ARM 64 or X86, it will execute on a WebAssembly host. So with big Go, you get a lot of, the experience I want to say is like almost as smooth as possible. What I would be looking for is, if your use case involves a lot of networking, that's where you're gonna maybe crumble a little bit more. But like I was saying, there's ongoing development in Wazze to address the thing. So in the coming years, hopefully we'll have a lot better support there. Okay, thank you. Thanks for your presentation. As you mentioned, big Go produces quite a big artifact. And I would love to deploy a Wazze and Go artifact on, for example, Cloudflare workers. But it seems that I have to use tiny Go for that. Do you think that in the future, big Go will produce a smaller artifact? You're asking about Go producing large WebAssembly artifacts and is it going to get better or is tiny Go the only avenue in the future? Okay. So the Go, like the program that Go produces is large because we embed the entire runtime. We've got a garbage collection, right? We support full concurrency. Basically the entire language is built into the target. Now, when you look at the way whether some of the modules are used, oftentimes they are employed in very ephemeral workloads, things like handling serverless functions. You don't necessarily need all this capability when you're gonna like spawn a module, run the function to completion and then turn it down. So thinking about hypothetical changes that could be made, if we didn't compile the garbage collector at all in the target for those use cases, then potentially the size would be a lot smaller. So I mean, these are things that we haven't explored, but once again, if you want to contribute, like maybe that's an idea to bring to the table. Following up on that question, are things like Wasm GC and various other proposals that are appearing now, do they help you optimize by not having to bring that part of the language into the module? When I was talking about the main challenges being around design, this is I think an example of it where Wasm GC could almost help us, but there's a few key features that are missing to really replace the garbage collector that we have in Go. So today the answer unfortunately is no, but I'm hoping that we can change that answer in the future. Right, looks like, oh, there's one more. Thanks for talk. Parallel execution, are we, what's the timeline on that? Is it the Wasi standard that's stopping the progress on that or is that just implementation? So the Wasm spec has, sorry, you're asking about, can we do parallel execution of WebAssembly or directly from WebAssembly, right? Yeah, so in the talk you said concurrency's there. Yeah. But the parallel execution is in there. Yeah, there are more tools now in the WebAssembly core specification that open up the door to implementing this type of features, but there are also limitation in Wasi, for example, having the ability to create a thread that prevent us from using parallelism directly from like in the compiled target. So progress is being made, it will get there. I guess that's my opinion, but at this time, excuse me, at this time, you don't have any sort of like API allowing you to do parallel processing. If you're building an application that uses a WebAssembly runtime for extension purposes, you're still free to spawn multiple threads and execute each module independently, so you get parallelism that way, but you don't get it in go directly from the program. Hello, about Wasm, there's a thing about, there's multiple of them and it can be a bit confusing for you as user. So what in your opinion would be like the advantage of Wasi P compared to Wasp Edge or Wasp app and if I have like a simple application, like a gene API that's calling PostgreSQL database, just like a simple container, and I want to transmit it to the Wasp, which runtime should I go to? I'm sorry, can you elaborate a little bit? As someone, you can choose a runtime for your application goal that you want to try to run as WebAssembly application, but how are you supposed to choose this runtime between the brand offering? So if you're just using the runtime as a standalone tool and you're asking which runtime should I pick when I want to run WebAssembly stuff, right? I want to say use the one that you like. Some of them have different features, so if you need a feature that exists in one runtime, that would be an indicator of the one you should choose. I think what's more, what's going to determine your choice more is like, when you use WebAssembly as an extension mechanism, you're going to want a runtime that is in the language of your host, right? Because the integration is going to be seamless. So if your host application is a go application, you're probably going to want to use was zero because that's a zero dependency go wasm runtime. If you're developing a rust host, then wasm time is probably a much better choice because it is written in rust, so the integration is going to be very seamless. So that's kind of like the decision matrix I would use.