🎮 BDFL but drop the FL, Game Development, and more!

August does, what it does to schedules, and we've had a bit of a scheduling mishap. So this episode is all me. I hope you'll I hope you'll like it, and, next week, we should be good, normally. So let's get into it with, the first, in my opinion, the first big news item on the docket, the leadership change in the Go project. So if you've been around the Go project proposal process or if you've listened to the show, you've probably mentioned, you've probably heard us mention, the name Russ Cox.

And then a significant update to just the Go community, Russ has announced that he's stepping down as the Go tech lead. Starting September 1st, Austin Clements will take over as the tech lead for both Go teams at Google and the Go overall overall, the Go project. And since Austin, comes from leading the compiler to toolchain runtime and releases a process, Cherry, Mui will step up there. And this marks end the end for 12 plus years, for us as the lead of the Go project. This is interesting.

Other languages, you know, they usually have, like, BDFLs. And Russ mentioned that in his post, that he thinks that BDFLs aren't great for the, for languages. And once, you know, leaders of technical projects that have done so for a while step down,

it makes, you know it's necessary for growth, basically. And, overall, the community, and I can safely say myself as well, you know, have responded just with gratitude. Thanks, Russ, for all your contributions. We're happy that you're still gonna stick around. Russ is not leaving the Groove project. He's just taking a different role, focusing more on just individual contribution, things like Gabby, which we've reported on in the past. And, you know, the the community also used this chance to,

you know, support Austin and Cherry and say, hey. Good luck. We're we're we got you. Overall, a very positive, announcement, I think. There have been also calls for, like, increased, communication, increased transparency, restarting the compiler, meeting notes, restarting the compiler, the run time office hours, things like that.

Overall, I think this is a really positive, step. And again, another chance to, say thanks to Russ for all his contributions for all these years. A lot of what we're talking about wouldn't have happened without, his leadership. But he's still hanging around, still, letting us know about proposals. So let's talk about some proposals. The first proposal I wanna highlight is, an accepted one. So you can look forward to, this proposal joining the standard library soon.

It's also pretty simple. It's a function called the text in the crypto, rand library. The function is very simple. It returns, text, random text, with, you know, specific, alphabet of, base 32. So, basically, very simple, you know, alphabet, like a to, zed, and some numbers. But the issue itself, the proposal, is a very interesting, like, window into the GoProposal process, and I suggest you read it. The, the suggestion was done, by the way, by Filippo, which we've had on the show before. And

it's a big discussion about the API. How simple can we make it? This entire proposal is an exercise in simplicity. The original approach was, let's offer a functional called string that gets an alphabet, and then returns a random string out of that alphabet that is, that has enough entropy to make root force impossible, basically, or, you know, infeasible, at least, which is useful if you need to generate, you know, passwords and things like that. And

as the proposal process went along, people suggested some ways to make the API more complex. Add the option for length. Oh, what happens if I pass a string with, just a a a? And then, you know, the discussion sort of shows how we make the, API more simple and more readable. So the name changed from string to text, and the the there was

a big discussion on adding length, adding entropy as a parameters, why do we even allow to pass the string. And then, because no one was able to come up with a reasonable use case for for selecting an alphabet for a random password generation, the the team just decided to drop that parameter completely. You know, and since this is a simple API, this was accepted with a caveat that other features like custom alphabets, custom length, etcetera, are basically deferred to future proposals. If someone will need it, they can create a new proposal and see, you know, how it works. Because it seems like, the text function with no parameters,

is very, very useful, and you don't need anything else. One thing to consider is that in the future, you know, 128 bits of entropy, or of randomness, I should say, might not be enough to prevent brute force attacks. So this, function text may return a longer text in the future, to maintain the property of being, cryptographically, random. So this proposal was accepted. We should probably see it soon.

