 Okay, welcome everyone, this is Lother. Hi, welcome to the Gold Devroom FOSDEM 2019, bigger than ever. So congratulations, you made it. Yes. Yes. So we're going to start with the talk that we start every year, which is the state of Go, that covers everything that has happened since the previous FOSDEM. So if you want to follow the slides, they're already online. They're in a bid that SOG is for state of Go, FOSDEM 19, so you can go there and follow along if you want to. I'm going to give you two seconds to take a picture. And done. So that didn't work, but those are supposed to be my name and her name. Let's fix that real-time. So fixed. So yeah, so I am Francescampoy, VP of product at Sourced, and then my second speaker lost her voice. So please stand up, say hi. Yeah, Margie couldn't make it, but big shout out to her because most of those lights are made by her. No, okay. Okay, cool. Continue. So we're going to be talking about everything that happened since last time I gave this talk, which means Go, 111 and Go, 112. Go, 111 was released in August 24th, 2018, and Go, 112 was released in sometime soon. And every single time I give this talk is always sometime soon, but a release candidate is already out. This time, not even a release candidate is out, only beta. Beta 2 was released in January 10th, and you can check it out, which means that if you run some of the code on the playground, it will not work, because the playground is still running Go, 1.11. So just so you take that into account. So the agenda is going to be, as always, we're going to be talking about the changes to the language, the standard library, the tooling, and finally the community. Also, big shout out to all of the drawer, like all the artists that made the gopher, all of their names will be at the end. And this died too. Cool. Did my laptop die? Yeah. Okay. Cool. Oh, my God. Okay. So changes to the language, what has changed in the language since 20, since Go, 1.10? Nothing. And yeah. So that is a feature of Go. We do not break things unless we really have to. We do not things unless we really have to. So that's why there's a really good talk by Bradford's Patrick called Go is approaching asymptotically boring. That's a goal. So one of the changes that we have, standard library. In the standard library, we have two breaking changes. So those are the important ones that might break your code. The first one is the fact that when you're passing a typed interface to an implicit skipper in the HTML template package, instead of getting an escaped version of nil, you will get nothing. What does this mean? In code. So if you pass a pointer to an integer to a template, before it was printing that escaped version of nil, which is like, we know you're inside of HTML. We don't want to have an HTML tag. So that's why it's escaped. Now it will not print anything except that in all of my tests, it still prints it. So yeah. So I asked Bradford's Patrick and he said he doesn't know. So yeah. So the other breaking change, which actually broke things, it's Baphio. In Baphio, now when you call unread rune or unread byte after doing peak, it will fail. So this means that in this code, for instance, we're reading from a buffer reader. And we're doing peak of one that will get the first character of the thing, but it will actually not read it for real. It will just look at what it's next. If you do unread after that, previously, it would just work. And the problem with that is that in some weird random cases, that would fail. Now we will always fail. So you will see things like invalid use of unread byte over unread rune more often. So if you see that error, take into account that that's why. Your code was already wrong. Now it's wronger. So other interesting changes, all the things that have changed to the Sunday library that might be interesting to you. You can now assign variables in templates. This is new. Previously, you only could declare variables, but not change their values. Now you can do that too. So in this example, this v equals change. That's something that was not a thing before. So if you want to do it, if you find that useful, you can use it. I find it quite useful for debugging templates. You can have something at the beginning that says, if debug changes variables to something else. So it's pretty useful. Other than that, I don't think it changes much. It's still something that I would rather personally avoid. Something else. Replace all. Replace all is a new function in two packages, bytes and strings. And basically it's the same thing as replace with a minus one at the end. But that replace with a minus one to say replace all of them was confusing to beginners. So it has been changed to be more obvious. Replace all replaces all of the things. Replace minus one is kind of weird if you think about it. Also if you print maps, they will be sorted. So what does this mean? No, don't be so happy. So it is not as cool as it sounds. So this means that previously if you wanted to print a map sorted in order, you had to do this. You had to get all of the, so you get the map. You iterate over all of the keys. You put them in a slice. You sort the slice. You iterate over the slice and you get the keys. The values are attached to the keys from the map. Now this is complicated. But now you can just print the map and it will just work. But this is only for printing. If you iterate over a map, the order is still random. So do not try getting things in order because that's not go. And that's actually good if you know why Java hashing functions are a good way to start reading about the hell that you can get in there. So go doesn't have that. So that's why that will always be random. But now you can print them easier. Why did we do this? Because of tests. So now when you print two maps, you can actually compare whether they look exactly the same or not. That's the only reason. We also get TLS 1.3 support in the Santa library. Except that not by default. So if you want to use TLS 1.3, you actually need to, on the config, you need to change max version to that value. TLS version, TLS 3. 1.3, sorry. Also, zero RTT is not supported. Quick question. How many of you know TLS 1.3 as a thing? Okay. Not many of you. How many of you know what zero RTT is? Okay. Everybody that knows 1.3 knows we do not support zero RTT yet. But also, the whole point is that this is TLS before. And you can see that the green stuff here, you have client hello that sends server hello. And then it sends back a certificate. And then we verify that their certificate is correct. And then we send another thing saying, hey, these are the cipher suites that I support. And then the server says, okay, let's use this one. Now, in TLS 1.3, so yeah, those are the two things that we're doing. In 1.3, what we do is we send hello, these are the cipher suites that I support. And the answer will be great. Let's use this one. This is my certificate. And then we verify. So we're basically removing one return. Also, eventually, we'll be able to cache that information. And that would be the zero RTT. So we'll be able to connect directly without having to have any handshake just start sending the information, which something that's not supported yet. Also, the point is that there's only secure cipher suites. But that's what people said about 1.2. So eventually, we'll have things that are not secure. Okay. So what else? Reverse proxies. And I know there's a talk later about how to write a reverse proxy in 25 minutes. This is about how to write a reverse proxy in one slide. So this actually works. And the new thing is actually not the fact that reverse proxy is so easy to do, but rather the new thing is the fact that now it also supports WebSockets. So if you have WebSockets in that website in there, my IP.minja, which is something that March created, you can just use WebSockets directly there. Nothing needs to change. It's really nice. Tooling. So what change in tooling? Bunch of things. First thing, go run of a package now works. This is cool because this means that you can actually run that line to someone that doesn't know anything about Go, but they have Go installed, obviously. And it will just work. It will download all the code. Find that there is a package in there that is a binary. Find the main.go and run it. This also works for directories. So go run dot works. This is cool. Previously, you had to do go run star and hope for the best that you were not putting random stuff in there. So this is actually a pretty good improvement. It's pretty simple, but if you've ever dealt with that go run main.go, oh, this function is not defined because it was on the second file. You don't need to do that anymore. Go run dot will do it. Also debugger count now run functions. So, oh, this goes too fast. So basically when you're printing that IP, previously you got all of that random stuff. Now you can actually call the string method. And when you call the string method, instead, you will get that value there, which is what the string method returns. So this is pretty useful. It is pretty limited. There's many things that you cannot do inside of that function. And it only works on Linux except that that screenshot is from my Mac. So it also works on Mac, but probably not as well. So you can try it. And also, yeah, there's a bunch of different constraints. You cannot stop. You cannot create new variables. You cannot stop all the other routines. This is actually something that was before the same way. And also, you cannot just stop anywhere and run a function. You need to stop it with a break point into a safe point. You cannot just stop and run something. You will not work. Go doc. So how many of you know the difference between go doc and go doc? Cool. Three people. So, yes. So go doc and go doc. We're basically the same thing. Now, there are actually several things. Go, so go doc is the one that you should be using. Go doc is an HTTP server for go doc with a space in between. It is hard to pronounce. But basically, the cool thing about this is that now you can do go doc-htp equals whatever and see the documentation as it would look like once you have it on GitHub and you access it through go doc.org. And for everything else, you do go doc. Also, dash all on go doc will make it feature complete with go doc. So everything that you had before will work there. Just read it. It's hard to say go doc and go doc and make it sound different. Something cool, though, and I don't know if you can read this very well, but in go doc, which is the binary that's an HTTP server, you will be able now to see in what version something was added to the standard library, which is pretty cool. So here you can say client trace was added in 1.7. And then that field in that struct was added in go 1.11. And if I see this, my first reaction is like, wait, that breaks backwards compatibility. Well, I tweeted about this and Brad Fitzpatrick referred me very nicely to the specs, telling me that for the additional features in later point releases, it may be necessary to add fields to explore a struct in the API. So these actually compatible with the backwards compatibility of go, which means that when you're declaring things, you should always use the field name in the struct. Otherwise, your code could break with newer versions. So that's why you should be doing that. Because otherwise, if you just pass all of the values of client trace, and then you get to go 1.11, your code will break because there's a new one. GoVet is deprecated. So go to that does not exist anymore. GoVet is the thing you should be using. How many of you have ever used go to that? Okay, so stop doing that. It is not it is exactly same as go that go to that was there for all reasons. And you will get also a new mistake. That code is correct. But if you remove that 42 in there, previously, it will not complain because actually it's not able to figure out that those parameters are passed to the print f. Now it will actually detect and it will say that wrapper format percent s reach argument one, but call has zero arguments. If you are missing that 42. So a little bit more, a little bit smarter error detection in GoVet, which is always good. Then with 10 minutes, we're going to be talking about modules, web assembly, and some more stuff. So modules, modules are great. Why do I think they're great? Because they remove the need for go path. That is, I think, great thing. Why are they also good? Because they allow you to do modules. For me, the secondary thing, it's something that allows you to have third party dependencies manage similarly to go depth is not that different to be honest, but it's just a little bit different. It's actually integrated into the go tooling. So if you want to know more about that, shameless plug. I have a channel on YouTube just for fun. And there's two episodes that cover this exactly. They cover the intro to go modules. And then so as a user and then another video, if you're a maintainer of a package and you want to start using modules and how to migrate to V2, V3, et cetera. So those are probably the places you're going to see. In total, it's over one hour of video. So I don't have time to do that today. Runtime trace. So if you've ever used the go runtime tracer, which is super useful, you may have seen that it generates events for every single thing that happens. If you declare a new, if you start a new go routine, or if you block in a channel, or if the garbage collector starts or whatever happens, all of those things are locked. Now you can log more stuff. You can log your own things. So that's pretty useful if you want to manage your own code and understand what's going on with things that may be like an event that is not something runtime, but rather something that you personally care about, but not in general. If you want to know more, I actually found a very good blog post. So it's bit.ly slash go UD trace for user defined traces. And it's probably a good place to check it out if you've ever used tracing. If you've never used it, it's not that important, but it can be useful for people that are doing things like open sensors at scale. Here you can do it at less scale. Just one binary and get the same idea. And then changes in the runtime. I wanted to give a shout out to Miguel for this drawing because that toaster just kills me. So in performance changes in performance, not much, everything is a little bit faster, but there's not actually any performance, any benchmark out or anything that is official. So I actually found something in one of the, I actually forgot what package this was. Yeah, no, I forgot which, this is one of the big libraries that uses go. I forgot which one it was. Sorry. But basically from 1.11 beta to everything was a little bit faster and go 1.12. Everything is supposed to be a little bit faster. But unfortunately, there's no official benchmark. So try it on. Also, if you've seen this talk before, I used to have these screenshots of the same guy over and over migrating heat change companies. So he cannot do that anymore. So it's sad. Then new ports. So there's a bunch of different things. Go 1.11 will only works on open BSD 6.2 or later. Open BSD 6.4 only works on go other 11 and later. Go on the 13 on Mac OS will require 10.11 or later, which means that go 1.12 didn't break anything, but go on the 13 will. So if you're not, if you're doing things on Mac for 1.11 for 10.10 or before for Mac, you will be impacted. Go 1.12. The last release is the last release supported on free BSD 10.x and runtime R64 is now faster. Windows ARM supports Raspberry Pi 3 and RISC V, which, or RISC 5, which personally, I didn't know what it was, but March it was very, very excited about having this. And apparently there's a deaf room about this. So I should learn what it is. And going to hurt our reserved values. What does that mean? Nothing. It means that maybe there's some work that's going to be started, but it has not been started yet. So it's maybe in the future. There's one more port that is super exciting, which is WebAssembly. So you can compile Go to WebAssembly. And this is something that works since go 1.11. And it is awesome because it allows you to run Go on the browser. Like you could do before with Go for JS, but personally I think that this is easier to use. I know how to use this. Go for JS. I gave it a try or two. It was actually kind of hard to get started. Once you know how to use it, it's actually very nice. But this is easier to use because it's actually a port. So what you need to do is say the Go OS or Goose is JS for JavaScript. And the Go architecture or Goarch is WASM, which is a shortnet version of WebAssembly. And it will work. I actually have a super mini demo of this. So we have, ooh, that's small. That is too big. Okay, so we have that code. And I can do make run. These will compile a couple things and start my server. And then I can go back here. This is going to be mind blowing. You've been warned, okay? So if now I go to this, that was printed from Go. Thank you. So if you want to do more complicated things like interacting with the DOM, there's actually a new package under syscall, syscall slash JS, which is experimental. And I have not tried it. So give it a try if you want to, but it might change in the future. It's not tied to the backwards completely of 1.x yet. And personally, I think that this will be great to be able to run Go on the browser, but called from JavaScript. I think that probably the best way to interact with the DOM is still JavaScript. But that way you can integrate with Go much easier. And now let's see if the Wi-Fi works. Cool. So community. They're all cheating because they all have the same cards. But whatever. So five years ago, how many of you were here five years ago? Okay, I was here too. Not many of us. You might remember that was this picture makes that room look bigger than what it was. This is actually a very tiny room. There was no stage. So that was pretty good. It was a good start. Last year, you might remember this. Oh, it's not going to have the audio. Wait a second. Sorry. Yes. So that was last year. Everybody complaining about the fact that the room was too small. And this was this morning. It's coming. Yeah. So thank you for them for a bigger room. Very happy with this. All the things that have changed, so women who go keeps growing. They have six more chapters than in 2019. So they have now 30 chapters. And they're in many, many places. But still, if you want to create more chapters, do that. We need them. We need more chapters. And also if you're interested in starting one, there's two people in here that might help you. So please, there you go. They're part of like, they're like the managers of women who go like they're really important people. So talk to them. Go meet us in the world. They're all around the world. Also, you might see that some of them are not clustered. I want to go to those. Those are the cool ones. But they're everywhere around the world. I didn't count how many you had, but basically everywhere. And then Go conferences. So we have Go Devroom 2019. Hi. Then Dot Go is going to be happening soon. And we have the organizer right there. We have Gotham Go that is happening in New York City, April 12th. And I will be there. My talk was accepted. GopherCon Singapore, I will not be there because it's very far. GopherCon Europe is going to be in Tenerife. It's a little bit nicer than Brussels in February. So it's a good move, I think. GoCon in Canada and GopherCon then in San Diego. And GopherCon San Diego, I will not be speaking, but I will be there for sure. This is going to be super cool. How many of you are going to GopherCon San Diego? Okay, not many people, which makes sense. So again, those lights are here. You can check them out. I'm going to give you two more seconds to take a picture just in case. What else do we have today? We have many talks. So this was the first one. The next one we're going to have is, I'm going to say Serge, but I'm not sure how to pronounce it. Close enough. And then we're going to have a bunch of different talks. Many, many, many, many, many, many talks. So stay around if you want to attend, because getting back into the room is going to be hard. And also we have Go Lightning Talks at the end. So if you want to register for those Lightning Talks, the link is bw slash golight 2019, which is also right next to the not creepy Gopher. And we will have the deadline is at 4 p.m. So make sure you send your ideas before that. You have only five minutes per talk. Those five minutes will actually be four minutes and 30 seconds after which I will keep you out. So you've been warned. And that's it. Thank you very much.