[00:00.000 --> 00:12.800]  Good morning everyone. Finally I can hear you again after two years online where I just
[00:12.800 --> 00:19.320]  had to stare at a boring matrix chat. I am honestly so glad to be here and welcome everyone
[00:19.320 --> 00:34.200]  back. Just like every year we are starting with an update with the state of Go. We are
[00:34.200 --> 00:38.960]  going to talk about what is new in Go. I will quickly touch on some topics. The interesting
[00:38.960 --> 00:44.400]  things about Go come in later talks. So what I am going to look into today is change the
[00:44.400 --> 00:48.960]  language as well as the standard library, tooling of course. I got two interesting design
[00:48.960 --> 00:54.400]  drafts for new releases in Go and of course an update on our Go community. What is new
[00:54.400 --> 01:00.840]  in Go since Go 180? Well of course Go 119 was released in August of last year. Go 1.20
[01:00.840 --> 01:05.280]  was released a few days ago. It is just the first time that they released a Go version
[01:05.280 --> 01:11.280]  before I do this talk. What are the big new changes? There are four new changes to the
[01:11.280 --> 01:16.840]  language as the most we ever had. However one is not really a change so it is more like
[01:16.840 --> 01:22.520]  two and a half changes but actually more like 2.25. Let's just keep it there. Two real
[01:22.520 --> 01:27.640]  changes to the languages addition. The first one is that there is a new syntax for converting
[01:27.640 --> 01:31.760]  a slice to an array. Those of you who are new to Go might be confused because what is
[01:31.760 --> 01:35.920]  the difference between a slice and an array? I call them both arrays. Well technically in
[01:35.920 --> 01:41.960]  Go an array has a fixed length and the slice does not. That is too easy to say it is not
[01:41.960 --> 01:48.000]  correct. But you can go verb between those two and you could have done so since Go 117
[01:48.000 --> 01:53.280]  using this ugly syntax which has to do with pointers and how it works underneath. I would
[01:53.280 --> 01:59.520]  have never come up with this myself. But in Go 1.20 it is more logical now. You can just
[01:59.520 --> 02:05.280]  make an array with a fixed length of 3 and put your slice in it. This now works. The
[02:05.280 --> 02:09.840]  next change has to do with generics which were introduced just last year. It has to
[02:09.840 --> 02:13.880]  do with a comparable constraint which we could give to variables. You could say a variable
[02:13.880 --> 02:19.320]  has to be comparable. Why would you use this? For example when you have to loop over a map
[02:19.320 --> 02:24.040]  it has to have a comparable key. So you could write something like this to make a sum of
[02:24.040 --> 02:29.080]  some numbers. And you can use it wherever you want. You make a map from strings and
[02:29.080 --> 02:33.880]  ints and it will count this. Okay strings will work because they are comparable. How
[02:33.880 --> 02:40.120]  do I know that? Simple. You can compare them with equal signs. But what about the empty
[02:40.120 --> 02:46.600]  interface? Is that comparable? Well that depends what the interface is. Before this was not
[02:46.600 --> 02:51.720]  valid. You couldn't do this. But in Go 1.20 you can because now we have two types of
[02:51.720 --> 02:56.960]  comparables. You have strictly comparables like ints, string, bytes, usual, but also
[02:56.960 --> 03:01.960]  non-strictly comparables like the empty interface. Do be careful because this might panic at
[03:01.960 --> 03:09.540]  runtime. It's allowed but it can panic. The next change is the comparables of strict values.
[03:09.540 --> 03:14.960]  It now checks one property at a time and it will exit at the first mismatch. Wait a minute.
[03:14.960 --> 03:20.400]  This was always this way. Yes, it was always implemented this way but it was never specified
[03:20.400 --> 03:24.640]  in the language specification. This isn't really a change in the language. The next
[03:24.640 --> 03:29.640]  change has to do with three new unsafe functions. This is the unsafe package. You should just
[03:29.640 --> 03:38.720]  avoid doing this. Next up, what is new with the Go Tooling? Well, I say this every year
[03:38.720 --> 03:43.000]  and before me, Frances said it every year, is that there are new warnings in Go Vats.
[03:43.000 --> 03:47.120]  Why should you care? Okay, there's a new squiggly line in your editor. You might not care about
[03:47.120 --> 03:51.920]  those squiggly lines in your editor. You should but you can't. Okay, but it also runs when
[03:51.920 --> 03:56.160]  you run tests with Go tests. So your CI might suddenly turn red if you update your Go version
[03:56.160 --> 04:00.200]  because there are new warnings. That's why these are important. The first new warning
[04:00.200 --> 04:06.200]  this year is in Go 119, that it will now error when you pass a pointer to an error in the
[04:06.200 --> 04:10.080]  Error.Ask function, which is such a common mistake that kid of co-pilot wrote this code
[04:10.080 --> 04:17.360]  for me. It's not bad. It doesn't work. The next warning has to do with incorrect date
[04:17.360 --> 04:23.760]  formats. Let's say I want to format a date of today in an ISO-like notation. Well, I
[04:23.760 --> 04:29.280]  would write some code like this. But wait a minute, let's think twice about my codea.
[04:29.280 --> 04:33.840]  How do I format a date in Go? Well, you always have to think about Monday, January the second
[04:33.840 --> 04:41.160]  of 2006. This is February 1st. Many of you probably haven't noticed. Again, this is a
[04:41.160 --> 04:45.480]  common mistake because people are confused between 1 and 2. Go Vats will now warn you
[04:45.480 --> 04:50.920]  against the above format because it probably is used nowhere. There are also some welcome
[04:50.920 --> 04:57.200]  changes to Go Dock. You can now make lists, link, and headers inside your Dock comments,
[04:57.200 --> 05:03.080]  which will be rendered into HTML. Use an example below where I put a header in, I link to the
[05:03.080 --> 05:09.440]  RC I'm implementing, and I'm also listing which guys of coffee my machine supports.
[05:09.440 --> 05:13.960]  There is also in 119 a new Unix build constraint. If you want to build a file that only will
[05:13.960 --> 05:19.120]  be built on a Unix system, you can do that using Go column builds. Okay, in the past,
[05:19.120 --> 05:24.120]  you could do it by listing all different Unix systems. There are a lot of them. Okay, that's
[05:24.120 --> 05:31.840]  a lot of code, right? Well, in 1 to 19, you can just do Go column build Unix. Wait a minute.
[05:31.840 --> 05:36.480]  Isn't this a common thing to do? Because a file system in Unix is almost the same everywhere.
[05:36.480 --> 05:42.640]  Okay, so I asked chatGPT, like every developer does these days. I asked, give me a Unix build
[05:42.640 --> 05:54.280]  constraint, and it gave me this thing. Go build, not Windows. Okay, you all know what's
[05:54.280 --> 06:00.760]  going to happen, right? Okay, you say, it's an AI, I trust the AI. Let's think tries about
[06:00.760 --> 06:06.920]  this. Don't try to be smart and reach the actual compiler code, like every one of you
[06:06.920 --> 06:14.160]  does all day. And immediately I found this thing. Oh, JavaScript is a thing. WebAssembly,
[06:14.160 --> 06:18.240]  one important fact I didn't even talk about if Plan 9 is Unix or not. No, I just love
[06:18.240 --> 06:22.920]  like JavaScript. That's not Unix, and it's also not Windows. So just don't trust your
[06:22.920 --> 06:29.920]  AI, please. 1.20 ads also coverage on building binaries. Why should you care about this?
[06:29.920 --> 06:34.720]  Well, many integration and end-to-end tests, you run them by making a special binary, running
[06:34.720 --> 06:38.600]  it, and getting your test results. If you also want coverage results, this wasn't possible
[06:38.600 --> 06:45.080]  before. If you now build it with dash cover and at a co-cover deer environment variable,
[06:45.080 --> 06:51.120]  then run the script, okay, you get your output, and you also get which lines all your code
[06:51.120 --> 06:55.760]  touched, so you can put it in your site, your favorite coverage tool. There are also a few
[06:55.760 --> 07:00.280]  small changes I want to touch upon. C code will now be disabled if a C tool chain is
[07:00.280 --> 07:05.520]  not found. Many container people will now be happy. Go generate and go test also have
[07:05.520 --> 07:11.280]  a skip flag, which you can put in the red text for which file to skip. Okay, let's take
[07:11.280 --> 07:14.720]  a look at the standard library. Go as many things in the standard library, and of course
[07:14.720 --> 07:20.760]  we have changes in those every year. The first one is in 1.20, and I find super useful. You
[07:20.760 --> 07:27.320]  can now wrap multiple errors. You can do so using error.fmt.errorf. You can now put multiple
[07:27.320 --> 07:31.800]  percent sign w in there. You can just wrap multiple errors. Your functions that you will
[07:31.800 --> 07:37.200]  run on them like errors.is or errors.s, just loop over all those errors. It does that by
[07:37.200 --> 07:41.200]  using the underlying new unwrap interface, which just gives you the slice of original
[07:41.200 --> 07:46.120]  errors back. There is also the new errors.join function, which you can just throw all your
[07:46.120 --> 07:51.720]  errors into. Why would you use this? Okay, you always written a code like this. You just
[07:51.720 --> 07:57.520]  loop over a list, and you want to check for some errors. Okay, you could just return a
[07:57.520 --> 08:02.040]  slice of error, but then you have to check for the length, if it's not nil, etc. Okay,
[08:02.040 --> 08:06.120]  you just want a single error out there. You can use errors.join, and you get a list of
[08:06.120 --> 08:10.400]  all your errors, which are joined together. You can just treat it like a normal error
[08:10.400 --> 08:16.000]  in your code, and even use errors.is and errors.us. So you can just say, oh, was there any empty
[08:16.000 --> 08:21.640]  string in this list? There are also a few changes to the strings and byte package, which
[08:21.640 --> 08:26.440]  is that it now has a new cut function. It just works as an act trim with trim prefix,
[08:26.440 --> 08:31.960]  cut prefix, and cut suffix, except it will now return a boolean if a cut has happened.
[08:31.960 --> 08:37.440]  There is also a clone function, which returns the same instance copied in memory. Also,
[08:37.440 --> 08:41.880]  few small changes to the time package. We now have a compare function, which is a combination
[08:41.880 --> 08:46.320]  of before and after. It does both. It will return you an integer from either minus one
[08:46.320 --> 08:52.040]  plus one or zero, depending on if it's before, after, or the same as a given time. There
[08:52.040 --> 08:55.640]  are also three new layout constraints, which you can use, and those actually came from
[08:55.640 --> 09:00.400]  you. Those came from the Go user survey that they are commonly used, so they added time.
[09:00.400 --> 09:05.480]  There is date time, which gives you an ISO-like notation. There is also date only and time
[09:05.480 --> 09:10.440]  only, which gives you only the date and only the time. There is also a change in the TLS
[09:10.440 --> 09:15.440]  package like every edition. This time, it's a change in how it treats memory. It now shares
[09:15.440 --> 09:20.280]  a copy of your certificate in memory. Why is this useful for you? Well, let's say you
[09:20.280 --> 09:25.280]  have an application that does many concurrent connections, like Kubernetes. Well, until
[09:25.280 --> 09:28.960]  then, now it's sort of a copy of your certificate for every connection in memory. It now is
[09:28.960 --> 09:33.560]  sharing those amongst multiple connections, so you are saving memory. If you somehow have
[09:33.560 --> 09:37.600]  an invalid certificate, you also get a specific error that says the certificate is not valid
[09:37.600 --> 09:43.840]  instead of a general error. And yes, we also have breaking changes this edition in the
[09:43.840 --> 09:49.720]  standard library. The first one happened in 119 in the HTTP package. The HTTP client
[09:49.720 --> 09:54.400]  will now no longer give an error back if you serve a sense of 300 response without the
[09:54.400 --> 09:59.800]  location header set. If you rely on your code to check if the location is set or not by
[09:59.800 --> 10:05.320]  using this error, yes, your code will break now. Also, a change in the random package.
[10:05.320 --> 10:10.440]  It is now preceded when you use the global random functions. You no longer have to call
[10:10.440 --> 10:14.320]  the dot seed function with some random number you get from somewhere. It now does that for
[10:14.320 --> 10:19.120]  you. Of course, it deprecates the dot seed function. If you still need your own seed
[10:19.120 --> 10:25.400]  for predictable random numbers, you can do so by using the random new function. If this
[10:25.400 --> 10:31.240]  somehow breaks your code, it could. You can disable it using this new go debug variable.
[10:31.240 --> 10:35.360]  In tar and zip, there are also some changes which are welcome, which is that it will now
[10:35.360 --> 10:40.040]  error if your R guy has an absolute pot, an invalid character in a file name, or a reserved
[10:40.040 --> 10:44.640]  name on the Windows platform. It will now return error in secure pot. This to protect
[10:44.640 --> 10:49.840]  your server from being hacked. If you somehow don't want this, you can also turn it off
[10:49.840 --> 10:56.360]  in go debug. There is one new package in the standard library, which is the elliptic curve
[10:56.360 --> 11:06.160]  of the helmet gear change. Yay. Very excited. This was possible. Go can do it using the
[11:06.160 --> 11:11.560]  lower elliptic one, but you had to implement more yourself. So it's probably more secure
[11:11.560 --> 11:18.440]  than you would. Okay. The go runtime. We also have a few changes in there. Well, go 119
[11:18.440 --> 11:24.560]  has a revised memory model, and I have no idea how they did that. I don't know. So if
[11:24.560 --> 11:28.280]  you want something, we actually know what he's talking about, Russ Cox wrote an amazing
[11:28.280 --> 11:33.160]  blog post about it. But what does this mean for us average go developers and not compiler
[11:33.160 --> 11:39.160]  developers? Well, first of all, go now has a soft memory limit. You can now tell go how
[11:39.160 --> 11:44.800]  much memory you wanted to maximum use. It's a soft limit. Okay. You can, for example,
[11:44.800 --> 11:50.000]  set it to be one gigabyte. Okay. What will happen tomorrow? Go towards one gigabyte limit.
[11:50.000 --> 11:55.160]  It will try to trigger the garbage collector more to get more memory frets. Yes, you can
[11:55.160 --> 12:00.080]  see the results if it's too low. Well, what will happen is if it's too much, it will try
[12:00.080 --> 12:04.680]  to limit it to 50% of the CPU execution time, which your process is using to be garbage
[12:04.680 --> 12:09.200]  collection. There is, however, a warning. If you set it to tens of limit, tens of megabytes,
[12:09.200 --> 12:14.360]  it might just work because your operating system says that's absolutely not enough.
[12:14.360 --> 12:20.520]  This also results in a new atomic package, which provides low level atomic memory access.
[12:20.520 --> 12:24.960]  So you could now access these variables in multiple go routines. It works only for primitives
[12:24.960 --> 12:30.280]  like integers, booleans, and unsafe pointers. It does this by exposing the function store
[12:30.280 --> 12:37.560]  and load. Also add for integers and compare and compare and swap. Okay. But if you use
[12:37.560 --> 12:42.640]  these, you need to know exactly what you're doing. You need to know how our topics work.
[12:42.640 --> 12:49.600]  As always. And it's still not really recommended. They recommend that you still share memory
[12:49.600 --> 12:54.080]  by communicating, for example, with channels and not communicate by sharing memory. So
[12:54.080 --> 12:59.920]  please only use this as if this is your only option. Go 1.20 has a few small changes in
[12:59.920 --> 13:04.520]  the runtime. The garbage collector got better yet again. Say this every year for five years,
[13:04.520 --> 13:09.480]  it got better. And it is now a Leatheretic. There is also a new mode, which you can compile
[13:09.480 --> 13:13.320]  the binaries in, which is P go, which you can give it a profile of your program that
[13:13.320 --> 13:18.280]  has been running, which will now will try to optimize the binary towards your CPU profile
[13:18.280 --> 13:23.880]  from a previous run by, for example, inlining frequently called functions. The go team claims
[13:23.880 --> 13:27.640]  that is up to 4% faster. I had some colleagues who were looking into this, but not in time
[13:27.640 --> 13:35.200]  to get actual benchmarks. At last, I want to give you a small update on go ports. So
[13:35.200 --> 13:39.240]  what is happening on the ports in go? Well, go 1.19 added a new processor architecture
[13:39.240 --> 13:44.080]  on Linux, which is long arc. It's a Chinese built architecture. It's not yet in white
[13:44.080 --> 13:54.080]  use hour. Go 1.20 will be the last one to support Windows 7 and 8. It will also be the
[13:54.080 --> 14:00.960]  last one to support Mac OS 10.13 and 10.14, but who cares? Go 1.20 also has experimental
[14:00.960 --> 14:07.960]  support for RISC 5 and the free BSD platform. Yay. Okay. That is the current version of
[14:07.960 --> 14:12.880]  go. But of course, let's take a look at the future. And always we try to look in the future.
[14:12.880 --> 14:18.120]  It won't always work. I have two interesting design drafts, which I found. The first one
[14:18.120 --> 14:23.280]  is one for structured logging, something you all do, but doesn't work in the standard library.
[14:23.280 --> 14:28.600]  There is a proposal to make an S log package in log in a standard library. They want this
[14:28.600 --> 14:33.840]  to produce machine readable logging. And it hopes to replace the many, many, many, many,
[14:33.840 --> 14:38.120]  many structured logging libraries like log RISC that ZLog, log arc, log, HLOc, and however
[14:38.120 --> 14:43.400]  you pronounce all those. It tries to propose something like this. Something like every
[14:43.400 --> 14:46.840]  library probably already did is you set up for something, you set up what you want to
[14:46.840 --> 14:51.880]  send it to, you put in messages, you put in variables, and it logs those out in something
[14:51.880 --> 14:57.520]  that is machine readable. This is the text output, which is just key value peps. So your
[14:57.520 --> 15:02.560]  computers can all read it and can index it and make it searchable. How does it want to
[15:02.560 --> 15:08.200]  do this? It wants to give you a logger interface. Again, these are all interfaces. You can just
[15:08.200 --> 15:12.720]  implement them in your own library. Okay, it wants to give you fellow functions like
[15:12.720 --> 15:19.800]  info, error, warning, log attributes. It then makes those into a record. This is just a
[15:19.800 --> 15:24.520]  track containing all this data, and you give this record to a handler, and this handler
[15:24.520 --> 15:28.400]  will turn it into something that's machine readable. If you want JSON, you just give
[15:28.400 --> 15:33.600]  it to a JSON handler. If you want some proprietary format, you just make your own. So it tries
[15:33.600 --> 15:36.840]  to give you an implementation and interfaces in the standard library for different log
[15:36.840 --> 15:42.440]  levels like debug, info, warning, error, passing in data to be printed out, and now putting
[15:42.440 --> 15:48.000]  it into text in JSON and maybe more formats. Again, this is a design proposal. It's not
[15:48.000 --> 15:52.920]  yet implemented anywhere. If you have strong opinions about logging, you can read the full
[15:52.920 --> 15:58.240]  proposal on this link. I will publish the site of FOSDM later today, and you can go
[15:58.240 --> 16:03.160]  there, read everything about it, and leave some comments in their issue tracker.
[16:03.160 --> 16:06.800]  The next big thing they want to tackle is Go version compatibility. Why do they want
[16:06.800 --> 16:14.000]  to do that? Well, we've been doing this talk ever since 2015. A lot has changed, bigger
[16:14.000 --> 16:18.640]  room, different speakers, and especially different slide templates, but there's one thing that
[16:18.640 --> 16:25.080]  always stayed the same. It's this slide. Freaking changes. We wait a minute, Marcia. Isn't
[16:25.080 --> 16:31.160]  there the Go 1.0 compatibility promise? And yes. Well, Go's emphasis on backwards compatibility
[16:31.160 --> 16:35.080]  is why we all use Go, because we don't have to rewrite our whole application every two
[16:35.080 --> 16:40.120]  years. However, there are times which is not possible, for example, with external security
[16:40.120 --> 16:45.800]  dependencies or just bugs that we have to fix. Okay, let's take a look at this in practice.
[16:45.800 --> 16:51.080]  Let's look at the big Go project. Kubernetes again. When did Go break Kubernetes? Well,
[16:51.080 --> 16:56.560]  more than you think. Just in the last version, Go 115 broke Kubernetes in some way by deprecating
[16:56.560 --> 17:04.560]  the X509 company. 117, a bug fix in that part's IP broke it again. In 118, again, X509 broke
[17:04.560 --> 17:09.120]  Kubernetes again because Go changed something, they deprecated something. And in 119, a bug
[17:09.120 --> 17:15.720]  fix in loop path also broke Kubernetes. Oops. Of course, it's impossible not to break Kubernetes
[17:15.720 --> 17:24.160]  somehow. But still, let's try to avoid this in a language. So we have a solution, and
[17:24.160 --> 17:27.760]  it's a solution already we have today. Is that Go debug flag I've been showing on my
[17:27.760 --> 17:33.560]  slides? Okay, what is this proposal? It is to commit to adding one of these Go debug
[17:33.560 --> 17:37.920]  flags to every breaking change in the following releases. And also to guarantee that they'll
[17:37.920 --> 17:43.120]  stay there for a few years or maybe forever. They also want to add metrics to it so you
[17:43.120 --> 17:47.560]  can look at your program and see how many of those are there that you have to fix. And
[17:47.560 --> 17:53.200]  also to put it in code so you can use Go call and debug to override it inside the code yourself.
[17:53.200 --> 17:57.360]  Again, this is not yet fully implemented. There is a design proposal. You can read everything
[17:57.360 --> 18:02.560]  on the link there and leave any comments. But wait a minute, Marcia, don't we already
[18:02.560 --> 18:07.120]  have this? I have to specify that Go version in my modules file, right? Yeah, but what
[18:07.120 --> 18:13.760]  does it actually do? Oh, I know. This says the minimum Go version to build it. No. It
[18:13.760 --> 18:18.960]  will try, any version will just try to build it. It's just a suggestion. It might fail.
[18:18.960 --> 18:25.320]  Oh, I know. It says a Go version in which it uses. Also, no, sorry. It uses the installed
[18:25.320 --> 18:29.880]  version on your laptop. Nothing else. Oh, did I know. This says the semantic rule set
[18:29.880 --> 18:35.160]  for the version. And yes, that is correct. But only the semantic rule set. So that slides
[18:35.160 --> 18:39.120]  to array conversion. Yes, that is set by this flag. The octal numbers which got added
[18:39.120 --> 18:44.200]  two years ago. Yes, that is also checked by this flag. But that's all. Okay, they want
[18:44.200 --> 18:49.960]  to change this. And this is the Go toolchain proposal. They want to add a Go toolchain environment
[18:49.960 --> 18:55.080]  variable which you could use to set a specific toolchain. Okay, I want to use the 1.20 toolchain
[18:55.080 --> 19:00.880]  for this application. This will allow Go get to get a new Go toolchain just like you would
[19:00.880 --> 19:07.040]  get your Go modules. Okay, but it also needs to change the Go command a lot because it
[19:07.040 --> 19:11.720]  has to get your toolchain from somewhere and then first download it, check it, and run
[19:11.720 --> 19:16.400]  it. That changes our tooling a lot. And also, there is a cool toolchain local if you still
[19:16.400 --> 19:20.720]  need a local for some reason. Again, this is just a design proposal. I might be saying
[19:20.720 --> 19:25.360]  that this is implemented next year. If you have comments about it, there is a link here
[19:25.360 --> 19:31.200]  as well. There is also a proposal to add this to the Go mod file. So it's right under the
[19:31.200 --> 19:35.360]  Go version. You say, okay, my application uses the 1.19 syntax which has to use a 1.20
[19:35.360 --> 19:39.040]  RC for toolchain. So if you build this module, it will go download this version of Go and
[19:39.040 --> 19:45.600]  build it using that. Okay, that's a technical thing. Let's talk about my favorite subject,
[19:45.600 --> 19:51.240]  the Go community. This is a map of all Go meetups in the world. We are pretty much covered
[19:51.240 --> 19:56.400]  everywhere where big populations are, but still not enough. What are the numbers? Well,
[19:56.400 --> 20:04.000]  the professional Go developer network on Meetup counts 127,000 members. That's 8,000 more
[20:04.000 --> 20:09.440]  than last year. There is sat news for the first time. There are now only 190 meetups that
[20:09.440 --> 20:16.280]  seeks less than last year, which also results in one country being less represented. Probably
[20:16.280 --> 20:20.200]  due to the pandemic. There are also the women who go and go break chapters, which is still
[20:20.200 --> 20:25.520]  stable at 41 chapters, and Berlin is still the most active one. But now let's talk about
[20:25.520 --> 20:31.880]  my favorite community, the Foslan community. Our deaf room is nine years old today. So
[20:31.880 --> 20:39.120]  we've been doing this since 2014. Okay, small room. Anyone can see themselves? Okay, we
[20:39.120 --> 20:44.600]  got upgraded in 2015, 2016. Okay, bigger one. We stayed in the same size for three years,
[20:44.600 --> 20:50.520]  which was a crowd enough, and today even is full house. 2019, we got the biggest upgrade
[20:50.520 --> 20:57.120]  ever. We got a giant room. And in 2020, we got the biggest room they could find for us.
[20:57.120 --> 21:03.000]  But I regret doing that because a month later, we were all in lockdown. That caused our 2021
[21:03.000 --> 21:06.720]  edition to be fully online for the first time. We all did our best. We turned our living rooms
[21:06.720 --> 21:12.040]  into giant television studios trying to bring you some talks about Go. We learned a lot
[21:12.040 --> 21:16.560]  of lessons. And in 2022, we brought you gophers around the world, which we had great fun
[21:16.560 --> 21:27.720]  in producing. But hey, welcome back. This is something you'll never, ever see again
[21:27.720 --> 21:37.160]  today. There was just one guy still sitting there. And he'll be here at 9.00 at 9.00 p.m.
[21:37.160 --> 21:41.440]  Good. Let's talk about Go! Conference. You're all in the mood, right? So there is a Go!
[21:41.440 --> 21:47.000]  Conference. You are here. Please stay. There are better thoughts than mine. If you quickly
[21:47.000 --> 21:53.240]  catch a plane, right now, you can still make Go! Con Israel, February 7. Con 42 will still
[21:53.240 --> 21:58.840]  be held online in April. If you want to go to New York, you can do so at April 28. Go!
[21:58.840 --> 22:04.920]  Con Japan will be held online. Go! Con Europe will be in Berlin in June. Go! Con US will
[22:04.920 --> 22:10.080]  be in San Diego in September. And Go! Lapp in Florence, Italy will be held in November,
[22:10.080 --> 22:17.280]  which I have not officially confirmed yet. So we got an amazing schedule today. I already
[22:17.280 --> 22:21.320]  want to talk all speakers for signing up to be in our deaf room today. I hope you'll welcome
[22:21.320 --> 22:27.520]  me again next year. But before I leave you all, I want to give a few housekeeping announcements.
[22:27.520 --> 22:31.960]  First of all, out of tradition, we have lightning talks at the end of the day. We reserve the
[22:31.960 --> 22:37.280]  last half hour of the day to do five-minute talks. Those timing is strict. I will pull
[22:37.280 --> 22:44.240]  you offstage. We have a CFP for those. It's open till 17.00, or 5 p.m. for your Americans.
[22:44.240 --> 22:49.320]  And you can submit a tile till that hour at govres.gov.slide. I'll write it on the right
[22:49.320 --> 22:55.080]  board later. You just have to fill out three easy questions. And if you fill those out,
[22:55.080 --> 23:00.280]  I can welcome you onstage at the last half hour. So you have time to submit a talk. Quickly
[23:00.280 --> 23:07.080]  think of something. Submit it. We need you. If you want to talk to us about, talk to us
[23:07.080 --> 23:13.520]  about social media, you can do so by using hashtag Golan and hashtag FOSDEM23 or FOSDEM223
[23:13.520 --> 23:19.520]  or FOSDEM, nobody agrees on that hashtag. But we stand to say with FOSDEM23. We're
[23:19.520 --> 23:24.440]  also on the Fediverse this year because Boo isn't. You can follow us, mention us, like
[23:24.440 --> 23:31.320]  us at godevroom at fosterdon.social. We have a social media responsible person this year.
[23:31.320 --> 23:38.880]  We will be happy to reply to all your angry tweets. So this is a state of go. I first
[23:38.880 --> 23:43.320]  of all want to thank the FOSDEM organization for welcoming us back in the ULB. I want to
[23:43.320 --> 23:48.080]  thank all the volunteers who are helping to make this room possible, as well as the AV
[23:48.080 --> 23:52.280]  team from FOSDEM, who makes my camera work. And everyone else who is working at FOSDEM.
[23:52.280 --> 23:57.640]  And at last I want to thank all speakers for coming here today. And of course, you all
[23:57.640 --> 24:04.640]  for coming to the Go Dev Room again. Thank you.