It's actually a pretty simple function to implement. Another related, cryptography related proposals that I found interesting, which is a likely decline, and this is your chance to, you know, change the future, basically. 8 years ago, Dave Anderson proposed adding, a Go implementation for the crypt, 3, compatible password generation. What is crypt 3? So if you try to search for it, you can find it on Linux man pages, and it's basically a password encryption function, that's used in /utc/shadow, in Linux.

The need for it in the standard library, if you need to install things in slash etc/shadow, you might want it, and back then, when they've looked for it, you only found some abandoned repos to do it. So this was 8 years ago, and it had a few, you know, people pop in now and then. Was like, hey. What about it? What's going on? And then, Raul Roland from the Go security team sort of gave his, 2¢.

Does this really need to be in the standard library? The bar is higher than, like, 8 years ago. And the what I really liked is that the original poster, Dave, just says that, hey, from since 8 years ago, I don't remember what I wanted to. I didn't actually need this function. I found some, libraries that can do it, so I'm not sure I I need this.

Feature wise, it's a lot better than what existed, 8 years ago. The problem with including it, other than the bar just being higher for this being necessary, is crib 3 is is m d 5 based, so, you know, including it in the standard library sort of goes against goes thing of being secure by default. So overall, since the discussion, doesn't go towards, hey, this is super neat, necessary, and there is a a third party library crypt/crypt. Looks like it's a likely decline. This means that if you really, really want this, now's your chance to jump on this, thread, link in the show notes, and be like, hey.

Hey. Stop this train. I really want this in the standard library. So this is a proposal that's likely to be declined, and, you know, now is your chance to change that if you wanna join. Last proposal I wanna discuss is an active one that I actually commented on, which is adding Go telemetry, increasing the scope of GoTelemetry to include, Delve.

So there are a few things to unpack here. First of all, what is Go telemetry? We talked about this, a few times on the show, but in case you missed it, Go telemetry, is a new feature in in Go where it sends private, telemetry to the Go team to help them direct the Go project towards what the community is actually doing. It's opt in, and if you haven't opted in yet, we highly recommend you do it since it seems like it's a really good privacy aware implementation, and, obviously,

in, you know, their development. However, Delve doesn't have Go telemetry, and this proposal is all about adding that. What is Delve? Delve is the Go debugger. You might have used it, but you don't know that you have. It's, the one that's integrated into Versus Code, and Delve is currently excluded from Go telemetry.

And if you add it, you know, the GoDev team could get more insight towards which debugging features people use, what are the trends that are going on, etcetera, etcetera. The proposal has 3 parts, updating the documentation, adding telemetry in Delve using the, telemetry counter API, and the proposal says that the Delve team decides what and how to measure. And the Go team and the Delve integrators can propose new metrics, in the Delve issue tracker.

Finally, adding the counters that were added to the telemetry upload configuration, following the official, you know, telemetry proposal process. So to me, it's interesting which data points specifically are missing for the Delve team. I wouldn't know what telemetry to collect to improve a a debugger. And also interesting to see if, this considers Golang users as well, or if they use a a different debugger. But overall, this looks like a really good proposal.

I upvoted it. 8 other people have upvoted it. And it's pretty recent. So if you are, you know, one of Delve's deepest users or if you really care about telemetry, now's a

good chance to, like, jump on this discussion as well. I think it's also it would be interesting since this whole telemetry thing is really new, how the process for, like, adding telemetry looks like, etcetera, etcetera. Alright. This does it for proposals. This, show is, kinda tough to do alone, but I I hope you're still with me.

I wanna highlight some, community things that are going on. So the first thing is that the GopherCon EU 2024 videos are online. This is, in my opinion, a really, really good resource for, learning about Go, just these, like, conference talks. If you have a pretty, like, boring, day at work, maybe putting them, you know, in your headphones while you're working, or if you wanna do it a bit more actively, doing it in your guild at work could be really nice, asking each member to watch one of the lectures and then having, like, a lightning round where, everybody gives, like, 2, 3 minutes summary of the video that they watched. Could be a really cool way to, like, upscale the team.

