WEBVTT 00:00.000 --> 00:12.400 It's 9-0-1, so first of all, thank you very much for waking up so early on a Sunday 00:12.400 --> 00:14.160 after a night of beer. 00:14.160 --> 00:17.280 So thank you very much for being here. 00:17.280 --> 00:25.080 Welcome to the already 12th edition of the Go Dev Room. 00:25.960 --> 00:31.960 12 years has still going strong. 00:32.680 --> 00:37.880 So early morning I would like to start traditionally about talking what is new in the world of 00:37.880 --> 00:39.720 Go with the state of Go this year. 00:40.760 --> 00:45.080 But as if you are new here, hi, my name is Machia and I am a train conductor. 00:46.120 --> 00:49.480 Why is a train conductor talking about Go? 00:49.480 --> 00:53.720 Well, I'm actually the only person in this room who's actually paid to remove rest. 00:55.880 --> 01:01.160 I also have apparently part time senior software engineering go but that's not important. 01:03.080 --> 01:07.080 What's on the agenda for today? Traditionally we're going to look at some changes to our language 01:07.080 --> 01:12.680 standard library and the go tooling as well with a small community update and a look at the future of 01:12.680 --> 01:19.160 Go. What has been used since I last spoke to you last year, year at first them, 01:19.240 --> 01:25.320 stoned you goal releases. One is go to 125 which has been released in August of 2025 01:26.120 --> 01:31.800 and one is go 26 which will be released in February, which is any moment now. 01:33.400 --> 01:37.960 And what has been you in Go since we last spoke? AI. 01:39.560 --> 01:45.400 We now have our shoutbook to Gofer. Hello, my name is Gofer, your AI system. Here to help. 01:45.640 --> 01:53.640 It looks like you are trying to make fun of Google's new strategy. Would you like me to write you 01:53.640 --> 02:01.240 a good joke instead? No, no, no, gofer, no, delete, no. Good news, it's never on our day 02:01.240 --> 02:07.800 eye this year. It's not from new fancai chatbot, it's actual new features to go which are very 02:07.800 --> 02:14.840 welcome for us as well as for AI developers. The first new changes are to the language. We got a major 02:14.840 --> 02:19.960 new change to the goal language this year and it is indeed already introduced new function. 02:21.320 --> 02:25.800 Well, we've all written code like this in the past. We have an object with a counter which is a 02:25.800 --> 02:31.800 point to an integer because it's optional and we march with a JSON or worse, GRPC. We're all used 02:31.800 --> 02:37.000 to having these weird pointers everywhere and not code. We all know the pain of initializing them 02:37.000 --> 02:41.960 because we cannot just do ampersand one that doesn't work. So we have written these help 02:41.960 --> 02:47.480 refunctions in the past, end pointer, but then we have more functions. We need input. We don't 02:47.480 --> 02:51.880 need a float pointer. We do also the boolean pointer and a stream pointer and a strategy pointer. 02:52.680 --> 02:57.640 This is going to be problematic and there have been actual helpful libraries for this. Some good 02:57.640 --> 03:05.160 some bad. That's a high gofer. You are absolutely right. I can generate one for every side for you. 03:05.800 --> 03:14.680 No, no, we have a better solution. This is the new function. So the new function has been changed. 03:14.680 --> 03:19.400 It can now determine the output type in which you define it. So we have here still our same 03:19.400 --> 03:25.160 codes where I say my counts and I just do new one. The goal compiler sees and he was in the 03:25.160 --> 03:30.280 front of the pointer to an integer. I have to return a pointer to an integer. So life changes, right? 03:36.360 --> 03:40.520 That's it for changes in the language, but there is also many more changes in go and let's start 03:40.520 --> 03:45.880 with our tooling. More importantly, we would go that. As go that is run. When we run any tests, 03:45.880 --> 03:50.520 it's quite important to look for any changes in there as your CI might break on any updates. 03:51.480 --> 03:56.760 And this addition, we have two new analyzers in go 125, which is the first new analyzer is the 03:56.760 --> 04:02.280 way group analyzer, which supports any misclaced calls in your code to weight group but add, 04:02.280 --> 04:07.240 which is ultimately a way to not being functioning correctly. There's also a second new one, 04:07.240 --> 04:14.200 which is the host port analyzer, which finds any misaccurances of concatenating the host 04:14.200 --> 04:23.880 with the port string, which we all know in IPv6 does not work. Oh, I go for it. It looks like 04:23.880 --> 04:32.520 you like IPv6, which I like to use net.join host port instead. Actually go for that's a very good one, 04:32.520 --> 04:36.680 because this is the one you have to use instead. Oh, yeah, it's useful sometimes. 04:37.080 --> 04:42.840 Unless a little further change in the go command. And more specifically, first in the go 04:42.840 --> 04:49.560 doc command. The go doc now has dash HTTP, which starts a documentation server on your local machine. 04:51.560 --> 04:57.080 Wait, I am pretty sure I've used this feature in the past. And I see many of you nodding. 04:58.120 --> 05:05.640 What happened? All are we looking? And it turns out that go doc might know space. 05:06.280 --> 05:11.640 Had this feature already, but go doc knows space. As been deprecated since 2019. 05:13.400 --> 05:17.000 So what happened? The feature is simply like baby. 05:20.360 --> 05:26.040 So that happens. And then we have also some improvements to go to. The go binary will now ship 05:26.040 --> 05:30.600 with less people binaries. It will not only ship with what you need as a central, which is the 05:31.480 --> 05:36.840 and the compiler. What do we need more in life? Well, any other go tools that you'll use with the 05:36.840 --> 05:41.080 go tool command will be simply compiled on first run, because a compiler is so fast. 05:41.880 --> 05:51.960 Why would we do this? Simple. We save on download size. Go 124 on the Linux A&B64 platform with 75 megabytes. 05:53.000 --> 05:58.600 Go 125 on the same platform is only 57 megabytes, which saves you a lot of download space 05:58.760 --> 06:02.920 for many use cases, especially in CI, where you don't use anything else in the compiler and the 06:02.920 --> 06:12.280 linker. Next up, go modules. There are also have been some very welcome changes to our go modules. 06:13.320 --> 06:18.680 The first one is that we now have a new ignore directory, a ignore directive, in our gomuffs file. 06:19.400 --> 06:23.320 It can specify some files there. There will be ignored in any general pattern matching. 06:23.320 --> 06:27.240 However, do be careful. They will still be included when you distribute your gomages. 06:29.160 --> 06:33.160 Go also no longer changes the go version, where you run any go module update command, 06:33.800 --> 06:40.200 which almost plays a very welcome change. Well, go 126 goes one step beyond. 06:40.200 --> 06:45.080 But now also changes that if you do go mode in it, it will not use the current go version, 06:45.080 --> 06:50.040 but the previous go version. And if you are on a prenalized version, it will use two versions before that. 06:50.680 --> 06:55.960 This is to promote any still support go versions. If you still want to let us think 06:55.960 --> 06:59.720 great as of go, you can just manually overwrite the go version in your go modules file. 07:02.600 --> 07:05.880 Well, let's put tooling. Now let's take a look at our rich standard library. 07:07.640 --> 07:11.000 First of all, we have a new package, which is the same test package. 07:11.720 --> 07:18.280 Well, this starts your tests into a certain double. And in this bubble, everything runs against 07:18.280 --> 07:22.680 a fake clock. We also can launch many go things in this bubble, which we have a obedient weight 07:22.760 --> 07:28.120 function for. Go for it. It looks like you forgot to delete last year's slide. 07:29.720 --> 07:32.600 No, no, no, no, it's simply no longer experimental. 07:35.560 --> 07:40.760 We also have a new function in HP Package, which is production against cross-site for jury 07:40.760 --> 07:46.680 quests. That's when it's a battle. When I was young, in a sense, and very naive, 07:47.560 --> 07:55.400 I wrote PHP. And I used to write many of these against cross-site resources for jury. 07:56.520 --> 08:00.840 We generated random token from some random data and defy it because of the file secure. 08:01.400 --> 08:06.280 And then we put it into a hidden input field like we did everything back then, hidden input fields 08:06.280 --> 08:13.960 where the world turns out I'm getting old. Because there is a modern solution for this, 08:14.040 --> 08:19.640 which is modern HP errors, which have been set with a new JavaScript fetch function. 08:19.640 --> 08:24.760 And what do we mean by modern browsers? Turns out 95% of our modern browsers, 08:24.760 --> 08:31.560 according to can I use already have this feature. So what is it? Every time you do a call from 08:31.560 --> 08:37.160 JavaScript or anywhere else, your browser will set e, set fetch, site header. And that's several values. 08:37.160 --> 08:42.520 You have the cross-site one, which is probably evil, which means a completely different domain, 08:42.520 --> 08:48.120 long-son JavaScript codes against your API. You have the same origin one, which is, 08:48.120 --> 08:53.000 it's the exact same host and the exact same scheme. You also have the same site one, 08:53.000 --> 08:58.520 which means it might be some different domain. And then you have known which means it has direct access. 08:59.720 --> 09:05.480 So how do we secure against this now, and go? Simple. Does Neo cross-origin protection 09:05.480 --> 09:10.040 and you point it to your max handler and you are protected against these attacks? Quite simple. 09:11.000 --> 09:18.120 Code 25 also has some new fixes in the URL parsing library. It will now reject any URLs 09:18.120 --> 09:24.440 containing a colon in the host, like the incorrect colon colon one. It needs brackets. 09:24.440 --> 09:32.120 Or worse, localhost 8 colon 80, colon 80, design worse. If you rely on incorrect URLs in your 09:32.120 --> 09:35.640 goal program, first of all, stop doing that, second of all, this will be a problem change. 09:36.520 --> 09:41.000 But also I have the same change to the reflect package. We now have two new methods. 09:41.000 --> 09:46.520 One for iterating on fields and methods of structs, and the second one for iterating on the 09:46.520 --> 09:52.760 ends and outs of functions. We can now quite easily get four examples, all methods on my HTTP 09:52.760 --> 09:58.920 client values. I just do type four, which I just get back averageable methods, and I get back 09:59.720 --> 10:05.560 all my functions which I can call, as the mean reflecting. We also have a new change in testing, 10:05.560 --> 10:11.000 we now have the artifacts directory function, which returns us a directory. In this directory, 10:11.000 --> 10:15.640 we can place any testing artifacts which in my generates during the tests, and we rely upon. 10:16.360 --> 10:21.560 It is configurable using test minus artifacts, and it will fall back to default output directory, 10:21.560 --> 10:26.040 if there is no output directory, it will fall back to a temporary directory, which will also clean 10:26.040 --> 10:34.040 afterwards. So more welcome changes are in the photography package. The random parameter in all 10:34.040 --> 10:41.000 your HTTP functions is now ignored. Why people have been accidentally putting incorrect 10:41.000 --> 10:46.840 bad or just static random data in there? Well this costs all your signatures and secure 10:46.840 --> 10:52.280 connections to completely fail based on no random data. Why wasn't there for testing purposes? 10:53.080 --> 10:58.280 Any people who now rely on any cryptographic signatures done with static random data for 10:58.360 --> 11:03.880 reliable testing, now need to use the crypto test patch, and this change is applied to every 11:03.880 --> 11:11.400 cryptographic packaging go including TLS. More chains of TLS is that we now have supports 11:11.400 --> 11:18.120 by default for these two very pronounceable cypressweets. I'm not gonna pronounce. 11:19.080 --> 11:22.520 Basically for nobody who knows TLS, they are quantum resistance. 11:22.760 --> 11:30.760 We also have four new packages. That's a lot. The first one is the HTTP package. 11:31.880 --> 11:37.400 HTTP stands for high-butt public key encryption, which quite simply puts is a methodology of 11:37.400 --> 11:42.760 combining symmetric and asymmetric cryptography with each other. When we already use this 11:42.760 --> 11:47.880 whenever, especially in Nike every browser uses this in TLS, however, the never was a standalone 11:47.960 --> 11:54.360 standard for this. We now have it in RCA 90180, and that means there is now a go package for it. 11:56.040 --> 12:02.520 There is also the new R-shinds package, yet a difficult term. All since stands for single instruction 12:02.520 --> 12:08.680 multiple data. Still experimental, but it allows you to do low level operations of this on any 12:08.680 --> 12:15.480 supported CPUs, which is currently on the NVC4 platform, only with CPUs. Which allows you to do 12:15.560 --> 12:19.800 very complex, but the cooperation is very fast. If you know what this is, you'll probably 12:19.800 --> 12:23.080 very excited if you don't know where this is, just ignore it's math. 12:25.880 --> 12:30.040 We also have a next experimental package, many new experimental studies here, which is the 12:30.040 --> 12:36.200 secret one, which allows you to create a secure facility in which you can compute any secrets, 12:36.200 --> 12:39.880 which will then be securely erased from your memory after your calculations are finished. 12:40.680 --> 12:44.760 It currently only works on the Linux I&D64 and ARM64 platform. 12:45.480 --> 12:50.600 And it is intended for forward secrecy. Let's take a closer look. 12:50.600 --> 12:58.040 Well, what I'm writing today is a VPN, and I just got my peer propublic key, which is public information. 12:58.840 --> 13:03.080 What I need is now my public key, and private key, private key, we're going to delete, 13:04.440 --> 13:11.480 and it's a shinkie. So I create variables for those, those are books, public or semi-public, 13:11.480 --> 13:17.480 so I want these in my memory. Now the secret part starts. What do the new secret that you, 13:17.480 --> 13:22.520 and I put a function in that, it writes in that. But I'm going to do that is I'm going to create 13:22.520 --> 13:28.520 a private key, an object, a arrow. And I will create a shark key by doing an 13:28.520 --> 13:33.640 if you calculate the curve, if you have one hand shake, perfect, soft, so I can generate a shark 13:33.640 --> 13:38.120 secret. From there on, I will do some more cryptographic, moon will jumble to create a 13:38.120 --> 13:43.960 my session key. And then I just say, okay, I also need my public key as well. So you 13:43.960 --> 13:48.360 have some variables above. However, that shark secret is very secret, and the primary key is 13:48.360 --> 13:54.680 even more secret. So we don't want those in memory. Functionants, and go just erase these 13:54.680 --> 13:59.320 securely for memory without even waiting for the garbage collector. What is only remaining in my 13:59.320 --> 14:05.480 memory is my public key and my session key. The only have been in my memory were a very short time. 14:06.280 --> 14:12.360 However, with gauge crispness ability comes quick care. Use this quick care, because if you 14:12.360 --> 14:16.360 use it on multiple platforms, the functional executes, but keeps you no security guarantees. 14:16.920 --> 14:21.000 If you use global variables, you have no security guarantees. If you use a new 14:21.000 --> 14:26.200 gorton in there, there are no security guarantees. If you do go exit, and you don't properly 14:26.200 --> 14:31.000 delay, it cannot erase it, so there are no security guarantees. If you use any references, 14:31.080 --> 14:35.080 which have been still being referenced, it's still down, and no security guarantees. If you 14:35.080 --> 14:39.240 cost any panics, you data may leak, and there are no security guarantees. If you use any pointers, 14:40.040 --> 14:45.320 then correctly, they may leak, and there no security guarantees. Please, with the fucking manual before 14:45.320 --> 14:51.720 use. I hope if you write this kind of stuff, you do that already, just pointing it out still. 14:54.600 --> 14:58.360 That's it for our standard library, but there are many more changes in the go runtime. 14:58.920 --> 15:05.560 And the first one is for panics. Panics, that were recovered, then we panics, now no longer 15:05.560 --> 15:10.200 get locked as to panics. Then now get simply locked as recovered, comma, we panics. 15:11.240 --> 15:13.640 Which I just hope you will never ever see in your entire life. 15:17.160 --> 15:22.120 There's also a compiler bug fixed, which has been there since go 121. And it's breaking. 15:22.360 --> 15:31.000 What happens since go 121 go compounds and executes incorrect code? I was very surprised myself. 15:32.040 --> 15:37.720 It's caused by incorrect delay new point checks. I couldn't believe this, so I went to try it out 15:37.720 --> 15:44.520 myself. I wrote that code again, which I do every day. We are trying to open another system file, 15:44.520 --> 15:47.720 which means that F will be new, and our error will be something. 15:48.120 --> 15:54.360 But then day is I want to file name, because I want to print that, so I take name is F.name, 15:55.000 --> 16:03.320 and then I check the error. And then I check the error. This right there is a very clear new point, 16:03.320 --> 16:13.160 right? What happens if I run this? It will, I run go 124, error opening file. 16:14.040 --> 16:18.040 Okay, that's an error, but that's for the correct error. 16:21.480 --> 16:28.040 Important error. Okay. Okay, this is wrong, because I have a new point right here, and let's go check. 16:29.320 --> 16:34.120 So when I run go 125, I now get the correct error, which is actually a new pointer. 16:34.760 --> 16:40.120 Did you some delay check? Code would actually completely allow new pointers without any issues, 16:40.280 --> 16:46.440 which was incorrect. The profile also comes in the experimental changes, which is a profile 16:46.440 --> 16:51.240 to look for the gore teams. If you have any gore teams, which you have not properly closing your 16:51.240 --> 16:55.560 codes or still running in the background, you can now use this profile to look for the new codes. 16:55.560 --> 16:58.920 That's currently experimental, and it aims to be GA in the next release of gore. 17:00.520 --> 17:04.920 There is also heap address based on the visualization, which will take change the 17:04.920 --> 17:11.560 be based address of your heap into your memory for security purposes, because if the run, if the 17:11.560 --> 17:17.560 address is random, any memory based attacks are easier to, is it too, not easier to do? 17:19.560 --> 17:24.120 The next section I would like to call Fausters Smaller Better, which is a new section 17:24.120 --> 17:29.240 I'm introducing into the state of gore, as gore is getting Fausters Smaller and Better every time. 17:29.240 --> 17:32.280 So let's take a look how gore this year is Fausters Smaller and Better. 17:32.680 --> 17:36.680 First of all, go now on support for green tea. 17:39.080 --> 17:44.040 I can generate you a picture for that, yours is ugly. I can use nano grass for it right now. 17:45.720 --> 17:51.320 No, gore, no, no. This was an actual message given to me by Google Slides by the way. 17:55.880 --> 18:00.920 So what we have is now the green tea gouge platter in an experimental release and go 126. 18:01.000 --> 18:08.440 What is it? Well, it's like it's aims to be 10 to 40% Fausters when using NA, GIC Heavy Workloads, 18:08.440 --> 18:13.160 which sounds very interesting. How does it work? I have no idea. 18:15.320 --> 18:23.960 Yes. So I have two options. I could either start Googling or ask AI. Just invite my best friend 18:23.960 --> 18:30.200 Jesus here, which will be here at 10 a.m. explaining everything inside and out how green tea works 18:30.360 --> 18:32.360 in this stage here, problem solved. 18:36.280 --> 18:42.600 Next up is Fauster photography. If you use any show one hashes, then now 2 times Fauster on the NA 64 platform. 18:42.600 --> 18:47.480 If your CPU has hard press support for it. Charge green on your hand is now 2 times Fauster on 18:47.480 --> 18:51.320 the Apple M124 processors. Which is very welcome for TLS. 18:51.560 --> 19:02.440 Sigo is now also used over at off around 20% less. The JPEG encoder in the decoder is a completely 19:02.440 --> 19:09.240 rewritten. And it's now replaced by a more accurate Fauster lighter, better newer Fauster implementation. 19:10.440 --> 19:16.040 This is a breaking change. If you rely on checking in your test, buy buy buy output of the JPEG package. 19:16.040 --> 19:18.920 Otherwise it just a very nice change which you get for free. 19:19.720 --> 19:25.000 Yeah, package. Now also has a very welcome update. Do the read all function. 19:25.000 --> 19:30.120 The read all functions now allocate way less memory and returns the minimally sized final slice. 19:31.240 --> 19:34.840 In practice it will be around 2 times Fauster than the previous implementation 19:34.840 --> 19:39.720 and use hard as much as memory. Ideal for reading your big files at once. 19:41.880 --> 19:47.000 Talking about memory allocation. We now also have more Fauster memory 19:47.000 --> 19:54.440 allocation for small bytes which mean around 512 bytes or less of memory by using a special size 19:54.440 --> 19:59.800 based allocation on the hardware size. Which will result in practice in around 1% Fauster 19:59.800 --> 20:07.800 runtime in heavy based allocation programs. However, this increases our binary size by around 300 20:07.800 --> 20:14.440 kilobytes. Which goes actually pretty recently given our binary sizes at the average 300 kilobytes 20:14.520 --> 20:21.400 is reasonable. Next up, let's take a look at some GoPort changes. 20:22.920 --> 20:27.960 So one has been a new decision. Go125. Now we will require macOS12 Monterey 20:27.960 --> 20:34.840 our later. Go1256 removes the broken implementation of Windows ARM32 for the snapdragon 20:34.840 --> 20:42.920 used out of us. It's ARM32 ARM64. Go1256 is now also added to the race detector to the 20:43.000 --> 20:47.960 risk file platform on Linux. But it marked the risk file platform on free free is the as broken. 20:49.480 --> 20:55.560 Go1257 the next release will require macOS 13 Ventura our later. And it will remove the 20:55.560 --> 21:01.400 PowerPC 64 big and the M platform. For the 5 PowerPC used in the world, this is the big 21:01.400 --> 21:06.440 and the insistent button little and the insistent IBM for some reason came up with two architectures. 21:06.520 --> 21:13.400 And there are some value welcome changes to little containers for once. This is new in my 21:13.400 --> 21:17.320 port section. I never talked about containers before, not in my life, it's talk. 21:18.680 --> 21:24.920 So we have this new making change in Go1255. So we have this very handy variable in Go which is 21:24.920 --> 21:31.480 the GoMax processes. Which links to your maximum seen links to the number of physical or 21:31.480 --> 21:35.880 logical CPUs in your system. Which is very handy when you use any Go routines and you want to use 21:35.880 --> 21:39.800 the most of your CPUs, you just say as far as many Go routines as their processors, 21:39.800 --> 21:45.720 they put all your workloads in the app. Pre-1255 is possible, this is just your physical number 21:45.720 --> 21:51.160 of CPUs in your system. But then I hear you are asking, what about Kubernetes? 21:53.160 --> 21:57.960 What if I write my Kubernetes deployment one, so I have in my first deployment and I put in some 21:57.960 --> 22:03.720 limits. You're doing Kubernetes and if you don't have a problem. If you put in a limit of maximum 22:03.800 --> 22:11.480 one CPU, logical units and I only request to run CO5. What we will do in Go right now 22:11.480 --> 22:17.720 we'll just give you your 100th track course on your AMD processor. That's all we want right. 22:19.880 --> 22:25.640 So what is now changed in 125? If you're CPU bandwidth in C groups, which is either set with 22:25.640 --> 22:32.840 Docker Kubernetes or your favorite container engine, if you're a C group CPU bandwidth is higher 22:32.920 --> 22:36.120 than your number of physical CPUs. First of all, it's weird, but okay. 22:37.400 --> 22:42.360 Then you still have the maximum number of physical CPUs as your Go Max process file. 22:43.640 --> 22:49.160 If it's lower, it will use this limit. Which means if we do this deployment, 22:50.040 --> 22:55.640 I will hear have just one CPU set as this is my ultra-most limits in my deployments. 22:56.600 --> 23:00.760 Please keep in mind speaking as people, the request is ignored and go as it's not the hard 23:01.480 --> 23:08.200 enforcement. But what if I change it? Good news, Go will automatically update 23:08.200 --> 23:11.800 the variable during the runtime. So if you change your bandwidth limit during the runtime 23:11.800 --> 23:15.480 of your program, Go will actually try to make your program faster again. 23:18.040 --> 23:23.640 That's it for this year of Go releases. But now let's take a look at the future of Go. 23:24.600 --> 23:31.880 And I couldn't find many new white 10-year visions. But what I did find is a very interesting 23:31.880 --> 23:37.480 new change, which already is experimental. But I want to give it a separate section, 23:37.480 --> 23:43.480 which is JSON V2. This is now an experimental already, released in Go 126, 23:44.040 --> 23:49.000 and the Go team encourages you strongly to find your usage and find any more buffs. 23:49.720 --> 23:53.720 Why not GA? There are still many outstanding open issues which have been found by the 23:53.720 --> 24:00.760 community, which is causing it to not be GA yet. So what happens here? Well, 24:00.760 --> 24:09.000 JSON V2 is a completely re-implemented JSON implementation in Go. Why? Well, turns out that JSON is 24:09.080 --> 24:13.800 a popular. It's now the fifth most used package, they include 70, in Go. 24:14.920 --> 24:24.200 And it has issues. So how are we going to fix this? Simple. We throw out the bats, we keep the 24:24.200 --> 24:30.280 goods. Okay, we keep the goods and throw out the bats. Let's try doing experiments and try this. 24:31.560 --> 24:35.880 What is good about the JSON implementation? Well, I personally love martial and martial. 24:36.840 --> 24:40.600 They work, you put something in there, something comes out, it just works. 24:42.200 --> 24:48.840 What do we also love? Struct X. Just an amazing invention. Just be able to pass your JSON 24:48.840 --> 24:53.320 immediately into a start by adding some simple text to it. Honestly, it's the main reason I'm 24:53.320 --> 25:01.640 ago developed these days. It's those struct X. What is bad about it? Everything else. 25:02.040 --> 25:08.920 But for us to have an idea of what happened in Go, what was wrong? We need to look at what 25:08.920 --> 25:15.160 happened in JSON itself. For JSON started back in 2001, and what happened here? Somebody looked at 25:15.160 --> 25:20.200 the web and said, hmm, all these encoding standards for data, they know that goods. I can do one 25:20.200 --> 25:27.560 better. And that's how standards play for it. So what happens? There was a standard about JSON. 25:27.720 --> 25:33.560 Let's do some JavaScript-like object notation. Well, it only took 2006. 25:33.560 --> 25:39.080 Jelly was put in the first RRC standards. Okay, now we have finally followed the 25:39.080 --> 25:46.280 finishing. That is not on some random website. What JSON is? In 2014, well, JavaScript. So the 25:46.280 --> 25:53.960 Agma standards body also released a standard code, which Agma 404, not found. In 2013, 25:54.920 --> 26:00.600 immediately followed up by a correcting RRC, which made changes to the Agma standard, 26:01.320 --> 26:09.960 it was in 2014. And there are multiple ones in between, even. In 2017, RRC 8259 has been released, 26:09.960 --> 26:16.440 which is, I had an order of C, defining how JSON should look like. I used JSON on daily basis, 26:16.440 --> 26:22.600 like, wow, I'm really surprised that it was that complex. And to follow up, there is now even an 26:22.600 --> 26:27.400 ISO standard to find a JSON. However, it was paywall, so I could get a picture of it. 26:27.400 --> 26:34.760 Actually, imagine it looks something like this. So JSON itself was never really properly defined 26:34.760 --> 26:43.960 until the late 2017's. So what cost many of this is this RFC flow, because it has been more 26:43.960 --> 26:47.960 than 10 years old. Yeah, JSON has been changed over a lot over the last 10 years. 26:48.920 --> 26:53.560 What is currently bad enough, we want implementation. In valid UTAV, it is a lot. 26:53.560 --> 26:58.520 According to DRC, that's an absolute no-go. It accepts duplicate member names, 26:58.520 --> 27:03.880 duplicate field names. As a absolute no-go, according to DRC, and even cost security issues in all 27:03.880 --> 27:09.320 the products. New slides will become no, which is according to the developer survey, 27:09.320 --> 27:14.840 not code developers would like. JSON parsed fields also are in case sensitive, 27:14.920 --> 27:19.720 which I was really surprised by but it's true. And the Marshall JSON function which nobody knows, 27:19.720 --> 27:25.800 because it's for strikes and it's incredibly cold, so nobody uses it. The way it is more. 27:28.040 --> 27:31.880 Well, it also has many inquiries of the decode function, because people do not really know 27:31.880 --> 27:36.920 how it works, so people make many mistakes against it. Well, the anchoring decode function in JSON 27:36.920 --> 27:43.080 has options, but the Marshall and Marshall ones don't. There are so many performance issues, 27:43.160 --> 27:48.760 the Marshall and Marshalling JSON. There is also no JSON streaming support for very large datasets. 27:50.120 --> 27:58.360 Help! We cannot just change this. Why? We have this go-one point no-go compatibility promise. 27:59.800 --> 28:03.400 Any program that is put into the go-one specification will continue to compile, 28:03.400 --> 28:08.680 I run correctly unchanged for the lifetime of go-one point though, and as far as I know, we still don't 28:08.680 --> 28:14.360 own go-to point no. So we cannot just rewrite as all because this will break implementations. 28:15.720 --> 28:19.080 What we can do is just release an impact edge, which is the V2 package. 28:20.120 --> 28:25.000 And this has been a group effort from around the go community for the last five years. 28:25.880 --> 28:26.920 And this is the result. 28:28.520 --> 28:32.280 Ferry clean implementation, Marshall, Marshall, right, Marshall and code, 28:32.280 --> 28:37.960 option sets, different availities for using things, same with and Marshall for the same. 28:38.040 --> 28:40.840 With the very complex and solid back end on it. 28:42.200 --> 28:45.960 What has been fixed? We now have support for custom Marshallers, 28:46.520 --> 28:52.120 for any weird special structs. We now have unmashing it at 10 times faster than before. 28:52.840 --> 28:57.080 There's also a very strict adherence to the latest RFC. We have case-sense did matching, 28:57.800 --> 29:00.600 new slides and maps will become empty arrays and objects. 29:01.640 --> 29:05.640 We have only empty, which allows us now also to any node types of empty string, 29:05.640 --> 29:10.120 empty slides and the objects. And there are also been some issues faced with time duration 29:10.120 --> 29:13.480 parsing. So yes, I want to get started now. 29:14.280 --> 29:18.200 Perfect because there is a very long and well-written migration guide for this. 29:18.200 --> 29:23.080 How to migrate your JSON implementation to JSON V2 and any pitfalls you might find. 29:24.680 --> 29:26.280 But what about the old one? 29:27.800 --> 29:33.240 Nobody wants to implement the usage of JSON. Not in go nowhere. Nobody wants this. 29:34.200 --> 29:37.800 What will happen to future is that V1 will gradually be rebuilt, 29:37.800 --> 29:41.640 to use the V2 system as a back end, but still have the same behavior. 29:43.640 --> 29:45.640 V2 migration is thus 29:46.600 --> 29:51.080 encouraged. You should try it, but it's not a lot of requirements. You can still use V1. 29:51.080 --> 29:55.640 As T1 will be supported throughout the whole life of the go 1.0 ecosystem. 29:58.200 --> 30:02.520 That's our changes to JSON. And now at last let's take a look at my favorite one, 30:02.520 --> 30:07.880 which is our community. I have a map of all go meters in the world, 30:07.880 --> 30:11.640 which is getting hard on how to track because V2.com is not up up here anymore. 30:11.640 --> 30:14.760 People are using different platforms. So this is something I try to keep up with. 30:16.200 --> 30:18.920 Same for the go and go bridge, stay remain about stable. 30:19.880 --> 30:24.200 But I want to talk about my favorite community, which is you all, are for them community. 30:25.160 --> 30:31.320 It has been 12 years, different rooms, but we have come up with some amazing traditions. 30:31.400 --> 30:34.680 So many recruiting speakers, many more recruiting attendees, 30:36.120 --> 30:41.800 have been here for the past 12 years, even throughout the pandemic, we kept on going and going 30:43.640 --> 30:47.800 till here, so pictures from last year, but you wear this slightly more bigger room. 30:50.200 --> 30:54.680 This is a picture from last year, and this year, you can just go outside. 30:54.680 --> 30:58.120 Let's hear AI work, AI agents, AI agents, what you talk for you. 30:59.080 --> 31:01.400 Which many of you did? 31:01.400 --> 31:05.880 Warning, this may cause extreme inaccuracies. 31:07.560 --> 31:12.440 I have for you today an amazing lineup of my best speakers. I got to reject some very good speakers as well, 31:12.440 --> 31:16.600 so I hope we have a jump back field day with talks that are amazing. 31:17.320 --> 31:21.080 And last year, I tried to come up with five mini tracks in this day. 31:21.800 --> 31:26.120 So the first section is about go, which is now finished, with over time. 31:27.080 --> 31:32.280 Next up is the deep dives, because it's morning, your mind's still fresh, so we're now getting very deep 31:32.280 --> 31:38.600 due to the technical degree. Our lunchtime, we have a security track here, while we have two talks about 31:38.600 --> 31:46.280 go security. Next up, we have using go, and we have an hour of tiny go-com today. 31:47.080 --> 31:49.080 And the last half hours, I'll about you. 31:51.480 --> 31:53.480 So you've got a taste for go-com process. 31:56.440 --> 32:00.840 What go, all the go-com process out there? If you're joining, please be a little bit quiet, thank you. 32:03.640 --> 32:07.720 We have the year today to go that room, at first them, you are here, please stay. 32:09.480 --> 32:12.360 There is also the next conference, which is go-for-cap in the Czech Republic, 32:12.360 --> 32:14.440 which will be from April 23rd to 34th. 32:15.240 --> 32:20.040 We have go-for-come Europe, which we have in Berlin, this year from June 15th to June 18th. 32:21.000 --> 32:24.760 We have go-for-come US and Seattle this year, from August 3rd to August 6th. 32:25.320 --> 32:29.880 Then we have go-for-come Africa in Johannesburg, which will be if you guys should fight 32:29.880 --> 32:36.040 very quickly from Seattle, August 27th. Go-for-come Latin America will be held in Brazil, 32:36.040 --> 32:42.040 which is September 2nd to 4th. Go-for-come Israel will be held in October 18th. 32:42.600 --> 32:46.440 And go-lap in Italy, Bolonia will be held from November 4th to November 3rd. 32:50.440 --> 32:53.160 The last part of the day is lightning talks. 32:55.320 --> 32:59.320 Our CFP for the lightning talks has just now opened. 33:00.760 --> 33:04.760 If you want to submit a lightning talk, if you have an ID for a talk, if you are coming up with an 33:04.760 --> 33:09.160 ID for a talk, if you just want to have a talk where you talk about your latest go-go-you-choreals, 33:09.160 --> 33:15.560 you can do so. We have five data talks, which you can do, find at go-for-the-plats-slides. 33:16.760 --> 33:22.040 Good you are now feeling the form and request that you want to do a lightning talk. 33:25.320 --> 33:29.320 And now go-for-slides just blocked. 33:33.000 --> 33:35.000 Nope, one before, one before. 33:50.280 --> 33:52.120 Okay, I'm going to split the slides you didn't have to propose. 33:55.640 --> 33:57.640 I gave up. 33:57.640 --> 33:59.640 Nope, no, no, perfect. 33:59.640 --> 34:02.440 If you would like to talk about the go-devil one social media today, 34:02.440 --> 34:07.400 you can just use hash tag go-long hash tag for the $20 on your favorite social media. 34:07.400 --> 34:12.600 If you would like to follow the Fediverers, you can find us at go-devil.x4sonon.org. 34:12.600 --> 34:18.040 And if you are on blue sky, if you're still a sticker for that, you can find us at go-for.lap, 34:18.040 --> 34:22.200 which just redirects back to the Fediverers, which is the only two open social media. 34:22.200 --> 34:28.760 Listen, I would like to thank you very much for listening to my talk and enjoy the rest of the day.