 So, hi everybody and welcome to the Gold Dev Room of FOSDEM 2018. We have the same room that last time, which is too small and it's still pretty small. So thank you so much for lining up and like being patient and being nice to the people at the door. We're trying to be nice to you too, which is hard sometimes. Anyway, so we're going to start the Dev Room with the State of Gold, which I've given a bunch of times. And we're going to be talking about where we are today. Which is almost, almost releasing Go 1.10. We're still not there. So I'm Francesca, I'm probably by the way. I used to be a developer at Bucketagoo Cloud Platform and the Go team. And now I work as a VP of Developer Relations at Source, which are the ones doing these t-shirts and all the cool stuff and we are hiring. Now that I've said that. So Go 1.8 was released one year ago here at FOSDEM basically. And Go 1.9 is already nine months old. And if you don't know what it's new in Go 1.9, there's a lot of cool stuff that I will not cover here. Because there's already enough stuff in Go 1.10. So we're going to be talking about Go 1.10, which is already out, kind of. There's a release candidate one that was released in January 25. And you should check it out. It's very easy to download. Also, you can try it with Docker directly if you want to try it. And we're going to be talking about all of the things that we released in Go 1.10, which is not much, but there's actually a lot. You will see why. And yeah, Go 1.10 will release soon. We don't know when. The slides are online if you want to check them out. It's campodocad slash L slash SOG, state of go, 110, 110. If you go there, the playground grounds go on the nine. So some of the examples will not work. Do not file issues. It's expected. That is what happens when you do these kind of talks. So the agenda, we're going to be talking about the language. All the changes to the language. All the changes to ports, so all the architectures that we support. The tooling, the standard library, performance, and the community. So changes to the language, nothing. That's it. There's some small changes in the, like, basically changing the specification for some ambiguities that we had. But that's it. There's nothing new, absolutely nothing. So that's easy. Cool. And then the second section, ports. What other architectures are we supporting that we didn't support before? None. But here there's some changes. So for all the BSDs, we are limiting to what version we're supporting. So if you're using one of the BSDs, please check the constraints that we're adding. Basically you need to use something slightly newer. Also for OSX, we're going to need to require also your submitting. So the next version will require just sanity. So this is basically a warning. Go on dot 11 will not support your sanity, so you'll need to upgrade. But being how aggressive Apple is at upgrading, I'm sure you will. Also Windows will not support Windows XP or Vista. So if you're using those, yeah, sorry. There was a really good burn on that bug basically saying if you're using Windows Vista, you should not be worried about security upgrades on go because it's Windows Vista. But anyway, oh yeah, this is the sick burn. So it said, I will not say who said these. I'll just leave it this way. You can find it. It says you won't get secure fixes. But if you're running XP, you're not worried about that. So that's pretty funny. Okay, changes to the tooling. And here there's way more stuff. All of the changes can be divided into two sections. It's easier to use and also everything is faster. So what is easier to use? If you remember, go path became optional in go on the date. Now go route is also optional. And it's basically reduced from the binary location. So that means that if you download go and you run it, it works. That's it. You don't need to set up go route, go path or anything like that, which is pretty useful. So we added a variable to check where you want to create your temporary directories. It's called gotemdir. You can also control it with temdir in most OSes. But it's being created if you think it's useful for you. Other than that, everything is faster. This is actually really cool. So when you do go build and go install, all of the things that have been compiled that are in our binaries, because all the binaries end up in the bin directory, all the packages that you compile end up in the package directory. That is not true anymore. Now what happens is that those compile packages are cached. And only the ones that you actually ask to compile, so if you say compile, I don't know, trying to find one, let's say OS. And OS requires IO. OS will end up OS.A will be in the compile somewhere. But IO will be implicitly compiled. So you will not see it. The important thing is that these caches are now kept, which means that if you compile again, you don't need to recompile all of the code. That's what go build-i used to do. If you use cgo, Paul, you've used that before, you don't need to do it. It's already implicit, and it works faster all the time. Similarly, you get caches for testing, so not only for the building, but also for the execution of tests. And these are actually done in a quite smart way. So the tests are cached as long as the old environment variables that the code checks did not change, that the file system did not change, and things like this. So your test will actually run when necessary. If you want to force it to run, you can say dash count equal ones equals one, and that will force to run the test once, which means no cache. Also, we added vet. So when you do go test, if you have something that, for instance, is, let's say, a printf with a format that has more parameters than the parameters you're passing, your test will fail, which is new, which means that some files will test, but your code was wrong. So that's not breaking all that one comparability. What else? Cover profile supports now many packages at the same time, which is cool, because it means that you can run your tests faster, too. You can create one single profile coverage for all of your libraries, which is pretty nice. Also, fail fast to stop all the tests when one fails, and dash JSON, so you don't need to parse the output of tests anymore. You can just read JSON, which is nice. And that's pretty much it. So a small detail. How many of you know what a three index slice is? Not that many. Cool. So that's why I'm going to explain it, because it's actually something interesting. So when you write code, you have some text here, which is a slice of bytes that says hello for them. If you call desk, I'm just printing the value of the capacity and the length. And you get from 0 to 5. And you get the capacity and the length. You're going to see that you get the length is 5, because it says hello, but the capacity is 16. That capacity means that from this slice, hello, I can access the rest of the slice. So if I append something, I'm actually overriding the original slice. And that's something that it's not something you want to do many times. If you're sharing pieces of slice, you might want to say, this is your piece of slice. You cannot overwrite outside this. In order to do this, you just add this 5 here. That 5, what it does is to says, I'm getting the elements from 0 to 5, and the capacity also goes up to the element 5. Now if you do that, when you append, you're actually appending on that slice that is already full, so you reallocate somewhere else. And you do not overwrite the previous slice. There you go. So now, hello, FOSDM did not change. Now that we all know this, changes that have happened. So GoFont has changed the way it formats this expression. I do not think that many of you use it, but if you use that expression and you're checking for GoFont in your integration tests, it will fail. It has failed for me. It's just one test. So it's not huge. It's only one repo fail. But it might happen to you. There's some explanations on why you should not be doing the GoFont, making sure that the output matches, and stuff like this. I think that, well, it's kind of painful, but that's how it is. Also, it's better now. It makes way more beautiful. I think you're OK. There you go. Now we're going to talk about the changes to the ThunderLibrary. There's nothing really big. There is no new packages. How many of you remember what was the last package added to the ThunderLibrary? Yes. Bits. There you go. So yeah, you get a t-shirt. I mean, there we go, I get a t-shirt. We have not added any more packages. There's nothing in there. But all of the packages we have, we have added some stuff, and actually some things that might be very useful for code that you're writing today. So let's go back to the same example as before. So now, instead of saying from 0 to 5, what I'm doing is I'm getting fields, which is give me the first word, basically. In Go1.9, the slides you were getting had the capacity to override the previous one. So if you overwrote, if you run this on the playground, and the Wi-Fi works, yay. So if you run these, you're overwriting hello fuzz them because the capacity is 16. If you run this with Go1.10, the capacity is 9.5, and you don't overwrite. So that's a change that might be kind of tricky. So if you're using fields, fieldsfung, split or split after, and you're trusting this capacity of being able to override outside of the slides, which is kind of weird, it will break. So take that into account. Also, there's a minor change to flag that makes me really happy. It's incredibly minor. Nobody cares about it, except for me, probably. But I do care. In Go1.9, when you had a description that had, thank you, that had a line break, it would print it like this. Really ugly. That line is not with a line. Now it's well aligned. Thank you. It's really important. Also, there's changes to Godoc. These are changes that is in between the standard library and also tooling. It's a little bit on both sides. Basically, until now, you know that in the documentation, when you have a new foo that returns that point to foo, when you look at the documentation, you see it tied to the foo type. You see foo and new foo. But if you are returning a slice of foos, that was not tied to it. Now it is. So in the documentation in Godoc, you will see it slightly differently, which I think makes more sense. But also, if you're using the Godoc package, you will see that those functions, rather appearing at the package level, will appear at the type level. So if you're depending on that, that might break. But again, I think the change that totally makes sense. So yeah, before you would see func many things, which is completely related to the type thing, now you will see the type thing has two constructors. One is many things and one is new thing. So it makes a little bit more sense. Changes to text and plate. And this one is interesting. So you've all used range or a for loop, I'm sure. And you have continue and break. Now you can also use those in text and plate, not on HTML template. And I do not know why. But that's how it is. If you try to run this on HTML template, you will get an error saying, this has not been implemented. I don't know if it is because they don't want to implement it or because they're like, we don't have time to implement it. That's it. Sheep it. So this I'm ranging from 1 to 10. And what I'm saying is, if it's even, print even and continue, which means that it will not print odd. Otherwise, it will print odd. And when we get to five, we'll break and finish the loop. So if we print this. We can add odd, even, odd, and we're done. Is there any water? No. There's a bucket of water, thank you. That is very useful. Very useful people. That's OK. OK, this is the change that I care about the most, I'd say, in all of Go 1.10. I'm sure you've all used bytes buffer as a way to create strings. Basically, you create it and it has the write method. It's a writer. And then you can use fprint or fprintf or fprintlend to write stuff into the bytes, into the bytes buffer. And then at the end, get the string. So you get the bytes buffer. You print hello, fos, then go first to the buffer. And then buff.string will print it. When you print this, you will see that I actually also added how many bytes we allocated. We allocated 856 bytes to do all of these things, which is a lot, but who cares? It's mostly the string. So now you have the strings builder. And the strings builder basically is a specific solution for the case of building strings. So it does not have all of the power of bytes, but in exchange, it has more guarantees. So one of the guarantees that it has is that it doesn't need to do a copy of the string every single time you try to get the string from the bytes. From a slice of bytes to a string, you need to do a copy because a slice of bytes, you can change it. A string is immutable. So you need to do a copy to ensure that that happens. With the strings builder, that bytes buffer is not accessible. Therefore, you don't need to do those copies. You know that those strings will never change, because you don't have access to those. So when is this good? So if you're doing something like this where you're adding emoji or anything, you're adding a piece of string to a bytes buffer, and you keep on adding more and more, and every single time you convert that to a string, you're actually forcing a copy and allocation of that string over and over and over, which means that if you get a benchmark, you're going to see that that's allocating 10,317 bytes. If you change that to instead being a bytes buffer to be a strings builder, you go to 22 bytes, which means that also it's way faster. It's like 30 times faster, something like that, which is awesome. Now, if you're not doing that, it is a little bit worse than bytes buffer. But this is the case where you're just adding more stuff and basically doing that allocation at the end only once. So it really depends on what you're doing, but I'd say take it out and do benchmarks and make sure that it might be better for your code, in some cases. So do not say, oh, Frances said we should just use it. No, but check it out. Unicode, we have all of these beautiful emoji. So there's 56 new emoji. I know, thank you. It's not me, it's Unicode. I think it's Unicode 10 or something like that. It has 56 emoji, you cannot see them, but I prepared the top, my favorite ones. So you have Chinese food, which I love. So you have takeout and fortune cookie, and also, I forgot the name of the thing. Gyoza, sure, Gyoza. Also Argentinian people say it's empanada, sure. Curling, because it is really important. At T-Rex, it is, I think it's very cool, to be honest. Mind blown. And the most important one, which is not emoji, but it's a UTF-A character that we didn't have before and everybody was dying to have it, was Bitcoin. Yes, you can now write Bitcoin as a character in Unicode and Go 1.10 supports it. My Mac doesn't, though, so. Yeah, it's a pity. Okay, performance changes. This is fun, because I should have prepared this top with way more time, but I did not. So I ended up doing this yesterday. And by yesterday, it might be this morning. So I checked the benchmarks between Go 1.9 and Go 1.10 on runtime, and they're pretty much the same. To the point that I removed all of the benchmarks that had actually significant changes, and all were gone. So either I'm totally wrong, which is a possibility, or they're actually basically the same speed, which is not shocking, because I don't think there's been that much work on performance for these pieces. For the compiler, though, I was completely mistaken. I thought that this was the runtime, if it was like this way slower. But these actually, if you don't know how to read it, it's not important. The important thing is the last number, is how long it takes for the Go compiler to compile the standard library and all the commands. I go from, go vet, and all of those. And it takes 10% less, so it's 10% faster than before, which is cool. It's not huge, but if you get in 10% performance boost on all of your compilations, not running, but compilations, that's pretty good. Also, garbage collector. Every single time I've done this talk since Go 1.5, I've added the same tweet, the same tweets, actually. Brian Hadfield has this thing from Go 1.5, when he's been tweeting the pause in the garbage collection of his servers every single time he was going to the Neo version. It went from 300 milliseconds, which is crazy bad, to around 100 or something, no, around 30 or something. That was from Go 1.4 to Go 1.5. That was when we actually gave a talk about it, because like, look at this. Then from Go 1.5 to Go 1.6, we went from 40 milliseconds to four milliseconds, which is pretty amazing. From Go 1.6 to 1.7, we went from around three to around one millisecond. Then to definitely under one millisecond all the time, with Go 1.8, with Go 1.9, it stayed pretty much the same. And then with Go 1.10, I was like, hey, Brian, you have not done it, I'll give my talk tomorrow. Uh, this is yesterday, by the way. It was like, could you please do this? And so this one's like, and he's like, hey, so I'm running a canary now, but you know, it's late, so whatever. And it was like, oh, if you can do it. And then I said, can I use this screenshot? Because you know, I'm a good person. And he said, yes, and he says, hi. And then I went to bed. And then this morning, he actually tweeted. And he said, yeah, cool. So he said, it looks basically the same. It's not, you know, amazing story, but he tweeted. So he's a very nice guy, so thank you, Brian. He'll be in the video. So thank you, Brian, for this. There's a couple more changes. You can read those. You can go to the Go 1.8, no, 10. Go 1.10 release notes, they're already public, just not on goland.org, they're on beta.goland.org, or tipgoland.org, same thing. So changes to the community. This is Women Who Go. They have now 26 chapters, which is amazing. They had 16 last year. I redo this slide every time. And this time I actually made the map so I can reuse it, which is nice, for the first time ever. I'm not just using paint. I was using paint. So this is really good. They're all around the world, which is amazing. So if you are a woman and you're a go, you should join one of those chapters or create anyone. Also, they have a new board of management. I don't know how you call yourselves. New C-suite, I don't know what that means. But oh yeah, because they have C's, there you go. Yes, so March, she's here and she's one of the organizers of the room. She is the CEO of Women Who Go. Veronica Lopez, that she's still not here, but she'll be speaking later, is the CEO, no, the CFO. And then we also have Daniela Petrosak and Carolina Athletic that are also helping with new chapters and the head of support. So that's amazing. So congratulations to the four of them. And then we have all of the Go Meetups. And Go Meetups, they're really all around the world. They're really cool. There's one in the middle of Russia. I was invited once, but I couldn't make it. But if you wanna go somewhere random, go in the middle of Asia. There's one Go Meetup there. Then this slide still fits in one slide, but it's getting really crazy. These are all the Go Devrooms that are happening soon. So we have Go Devroom Fosden, which is today and here. Congratulations, you're here. Gophergon India, which is in March. Russia in March two. Go SF in March two. So if you wanna travel, March is a good month to travel. Then April in New York, May in Singapore, junior Reykjavik. The organizer is somewhere there. There you go. And August in Denver, September in Florianopolis, October in Florence, and then Doug Go has moved a little bit farther away. So there will not be 2018, there will be 2019 in, not the other way around. 2019, I'm mistaken with the years. That's 2019 next year. And also we have a bunch of talks today. At the end of all of these talks, we'll have a lightning talks. So Marja was working on, we'll give the link to a forum where you can apply to give talks. If you're gonna give a talk, there will be a five minute talks really short, but you can give something cool, some ideas or some project you'll be working on. We're definitely interested in listening about it. And that's it. Enjoy the rest of the day. And thank you very much. And.