In my opinion, if you have to pick one video, it's actually not about go. It's Hila Fish's technical documentation talk, which is really super good, fundamentals talk. So the playlist, link is in the show notes, and, you can just start watching them. There's a lot of Go content out there. This show is tries to be, you know, your sort

of shortened news version of it. So we can't go off over every single lecture that went there, obviously. And I couldn't go there because I was at DevOpsDays Amsterdam. I think Jonathan was traveling as well or something like that. But there just from the, you know, titles, there looks like there's a ton of really, really good stuff.

Rethinking domain driven design, deep dive into DB connection, building AI applications in Go, obviously hot right now. Go Time podcast had, had an episode, shout out Go Time podcast. I think our, sort of our bigger brother, or bigger sister, podcast thing, and Go AntiPatterns, a panel about Go and DevOps, securing containers. Like, there's a whole,

smorgasbord of lectures that, like, every one of them would have been interesting enough to watch it work. So we highly recommend, just checking it out then and, you

know, if there's a specific lecture here you listen to and you want us to, talk about because you think it's worth, talking about, maybe interview the speakers, let us know in the in the channel. We'll definitely try to make that happen. Last thing I wanna highlight is Go game development. So in a recent episode, Jonathan and I talked a bit about Go game development, and we basically said we don't know, enough about it, but sounds like

it wouldn't be good because x y zed. Not talking, you know, not very authoritatively saying goes bad for game development, but just not really knowing a whole lot about it. I'm interesting

interested in game development, planning to do a game jam, in 2 weeks time, the GMTK, game jam. We basically expressed sorta negative opinions about, Go and game development. I got a super interesting email from Maximilian Patterson, a software engineer from the mid western US. Basically, he convinced me that we undersold Go's capability in game development, way back in episode 67. There are really a few cool links here.

The most important one is Bear's restaurant, which I knew about. So, apparently, there have been commercial successes, you know, on the well, you developed using Go. Bear's restaurant being, you know, the the most famous one. It's even on Switch. There have been people building 3 d games in Go, as well.

There's Mythfall, which was developed in Go, a a big MMO that looks super cool, but it's still, pretty alpha. And I found 2 I wanted to, you know, keeping in theme with the show, sort of give 2 news items about Go and game development. So first one is, a new minor version for Ebit engine, version 2.7.8. Overall, the 2.7, miners, like, patch releases look like they do a lot of, standard, like, bug fixing. The last one had, fixing a memory leak and fixing an issue where text was unintentionally input twice, fixing a crash when dropping an HTML element, and, you know, multiple identical controller on Windows issues.

Overall, sounds like really difficult game development bugs. So looks like they're, you know, they're polishing the engine more and more. EbitEngine, if you

don't know, is an open source game engine, Forgo, which developed in in which many developers, did their production ready, games, production level games, with the, again, highlight, I think, of the entire, Go development community at the moment being Bear's Restaurant. Funnily enough, I, you know, I played Bear's Restaurant. It's, the story, and the art as they highlight, not exactly the technical fidelity. But it is a great game, which means, you know, this, framework doesn't limit creativity for sure. So a new minor version for Ebid engine, which fixes a few crashes.

I guess if you're building your game in Ebid engine now, make sure to upgrade to avoid these. And the second thing I wanna highlight about Go game development is a new channel, I found called Coding with Sphere. It's, someone on YouTube who's doing, game development videos, tutorials, devlogs, commentaries, etcetera. And, you know, they have, very recently started a series, a video each week about RPG in Go. A really, like, 10 to 15 minute video tutorial about, doing basic stuff you need to do for game development.

So, you know, setup, drawing, moving sprites, managing entities, creating and loading maps and things like that. Really cool stuff, and the the I guess the intro video is called I'm Making a Game in Go, My Experience. I highly recommend just watching it. It's really cool to see someone nerding out, about which language to pick. I know I'm I'm in a similar scenario, right now before the game jam.

