 I'll start over then. So good evening. My name is Ken Shaw. My presentation is on running basically web assembly with Go, running Go everywhere. So I actually changed my topic at a very last minute notice because one of the other speakers was doing a GRPC topic, and I didn't want to be repetitive. So I apologize if it's not as polished as it could be. So just to give you a little bit background, so I came in here from Indonesia. I'm the founder of Go Jakarta. Go Jakarta is a pretty big Go meetup group, probably one of the biggest in the world. We're a monthly meetup group. This is our little mascot. And if you are, so quick thanks to Jump Trading and to Go SG for hosting this tonight. If you are come out to Indonesia for some reason, please join our Go community there. We've got meetup, telegram, Facebook groups, and other stuff. It was pretty big. It's pretty active. So just a quick background about me. I'm the CTO and founder of Broncus. Broncus is a company that's 100% built using Go. I'm also the former CTO of multiply.com. If any of you guys remember that defunct social network, I've previously started and sold a bunch of technology companies. And I've lived in Asia since 2005, Indonesia since 2012. And I'm the author of quite a few popular open source Go packages, USQL, XO, Chrome DP. And I started Go Jakarta. And I'm actually also the founder of Go Manila, by the way, but whatever, which our first meetup is in like next week or something. So if you're in Manila, give me a call. So just Go Jakarta. We've got slides. This is the magic URL. So as I said, my pointer doesn't work. So here is the URL. It actually is GoGetable. It should be up right now. My slides are on there on a previous one, because I adapted this from a talk I did in January at Tokopedia. So basically, without further ado, I'll get into running Go everywhere. So as developers, we've talked about for years about the ideal, like what is the ideal development environment? Ideally, we would want some kind of magic system that ran everywhere on every platform, every operating system, every processor, everything. And it was simultaneously used very low memory, was super fast, and efficient, and easy to write, and easy to code. And you could write once and run it everywhere. So there's been a lot of attempts over the years to get to that, right? So there's a lot of attempts that have over the years to get to that, right? Java, ActiveX, Flash, list goes on and on and on. Basically, none of them have been very successful, because they have really bad trade-offs that basically prevents them from being usable everywhere, right? Because you have the baggage of a giant runtime like Java, or they just really don't run on any platform, i.e. They only really only run on one platform, i.e. COM, so COM, I mean ActiveX. And or there's just a myriad of the reasons, like the syntax is just unmanageable, unless you have a PhD in programming languages, and for just a wide variety of other reasons, which we don't need to belabor here. So basically, it kind of comes down to these reasons for why they fail, which is complexity, proprietary, not standard, not cross-platform. The developers get tired, like it takes too many mental hurdles to deal with it. Like if you've ever had to write an ActiveX COM object that's actually usable in anything but a browser, which I've actually had to do, it becomes problematic. There's just performance issues, or basically, like again, when it comes to ActiveX, there's platform exclusion. It doesn't work on OS 10. It doesn't work on Linux. It doesn't work on iOS and Android, which is important. So that said, we get to go. So go is and has been for a while pretty close to almost the ideal. It's very fast. It compiles to basically every platform, every architecture. It's got a powerful standard library that genuinely works the same everywhere because it's all written in go. It's not like Java where their standard library is written in C++, and then it doesn't work on some variant of FreeBSD, the same way it does on Windows or whatever. It's extremely efficient. If you've ever seen the native code that the actual assembly that's generated by go, it's really amazing. Engineering that's gone into goes back in is phenomenal. It's well documented. It's open source. It's extremely easy to interface with existing code, C and C++ libraries. The only real thing that had been missing from go until recently was basically a way to run in the browser. That's really the only thing that's been missing until now. And I'd like to happily tell you that if you're not aware with go, since November of last year, go will now run in a web browser in the exact same way that it runs on your console. So how does go accomplish this? And how are any other programming languages going to accomplish this in a future? There's a new standard called WebAssembly, which is basically the successor to PNACL. If you're not familiar with PNACL, PNACL is basically Google's attempt at doing a non-active x-style, multi-platform cross-browser plugin solution, and it just didn't work. The difference is that WebAssembly now has been built as a standard, and it's now actually active in more than this number has changed. It's actually 90% of browsers today, 90% of user agents today, active today as of April 3rd, 2018, is more than 90% has availability for WebAssembly. So it's supported everywhere, Edge, Firefox, you name it, et cetera. Now the point is that if we can get go to somehow compile to WebAssembly, then we can now actually use go everywhere. And in the same kind of performance characteristics that we've enjoyed as go developers for building for Linux, or for Windows, or whatever it might be, we can now use the same in the web browser. So there is an experimental branch by a guy called Neelance, that's his GitHub username. It's available right now. And this is basically the magic. If you know how to build go from source or whatever, you basically have to build go from source to do this. This is all that it takes. There's nothing else that you need to do to get go to compile the WSAM today. Now I'm not a member of the go team. I can't really try to suggest when it will be actually included by default out of the box. If I had to guess, it'll probably be 112, because I follow the go source code pretty closely. It's not in 111. So I can pretty confidently say it won't be in 111 unless they decide to make that at a last-ditch measure. But 112 or 113, so within the next six, eight, nine months, it will be there. And theoretically, you could use it today. You can use it right now and get your code just by doing this. You'll basically get a version of go that will compile everywhere. And it will genuinely truly work everywhere. It'll work in a web browser. It will work on iOS. It will work on Android. It will work on Linux. It will work on Windows, all in the exact same way. OK? And that's really what's really exciting about this to me. And one of the reasons why I'm invigorated about go in general is about the tool chain and the parts that surround go is really, to me, what's more exciting about go. Because it makes me, I've been programming for a very long time, it makes me actually excited to be a developer again, and I'm actually happy to start using these tools again, as opposed to having to pull out a JVM combination and trying to build some giant docker image or something or blah, blah, blah, blah, blah to get a deployable system everywhere. But with go, you can now genuinely truly build something that's simple, that has a simple straightforward syntax, has a very robust standard library that works everywhere. So just to give you an example real quick. So I apologize. I don't know what the audience is here. I typically speak when I speak in Indonesia. The audience there is very, very new to go. And that's why I'm speaking as if you guys are brand new to go. I don't know what your level is or not. And this talk was originally designed to get more developers interested in go and using go in general. And about getting people thinking about what you can do with go, something that's not possible today. So this is a very simple hello world using go. I'm sure you've seen something like it. The only thing I've added here is the runtime.go.os, runtime.go.arch, if you're not familiar with it. But basically, when you cross compile for go, it's essentially quite trivial. If you're not familiar with this syntax, you basically just do it as an environment variable. Do go build, output if you want, process that, et cetera. And then you could also use the same thing technically to build to iOS and Android. That's a little more complex because you have to have the Android and iOS SDKs. And this was really a demonstration to show you what you can do right now. Go has had this really amazing cross platform tool chain that's available for every installation, which means even if you're on Windows, even if you're on Linux, or if you're on OS X, you're able to simply cross compile for another system, so long as you don't have a C dependency or something like that. And that's really what's one of the greater things or more amazing things about go in general. So similarly, why is this not OK? Similarly now, if you install the WSA-enabled branch of go, you can build go run times in the exact same way. And you can actually do a go run and execute it using no JS, believe it or not. That's actually funny, huh? I think that's pretty cool. So there is a go, underscore JS, WSA and exec that's included in the go branch. If you copy that into your path somewhere and you can actually then do this, it's the go OS, JS, go arch, equals WSAM, go run. I don't know how that got messed up. That should be all uppercase. Go run, hello.go. By the way, so all of my code is online. It's available in these slides, and it all runs. It compiles. It all works. So feel free to check out my slides from the previous thing. It's gofers.id forward slash slides that will just take you to the GitHub repo if you're interested in it. So this is all that you need to do now for this magic to actually build and run a web assembly with go. Now the next thing, the next difficult task, is getting this deployed inside of a web browser. This is all the HTML that you need to then execute that generated hello.wasm file inside the browser. There's basically the wsamexec.js that has to get included. This is essentially the compiled go runtime that's been compiled to wasm. And then basically, this is the standard off the shelf prescribed weight on how to load wasm. I don't know if you're front-end or back-end developers here, but if you know anything about this, all it is is just essentially JavaScript. It's loading it using the standard thing. And you're just basically calling the compile, which is an inside of the wsamexec, which doesn't really do anything except it passes it onto the wsam handlers via the generated wsam. And then it loads it and runs it, which then gives it. And this basically binds you to this button. And then that basically, when you click this button, it will actually execute this. And it will execute it. And it'll execute using the JavaScript console. You'll see the same hello message using the runtime.go.os and runtime.goarch variables. So if you wanted to simply run this and actually had a self-compiled package of go, you could just use the HTTP.dure to serve the active directory. Or sorry, your current working directory, I mean. And the real thing about my presentation, about why I'm even bringing this up and demonstrating this and not going super into depth, is that I really want what my goal in general is with go and the community that I've been creating in Indonesia. And hopefully you guys are creating this here too, is to me, it's more important to do meetups like this. It's about getting people thinking about what's possible with this tool, with this amazing powerful tool that's been provided to us. And there are things about this that really needs to be talked about, about what is now possible. My prediction is is that there will be in the near future, there will be a cross-platform UI now that is like QuickTime, or sorry, not QuickTime. I mean QuickTime. Like QT, I don't know why I say QuickTime. I didn't mean that. Like QT, but that actually is truly cross-platform because it actually compiles directly to machine code for every single programming language, OK? Yeah, is that a question? Yeah, would you like questions in between or wait till the end? I don't really care. Whatever's good for you is good for me. I was just thinking about what you do with it. And my understanding would be that this question, is that right, that you can actually replace all the JavaScript libraries like AngularJS and stuff with the application that you write for Browser, which can interact with the dome of the browser and the event model within the browser? Yeah. Yeah, so WSN allows you to do that. And you can interface that with Go. What's missing right now is that there's not high level packages in Go that exposes that, right? So somebody would still have to do the low level work to basically bind a common package for those other languages. But so for example, if you're familiar with LiveUI, which is that micro-C UI framework, there's no reason why the Go UI package could not be modified to work similarly with WSM for connecting that. So yes, you could create a truly cross-platform React native thingy that's written in Go, but that actually compiles to native machine code and then compiles to WASM for the browser, right? You could do that. Yes, but that's a lot of work, right? But the thing is, is that this is usable in other ways right now today. So I can tell you that there's a very big, very, very large Indonesian company that is using Go on its web front end now that's basically handling back end communication with its services. I know that because they basically paid me to build it for them. So I can't really tell you, but there's only four Indonesian unicorns. You could figure out by their websites of those who have websites, right? There's only two that have web apps, right? So figure it out. So anyways, what's really cool about this is that because everything is now going to be able to be compiled to Web Assembly 2, is that you'll be able to drag along using the LLVM compiler or tool chain. I should call it a tool chain, not really a compiler. Using the LLVM tool chains, Rust, C, C++ code, these can all now be targeted also for the web browser. And they can be used in the same way from Go code that's been compiled to WSM. So for instance, TensorFlow could run natively inside the browser, right? If somebody did the work to get it there. And when I say that, I don't mean that in an off-hander say, oh, well, just go write that, right? Just go write a rocket ship. That's not my point. My point is that the hurdle to jump is now no longer seven meters tall. The hurdle to jump is now two inches tall, or two centimeters tall, keeping with my metric theme. So the point is that we're very, very close to that. And that's the thing. And my whole thing with this presentation is really start thinking about this. Because this is something that is super exciting to me as a developer. I've not been this excited about the possibilities of a programming language in like 15, 20 years. I mean, it's just been freaking forever for me that I've actually been excited about something in a truly new and unique way. And so you'll get this, right? I think we'll get there at some juncture. Well, whether or not the web matters in five years is a different question. But who cares? So that's basically my presentation. Oops. I have go-to-carta stickers for you guys, if you're interested in them, a little tiny gopher's. And that's it. And then just a prayer for developer CVs. We're hiring for all positions, developers, front end, back end, whatever. We don't use WASM on our front end. We use TypeScript. But we're looking for really amazing people. We're a 100% remote company. And so apply if you're interested. So I just happen to be in Indonesia because that's where I live. OK. All right. Any questions? Questions? Seeing none. Maybe I want to get more about the model. What about the command object model? So yes, WASM can absolutely interface with the doll. If you didn't want to have it as completely low level calls, though, you would have to write some kind of high level package. So Neelance, the guy that did the port for the back end that compiles the WASM, he's actually the author of, is it Go4JS, I think? And they have a, I imagine that his packages from Go4JS will be moved over so that they can be used from the WASM build essentially. But that, yeah. So the point is that yes, you can definitely interface with the DOM, but somebody would have to write a package. So oh, my other message. So one of the things that I wanted to do this with Indonesian developers is that Indonesian developers, their average age is like 17. I mean, they're super young. One of the things that's been kind of disheartening for me as a developer is, I'm not old, but I'm not young either. The thing is, is that every time I had a great idea, it turns out that Linus had already implemented it. So what was I supposed to do? So one of the things is that if you want to make a name for yourself as a developer, you have a lot of great opportunity right now. There's a lot of work that can be done that's super easy to do. If you want to prove that you have coding skills, as an example, picking up the DOM and making a high level Go package for working with the DOM would be a perfect way to show your skill set as a developer. So just keep in mind. So any other questions? Yes. What is it you hate so much about JavaScript and TypeScript? I'm excited about it. I don't hate them. I speak in hyperbole if that's not obvious. No, I don't hate it. It's just that if you've ever had to deal with Node.js, and if you've ever had to deal with NPM, I mean, I don't know how many more left pad, or right pad, or middle pad packages we need. So it's just I think every programming language has its kind of time that it's in the sun, that it's really amazing. And then eventually, CPAN happens, and they all die. Is CPAN still alive? Sorry, CPAN. So look, programming languages that were great, that have all the same problems. I can name basically all of the programming languages that exist that are popular, have that same problem. It's basically package management, and it sucks, which is really why I hope that Go never really has a true package management solution. I don't even want to talk about the philosophy of the new stuff that's coming in. But every great programming language that existed was great until the community went out of hand with a bunch of crappy, badly written, poorly written packages, right? So Perl's the first example, CPAN. But look, Python, pip, easy install, whatever. Pip two, pip three, pip 17, whatever, right? I mean, if you are in the world of trying to build correct, repeatable builds, which is what I have been doing forever, this is a problem. Which is why a lot of people prefer CNC++, because there's never really been a package solution for CNC++. But it goes beyond that, right? I mean, Ruby's gems are horrible, or bundler. Bundler and gems is horrible. It's the same problems. Because it's not so, this is a philosophical question outside of the scope of tonight's discussion. But I do not believe that it's fundamentally a problem that can be solved, which is why nobody has solved it. If it was solvable, it would have been solved a long time ago, right? But, yeah. Getting back to that question, I think something that strikes me again in the game when I use code is that this language was actually developed for the stuff that I want to do. It is writing applications in the times of internet. And many of those other languages that we use, they were developed for something else. And then they just came to some fame, because someone wrote a great library that you could use for it. And then it was kind of listed. Some Java was made for second boxes and code. Sure. The only real application that Java has is Android. Right. That was intended to do stuff like that, but not big solar applications going on. I think Java was a super popular way before Android, though. Yeah, yeah, yeah. I mean, but, you know, they changed their mind. Somewhere in between, they met with a guy who told them, hey, you should do this for the internet, not for the setup. Because they failed to see who sent us. They didn't like it, right? So then they had to be sick, otherwise the percentage of it was there. Right, no, I think, yeah, it's just... And then they were happy, and they said, oh, we're going to integrate it into the state. And then suddenly everybody looked at it. Ooh! You should come do a presentation on why Go is awesome. We're very happy. Hey, I'm so speaking. You guys ever do come out to the car, and you want to do a presentation on Go, let me know. One of our hardest problems is games for you, so... Please draw me a line. My name's Ken Johnson. I'm not... I'm not... You know, check if I'm fine with this. Okay. I think I... Wait...