I'm wondering if I should, like, just do Unity and c sharp, which I already know, and try to get something out. Or, what I'm aiming towards right now, doing a bevy in Rust just because I I I'm doing the game jam with my brother, and, we really hope to practice our Rust because, we both need to sharpen that skill for work. But we might go with Go because sounds like, there are really good options there. And, you know, Max sent me this email with all these games and resources. And overall, you know, we like, it Go doesn't have to be boxed into the web and server space.

You know, as a language we like, Max, expressed hopes that it will break into other spaces like firmware, like game development, and things that, it isn't commonly used for now. We've highlighted a few times on the show, projects like FINE, and other GUI application projects, which Go also isn't known for. And I think game development, is up there as well. And we've highlighted Go for AI. So I think there are some, not not common use cases that Go is still, relevant for or maybe more relevant for in

the future. And I I might pick EBIT engine or Raylib, which is the coding with, Sphere guy is using. So these frameworks for, again, development. I'm definitely a lot more open to giving it a try right now. Alright. That does it for the news items. Let's jump into the lightning round. Lightning round. Alright. So since it's just me, this is gonna be a very fast lightning round.

First item is use Go money. There was an interesting thread on Reddit, but it just has a very simple conclusion. Hey, when I'm dealing with money, what do I do? How do I convert to sense and e n 60 4, blah blah blah, division, it's really hard. And someone just answered the sort of canonical answer, use the money library, which provides the ability

to work with monetary value using a currency's smallest unit, basic and precise money operations. So if you deal with transactions and and Fintech and things like that, make sure to use Go Money and not just numbers. Second thing is Quantum Safe TLS. So Gil Ada, from CyberArk, posted, sort of a general summary situation about quantum safe Golang of, like, quantum safe cybers, x25519, Kyber512. You know, in 1, 2, 3, we the Go library should provide these, like, quantum safe key agreements and things like that.

If you're worried about this stuff, I'm slightly worried for you, But if you need to be, quantum safe, Go's got your back. And this, medium post by, Gil highlights these, new changes. Last on the lightning round, new Ollama release. Ollama released version 0.3.3, with some, by the way, this is like a patch version, but it's it's it has interesting changes in it. The embed API returns statistics, like duration, eval count, things like that.

Usage metrics for the embeddings, OpenAI compatible API, API generate fixes, etcetera, etcetera. Ollama is the, you know, get up and running with large language models, Go library. And one very interesting thing I found about it, is that it is number 4 right now, overall in GitHub stars, for Go projects. So it's just up there, like, below Kubernetes, only atop by the Go language itself and Awesome Go, which is an aggregate. So Go for AI, it it might this might be a vanity metric, but Olam is definitely climbing up there almost, eclipsing Kubernetes in popularity on GitHub.

That does it for my show, our show, for this week. If you wanna support us more, this show is supported by our Patreon supporters. This makes this hobby, which is a rather expensive hobby, paying for editing, the time we invest into the show, etcetera, etcetera, makes this hobby more sustainable for us. So we really appreciate you joining. If you can't join the Patreon, you know, it's just $8 a month, but you wanna support in other ways, or you don't feel it's worth your money, that's also totally fair.

You can find all our resources at capago.dev regardless. There's nothing, the Patreons get that you don't. You can access our Slack channel at hashtag cup dashodashgo on the go for Slack. You can email us at news at cupago.dev, And we don't pay to advertise or share this show at all, so please leave a review on Spotify, Apple Podcasts, or just whatever you listen to your podcast, and maybe share this show with a friend or a colleague. Thanks a lot for joining

this, episode, this lonely, lonely episode. And hopefully, we'll be back to normal scheduling next week. One last thing to mention,

we have social media presence. We have a YouTube channel, and we have a Twitter account, x, and we have, you know, our own personal, like, social profiles, both Jonathan on, and myself, mostly on LinkedIn, honestly. So I think Jonathan's on Mastodon as well. Feel free to reach out and follow and like and sort of try to get his show, highlighted with the algorithms as well. And I'll just personally to get more listeners, on the show. Thanks a lot, and, program exited, I guess. Goodbye.