Cup o' Go

★ Support this podcast on Patreon ★

Creators & Guests

Host
Jonathan Hall
Freelance Gopher, Continuous Delivery consultant, and host of the Boldly Go YouTube channel.
Host
Shay Nehmad
Engineering Enablement Architect @ Orca
Editor
Filippo Valvassori Bolgè
Sound Designer / Audio Editor based in Milan

What is Cup o' Go?

Stay up to date with the Go community in about 15 minutes per week

Speaker 1:

This show is supported by you. Stick around for the mid show ad roll to hear more. This is Kafka Go for February 16, 2024. Keep up to date with the important happenings in the Go community in about 15 minutes per week. I'm Shaina Khan.

Speaker 2:

And I'm Jonathan Hall. Happy Valentine's Day, I guess.

Speaker 1:

Happy late Valentine's Day. You got your coffee? You woke up early today.

Speaker 2:

I got some coffee. I woke up early.

Speaker 1:

1 hour early. I don't know.

Speaker 2:

Did the time change? I don't think it did. I don't know what happened.

Speaker 1:

I moved the show

Speaker 2:

to 1 hour. Alright. Alright.

Speaker 1:

It's all on me. I don't have my Go, cup today. I have my Harry Potter cup here. Obviously, with Hermione, the actual hero of it. Of course.

Speaker 1:

But even without a cup of go cup, I can still talk go news. Can you? So we have some proposals to discuss, some interesting blogs, some interesting stuff happening in the industry, some stuff on the community, just a a trail mix of news.

Speaker 2:

Would you say that again? A trail mix of news. Say that again.

Speaker 1:

Trail mix of news.

Speaker 2:

Say it again.

Speaker 1:

Trail mix of news.

Speaker 2:

Say it again like 15 times.

Speaker 1:

That's not that hard.

Speaker 2:

Wouldn't it be nice if we had a library function that would just let you repeat things like that?

Speaker 1:

You do you remember, Tom? He's he used to work at the Eircon. We he mentioned him a few times on the show. Yeah. Tom has a saying, this you have bad ones, but that's one of your worst.

Speaker 1:

Well, hey,

Speaker 2:

if you can't get better all the time, you might as well you go the other direction.

Speaker 1:

Yeah. Yeah. So Slices that repeat.

Speaker 2:

Yeah. The idea is to be able to create a a slice with repeating value in it.

Speaker 1:

Is there a lot of discussion? It sounds pretty simple. Sounds like it would be it's just replacing a for loop basically. Right? Is it?

Speaker 1:

I think so. Like, if you wanna create create a repeating slice, so you open the slice and you append in the for and this is just syntactic sugar over it.

Speaker 2:

So you wanna you have x. Right? And you wanna repeat it 15 times or whatever. Sounds pretty simple. But wait, what if you have a slice of things that you wanna repeat over and over again?

Speaker 2:

Like you have x y z as 3 separate things. You wanna repeat those a number of times. Oh. What would that function signature look like?

Speaker 1:

Generic, I assume.

Speaker 2:

And now wait. Do we need 2 function signatures now? Do we need one for repeating a single thing and one for repeating a slice? This is the sort of bike setting that happened. Damn.

Speaker 1:

So, yeah, I I

Speaker 2:

had the first thought I had the same thought as you at first. Like, is easy. Of course. It's no brainer. Let's put it in there.

Speaker 2:

And he has to use the generics.

Speaker 1:

I I can knock it out in an afternoon. Why Exactly. Why do we need language medators?

Speaker 2:

Anyway, I'm not gonna go through all of the bike shedding because, you know, it's been it's been settled. But if you're interested in in how language designers and users of language design simple, trivial features like this that just take a half an hour. Go read the issues in the show notes.

Speaker 1:

Alright. Another, accepted proposal. This one's really simple. Just nice to see, cleanup happening and it's worth, shouting that out is that runtime dotgoroot is going to be deprecated, which makes sense. If you don't know what goroot is because you joined Go recently enough, then I'm I'm really jealous.

Speaker 1:

This is a really good place to be in. Yeah. But a few years ago when you installed Go, you also had to mess around with, like, a few environment variables and they were always kind of weird. The Go team had this notion of all your Go code living under the same Go directory, which works if you work at a specific company and you have a big monorepo, let's say Google, but doesn't really work if you just wanna open a directory and start hacking on Go. It was a lot less flexible.

Speaker 1:

You don't have a Python root on your machine. Right? Or a Node. Js root. But for Go, that was the decision and the language slowly moved away from that.

Speaker 1:

I think it it, like, there was a blog about deprecating it about a year ago. Just let's not use, gorout anymore. And now the runtime function is going to be deprecated as well because it's not gonna be meaningful if, copied to another machine. And instead just use the system path to find Go. It was accepted yesterday.

Speaker 1:

Yep. And the topic of paths as strings, which is basically all we do in Go. So we talked about Go Root. Yeah. How about HTTP paths?

Speaker 2:

Yeah. So if you listen last week, we talked about the new HTTP routing capabilities in Go 122. Of course, we didn't go into a lot of detail. If you'd like some detail, the Go team, Jonathan Amsterdam, specifically on behalf of the Go team, released a blog post.

Speaker 1:

Jonathan Amsterdam which again important to note is not you.

Speaker 2:

It's not me. I am Jonathan and I live in Amsterdam but I am not Jonathan Amsterdam.

Speaker 1:

I've never seen you and Jonathan Amsterdam in the same room together. Curious.

Speaker 2:

We we need to get him on the show maybe and and figure out how this works. Yeah. So, anyway, thanks, Jonathan Amsterdam for writing this blog post that who's not me. But he wrote a blog post explaining the details of the new, routing capabilities in Go 122. So that's probably a useful thing for most of us to check out.

Speaker 1:

Yeah. Super short, highly technical article, just like, we love to see in the Go dev blog.

Speaker 2:

I I think the one thing I want to shout out is the last, the conclusion, where it talks about compatibility. He says we made every effort to keep new functionality compatible with old versions of Go, but there are some edge cases in particular if you have curly braces in your URLs. In the past, they were just translated literally. This should be very rare that you have curly braces in your URLs. But if you did for some reason, you're probably gonna break when you upgrade to 1 22.

Speaker 2:

So you'll have to to update that or you'll have to work around that somehow.

Speaker 1:

I guess maybe with some sort of encoding or auto generation, people might have that and they didn't mean to. But I can't, in good conscious, imagine the path. I'll be like, yeah, curly brace makes sense in this path. Yeah. Yeah.

Speaker 1:

On the topic of HTTP services, there's a really, really good, not concise, blog post. It's dense, but it is very long by Matt Ryer about how to write HGP services in Go. This time it's coming from someone with quite a lot of experience, because the title is After 13 years. And this post is basically a really good, blueprint if you want to create the new template for an HTTP service at your company. Just follow all the tips here.

Speaker 1:

I really can't look at one tip here where I I disagree. Some things include that main only calls run using a ton of dependency injection with long argument lists. That's a really bike shady argument I've had a few times. Did you ever write a code review and we're like, this function just gets too many parameters. Let's group some of them into a class.

Speaker 2:

I've done that in the past, but not not these days. I actually I I agree with Matt that the long list of parameters is useful because of the type checking. You can't accidentally omit 1. And I I I do think there's a a smell to be had when you have too many arguments, but it's not the solution isn't to switch to a struct. That just hides the smell.

Speaker 2:

It's like sweeping the dirt under the rug. The solution is if you truly have too many arguments, that means your function is doing too many things. I don't think that usually applies to a constructor, like, in this case, though.

Speaker 1:

Yeah. So there's this sort of really good separation that comes out in this blog post as well when you have sort of graph creation code where you just take all the you need to the things and hook them up together and you don't do any logic. You're just like some people call it manager, some people call it constructor, some people call it graph creation versus all the rest, which is like your business logic. And in all the rest, this is a smell. But in the, like, big init functions and and wrappers, I totally agree that just adding all the stores, adding all the services, the config, the logger, all the middlewares, all the, like, whatever is a really good idea.

Speaker 1:

Decoding and encoding, do it in one place, validate your data, that also makes sense. And I really think that there's a lot of good tips here that could be applicable even if you don't take them as is. For example, for decoding and encoding and validating data, if I were to write a go service from scratch today, I would probably do it in a gRPC and I would use a gRPC validate for validating data. This still adheres to these like these tips but it doesn't follow them exactly. I think the the core of these tips are really really really good And there was a lot of talk in our channel about the middlewares.

Speaker 1:

Right? That was a topic that caught people's attention at the Cup of Go channel. Yeah. I never thought about it so hard. Why why do people care so much?

Speaker 2:

Well, I I think it as a newcomer to go, it's confusing to have like, a typical middleware has a function that returns a closure that returns a closure, which is kinda confusing until you recognize the pattern. And then it and then it kinda, I think falls into place in your head and it makes sense and it and it feels good. But until then, I know I struggled with it for a long time. Like, what what is what are these different layers? It feels like you're in this in inception or something, you know.

Speaker 1:

I understand. I think definitely reading it. This post assumes that you know go pretty well and that you've written quite a few HTTP services before. It's not a tutorial. So if you're a newcomer, I would put aside 2 days to read this, but I would put them aside.

Speaker 1:

It's really, really worth it. And finally, the post ends with, like, putting all these into practice. So larger organizations and bigger projects, there are constraints of the real world. This post comes from Grafana Labs. So, you know, there are gRPC practices, and tools, abstractions in gRPC.

Speaker 1:

Grafana uses gRPC. So you just go programmatically and go with the flow even if it doesn't necessarily fit into all these, you know, tips, for example, using inline request response types. But overall, this is a really, really good, blog post. I think it shows the the huge gap between, oh, I can do, like, production services with the standard library and how much work actually goes into, you know, a proper modern HTTP service. But honestly, just a super great blog post.

Speaker 1:

Highly recommend.

Speaker 2:

Awesome. I like Matt Ryers blog post in general. So, yeah, check it out.

Speaker 1:

Cool. So we have some more, community stuff to to talk about. Right?

Speaker 2:

Yeah. This one's a little bit less awesome. I don't know. Have you ever used Flux or Weebworks?

Speaker 1:

Have you used Argo CD?

Speaker 2:

You've used Argo CD. Yeah. Who's eating their lunch or has has eaten their lunch, I guess. So we, if anybody uses Kubernetes, you may be familiar with

Speaker 1:

If anybody ever heard on this, it's the tiny project Yeah. From it's a new open source project from Google called Kubernetes. Some people

Speaker 2:

will deploy Kubernetes with this tool called Flux. It's a GitOps thing. Basically, you can throw a a stack of YAML at Kubernetes and it just makes it happen. Kind kind of. I mean, it's really oversimplifying.

Speaker 2:

The company behind Flux, Flux is the first project. The company behind Flux, Weaveworks, has announced they are shutting down operations. Didn't have the the revenue necessary. An acquisition fell through at the last minute. So if you are a Flux user, I mean, Flux is open source, it will still be there, but probably won't be getting much updates.

Speaker 2:

WeWorks, the the SaaS are behind we behind Flux is going out of business or or has gone out of business. I don't know exactly the timeline. This announcement was dated February 5th. So it's kind of sad to see that happen. Flux is a CNCF project.

Speaker 2:

So I mean, it's not vanishing, but I do imagine it will get a lot less, development work. It'll probably become more of a community project, I'm guessing. And, yeah, I think most people are switching to or or are using Argo CD these days, which I haven't used yet. So I don't know exactly how compares feature to feature or whatever, but,

Speaker 3:

yeah, it's a

Speaker 2:

little bit sad to

Speaker 1:

see it happen. We don't usually link to LinkedIn. Just not the type of, links we usually link to. But the post from the CEO is kind of he's obviously worked up about it and, there are some comments from really interesting people here. Liz Rice, I don't know.

Speaker 1:

I watched her videos to learn about what this Docker. You know what I mean? Mhmm. And just people who seem to be impacted or or, you know, care about Weaveworks. Not just the project, it's also the people behind it.

Speaker 1:

Argo City is like going great. I'm working, on integrating Argo City to Orca right now. So I really think it's not like GitOps is going down. I just think we're consolidating to a single solution. Mhmm.

Speaker 1:

There is one interesting thing in that regard. You know how you always look up x versus y when you're for example, if if someone wanted to get up solution right now, they would probably end up googling, Argo CD versus alternatives or Flux alternatives or Argo CD versus Flux. Mhmm. When you look that up, you see a ton of, posts. Right?

Speaker 1:

Called flux versus Argo CD. What should you choose? It's amazing to me how much all of these are invalidated now now that one project is, like, financially backed and and CNCF and everything and one is just an open source project, not the same, level of commitment I would say.

Speaker 2:

I also get a lot of flux versus redux which I guess is, something that front end developers will understand.

Speaker 1:

Yeah. It's not a flex is a different it's a state management for for front end, and you shouldn't use any of them anyway. You're right. You should use sagas. Never mind.

Speaker 1:

We're not a front end podcast, but if you have a Redux and you're not migrating to MobX, maybe you're maybe you should rethink your life. And if you are, maybe you should rethink your life and write goosome go instead.

Speaker 2:

There you go.

Speaker 1:

I found this interesting thing on Reddit where one of the users posted that go 122, which we've talked about last week, is yielding an 18% regression in single threading performance. And I was, like, oh, no. They fucked something up. Like, it's it's not good. But luckily, this user decided to post on the subreddit instead of just reporting an issue and got some feedback, you know, some peer review from the Reddit community that basically shared that 2 small sample sizes are not relevant.

Speaker 1:

It's just changes in the in the jump alignment between builds and every program that's over 60k lines, the time is exactly the same. So, no, go 122 doesn't have an 18% regression even though that was the title of this post, but in small sample sizes, it might. The main culprit that they tried to look at was the loop fire fix because they go change how loops work and there's some interesting investigation here in the comments. But, overall, seems like everything below 60 k is too short and above 60 k, everything's great. So it looks like, no, go 122 doesn't have a big degradation in performance and you shouldn't have a problem upgrading.

Speaker 1:

But a good work on on on behalf of that Redditor. Right?

Speaker 2:

Yeah. Instead of just running to the Go team. For not being, toxic here. I mean, I I like to rag on Reddit, but this was a very civil discourse, I think. So good job.

Speaker 2:

Could could

Speaker 1:

have been a Slack thread for all I know. One last, community thing we wanted to discuss. Right? Yeah. Some YouTube content.

Speaker 2:

So, I'm sure many of you, if not all of you, have heard of, if not watch regularly, the Primetime YouTube channel by the the Primagen. Is that how he says his name? His moniker. So he has a new video that came out, yesterday called why I use Golang in 2024, which is kinda interesting. I mean, he's talked about go several times in the past, but he's he I think he works at Netflix.

Speaker 2:

He talks about Rust a lot, and he and he just reviews, your content, blog posts, and stuff. A lot of people are I shouldn't say reviews. He more like, reacts to. But he talks a lot about Go and some of the things he likes about it. He talks a lot about Rust and the things he loves about it.

Speaker 2:

So this 10 minute video, it's it's, easy quick watch. He talks about why he's switching from Rust to Go in 2024. And to be clear, it's not because he hates Rust. There's no Rust hate in this video at all. He loves Rust.

Speaker 2:

But it's an interesting watch. I mean, I think I think the main point he makes is the idea that Go is sort of designed to be a simple language to be productive. And he wants to give that a shot before he has a full verdict on whether he likes Go or not. So he says he's gonna try using Go for when he has a choice, he's gonna use Go for the next year or 2. Yeah.

Speaker 2:

I'm curious to see how that goes. I'd love to watch a follow-up video in a in a year or whatever and and see his response to that after he's he's done this experiment. Maybe we can get him on the show and and, ask him directly. That'd be fun too.

Speaker 1:

At least on YouTube. I don't watch a lot of YouTube, but I do follow, a few, programmers on YouTube, prime time. And there's some people who make, like, you know, comedy videos about programming. Fireship. I 0 does this like really short form, you know, tech videos, which I like x in 60 seconds and no boilerplate as a as a dude who's doing videos about rust.

Speaker 1:

And whenever I watch programming content on YouTube I feel like, oh, I have to do Rust. Why am I not doing Rust? Everybody's doing Rust for everything and and all the all the world is getting oxidized. And I I then I go back to my corporate job where people are, complaining about even using Python and not configuring everything with JSON files and web interface and, like, okay. In reality, we're far away from everybody writing Rust for everything all the time.

Speaker 1:

It's really, really, really, really, really hard and not, very, like, very strict and not relevant for many use cases. But Go is relevant for, at least in my opinion, for many more use cases. And you can knock out stuff really really quickly. And you'll see a lighting. Sure.

Speaker 1:

You need the HTTP service. You don't need now you can just use the standard library, etcetera, etcetera. I think it's really productive. I just hope that it's sort of boring. You know what I mean?

Speaker 1:

We shouldn't say that as a Go news show. Yeah. The this topic of is is boring. But I mean boring in the sense that usually you write a thing in Go. It'll probably work like it'll probably not crash.

Speaker 1:

I have some rust in in production myself. It doesn't crash as well. It just took a lot more effort to write. Mhmm. And I just wish, private time will have a good time with, go this year.

Speaker 1:

He colored his hair, gopher blue. So, you know, he's already on the right path.

Speaker 2:

Awesome.

Speaker 1:

Cool. So that's what we have for y'all this week.

Speaker 2:

Stick around, though. We have an interview coming up today, the first time this year, with Daniel Marti. So stick around for that.

Speaker 1:

Should be interesting.

Speaker 2:

Talk to you there.

Speaker 1:

This show is supported by you. Woo hoo. We wanna welcome 2 new Patreon members to our cupago club.

Speaker 2:

Thanks a lot for your support,

Speaker 1:

Thomas Bruno and Wilken Rivera, which we had on the show before. Shout out, brother. Thanks for, supporting us. If you wanna learn more about the show, you can find us on the web at cupago.dev. That is cupogo.dev.

Speaker 1:

And we usually hang around with, our community at the Gopher Slack hashtag cupogo with hyphens. If you're into email, you can email us at news at cupogo.dev. If you wanna support the show, buying merch on our store or joining on Patreon is the best way to do so. Is a pretty expensive hobby, and we rely on your support to keep it up. And other ways to support us include, leaving a review on Apple Podcasts, Spotify, wherever you listen to your podcast, and put the word out.

Speaker 1:

Our last episode about Go 122 was almost our best release window ever, probably because it's a very shareable episode. Just talks about the new things in 122 which is something that most people who program in in Go care about. If you're looking for a specific episode to share, maybe that one could be a good one. Thanks a lot for listening, and stick around for the interview with Daniel Matti. Looking forward to it.

Speaker 1:

Jonathan, are you ready to start the interview? I am. Alright. So I'll give you a cue and we could start. So so I just need someone who can tell me about cue.

Speaker 1:

Anyone? You know anyone? So I can give you

Speaker 2:

the actual Q so we can

Speaker 1:

start the interview.

Speaker 2:

Daniel, do you know anything about Q?

Speaker 3:

A little bit.

Speaker 1:

Yeah. Hi, Daniel. Hello. Nice to be here.

Speaker 2:

Welcome to this cheesy show that we do. So Daniel Marti, did I say that right? Is it Marti? Yep. Is our guest today.

Speaker 2:

Daniel, you have your fingers in a lot of pies, I think. But before we talk about those pies, would you do a brief introduction? Let our audience who doesn't know who you are, know about you, what your relationship is to the Go language, the Go project, and and all that fun stuff.

Speaker 3:

So my name is Daniel. You might know me as m v Dan online, and I did start coding in Go geez about 10 years ago. Mhmm. And I have been contributing here and there, never full time, sort of on on on the sidelines. And in the last couple of years, I've been involved in q, a configuration language built on go.

Speaker 3:

So there's some over significant overlap there. Cool.

Speaker 1:

We have a quite a few projects we wanna get into, but I think Jonathan has a has a favorite he wants to ask you about first, which is GoFamt. Not Go fmt. Go fmt.

Speaker 3:

It's funny that you mentioned that because somebody just this morning mentioned why did you call the tool Go fmt. It's so confusing. And I'm like, yes. That's precisely why I called it that. Because I used to call the original GoFumpt, goFmt.

Speaker 2:

And then somebody told me, no.

Speaker 3:

No. It's pronounced GoFumpt. And I was like, well, then just call it Go fmt in writing.

Speaker 1:

That's exactly the sort of, extremely pedantic, conversations I expect someone who developed the GoFund to have. Jonathan, since this is probably one of your favorite tools, what is GoFund?

Speaker 2:

Are you ask are you asking me? Yeah. You want me to explain what Go fmt is and see if I if I can If if that

Speaker 1:

integrates you. Yeah. If if you're hitting, the nail on the head.

Speaker 2:

It's a stricter version of Go fmt.

Speaker 1:

But it's Go fmt. What is Go fmt? So it's a stricter version of Go fmt.

Speaker 2:

If I'm not mistaken, it's a fork of the official Go fmt It's added some stricter formatting rules to tighten up certain, you know, white space in certain places. And, you know, there's a couple dozen rules, I guess. But,

Speaker 1:

So, Daniel, why develop a different formatter? Go already ships with a built in formatter, which is one of the things, you know, people will talk about the and go, oh, everything's batteries included, everything's built in. You don't have to, like, install, you know, black and flak8 and isort and all that, for example, in Python, you just get it out of the box. Why did you feel the need to fork it?

Speaker 3:

Yeah. Out of all the projects I've started on GitHub, GoFund is maybe the one that's most polarizing because some people say, yes. I I love the extra rules. Thank you. And some other people say, why did you start this?

Speaker 3:

It's just like split the formatting world in 2. I kind of see both sides. I wouldn't really say that I split the formatting of Go in into 2 camps because I deliberately made GoFund backwards compatible with Go. FMD. Meaning that if one of your developers chooses to use the stricter tool, the stricter tool and the original tool are not gonna fight each other.

Speaker 3:

It's just that one will wanna go a little bit further, but it's they're not gonna gonna, like, collide and conflict with each other. Another choice that I made is because it is, in a way, a fork of GoFmt, it follows the same philosophy of no options, of the same command line interface, and so on. So it is pretty much a drop in replacement.

Speaker 2:

And what was it about GoFMT that you didn't think was, quote, good enough or strict enough, whatever? What why did you choose to make this for?

Speaker 3:

So it it is gonna sound slightly pedantic if I say this, but at a previous job, I was doing a lot of code reviews. I was in a sort of team lead position, and a lot of the people that were sending me code to review came from other languages. So they wrote Go code as if it were another language, if if you will. And most of that is is not style. Most of that is things like naming variables or how you structure your types and methods and things like that and files as well.

Speaker 3:

But quite a lot of it was just because they were used to, for example, you know, languages like C or Java or Python. You just style your code differently. And if you pass that through go fmt, the original Go fmt, it deals with a lot of that, but some of it just, like, doesn't care. Leaves it alone. And I kept seeing patterns of, like, oh, I would delete this empty line.

Speaker 3:

Oh, I would just join these lines. Oh, I would blah blah blah. And then I I'm a very lazy person, so the 10th time I would have to suggest something. I would just be like,

Speaker 2:

I can't be bothered.

Speaker 3:

I I want something to just do it for me. Right? Mhmm. So that that was the source of it. And I I know that Robert, the author of go Go fmtMaintainer, I know he wants to add more roles to the to the upstream tool, but at the same time, he's somebody that that has to maintain 20 different things.

Speaker 3:

And he was also at the time developing the early prototype of generics. Right? So improving GoFmt was very, very low on his list. And even today, it is, for obvious reasons. So I I thought, it's not like I'm going against him or like I'm go I'm trying to overrule him, but at the same time, I treat my tool as, like, an experimentation place.

Speaker 3:

And then it's very much the intent that if, for example, half of the rules that I have are a good idea, he can well, he's more than welcome to copy them. I I do not care.

Speaker 1:

Cool. I I hope that does happen. Like, consolidating all the rules and having stricter formatting is like, you say it's, you know, you were lazy and you wanted to have more uniform CRs. But when you're in a team lead position and you do a lot of code reviews, I can definitely feel you. Like, having uniform just ways to look at things and the pattern recognition is easier, makes it easier for everyone.

Speaker 1:

By the way, including LLMs, we've mentioned this a few times on the show, but the fact that Go has a, you know, a format that's an you can't argue with and you can't really configure too much and also uses tabs instead of spaces is super good for code generation, just a lot cheaper, which is nice. So GoFound. We I just wanted to get that out of the way because it's Jonathan's probably favorite tool.

Speaker 2:

No. That's that's that's quite true, but it it is it is, one I like a lot.

Speaker 1:

So but you mentioned you were working on Q. Right? We're planning to have, another maintainer of q on the show.

Speaker 2:

Paul Paul is scheduled to come up, on the show in March. So

Speaker 3:

Oh, cool.

Speaker 1:

Yeah. So so we're gonna have 2 views on q. But why another configuration language? Again, yaml is good enough? Isn't JSON good enough?

Speaker 3:

It's a good question. And there's like, if there's many opinions about what a programming language should do, there's even more about what a configuration language should do. Because there's there's camps of people who say configuration languages should be as dumb as possible in a way. So think like JSON. Right?

Speaker 3:

JSON does not have references, does not have any logic whatsoever, does not even have comments. Right? Some people go even further with things like INI or TOML, which is just like, you know, like a list of key values of in a way. And then there's camps of people that say I want configuration as code. So they might use something like Python or languages that are somewhere in the middle like I keep forgetting the name, but Starlark, I think, is like a version of Python that's specifically aimed for configuration.

Speaker 3:

And then there's configuration languages that say, well, we're kind of like code, but we're not Turing complete. So so we we allow you to do some things like conditionals and loops, but we don't allow you to, for example, look forever or, like, write a kernel in this. Right? And I I think that's where some languages like HCL and Qt try to set. So I I would say those are the 3 main camps.

Speaker 3:

And I would say that there's not enough my opinion is that for projects or companies or orgs that are large enough, simple languages are not enough. And you have to be really careful with any language that's too powerful because then that's essentially how you get into trouble because configuration issues gets, a, too complicated to understand, but, b, also too too expensive to compute. So that is when you need this middle ground of a language that lets you do more than just dumb configuration languages, but not so much that you just, you know, waste CPU cycles trying to evaluate what the hell is happening.

Speaker 1:

So there's a new very new, I guess, I don't wanna say competitor because it's, like both open source and they're both fine, but there is a new library out by Apple called Pickle, which is it's called pkl, which is even a worse choice than Go fmt because at least with Go fmt you meant it to, like, go over the same thing. But there's Python pickle and now there's apples pickle, which is not related to Python's pickle package at all. I wouldn't be able to say that sentence again fast. And I'm wondering, like, how much overlap there is between, q and and Pickle? Like, if are they direct competitors?

Speaker 1:

Is there, like, sort of features that the Qu has that Pickle doesn't? What reason would I have to pick one over the other in case, you know, I I decided I wanna be serious about my, you know, configuration, like, but database connection string. I really wanna configure it correctly this time.

Speaker 3:

That is a good question. And I think that should definitely be one to say for Paul because I haven't looked at Piccolo with much depth. All I know is that they take different approaches mainly because Qt takes a somewhat a somewhat unique approach in that it's a it's a a configuration language built around unification. And that is actually where the name Q comes from, configure, unify, evaluate. Even though maybe that's not the best way to name a language, but that's what it is.

Speaker 3:

Mhmm. And it's it's a bit it's a bit special in the sense that, you know, how, for example, in Go, you can compose interfaces. So in a way, in q, you can compose values. So you can take one value, another value, and then unify them, and that gives you a new value. And there's, as far as I know, there's no other, like, mainstream configuration language that works like this.

Speaker 3:

Some others instead do inheritance, which is the more classic way with programming languages as well. I'm not gonna say one of them is strictly better than the other one, but they're definitely very different. And they both have pros and cons.

Speaker 1:

And you like, there are users of Q, you know, on the at least there are logos on the on the homepage. Is are they, like, contributing a lot of code back? Do they have a lot of complaints? Or is it, like, yeah, queue as it is is kind of fine and sort of done?

Speaker 3:

I believe the companies that are listed on the website are mainly the big users, you could say. In terms of contributors, we have people contributing on GitHub and Garrett all over the place. Including me. Yeah. To to the point that sometimes we get pull requests or or patches, and it's only weeks later that we realize, oh, that person works at that company.

Speaker 3:

Right? Because with open source, unless they put it in their profile, you don't you sometimes don't tell.

Speaker 1:

Mhmm. I I guess I should add my company to my GitHub profile. That's always a problem. Right? Because when you join a company Jonathan, you're you're doing work with tons of companies, right, because you're freelancing mostly.

Speaker 1:

Yeah. So do you use your main GitHub or they they force you to open like a company email?

Speaker 2:

I prefer to use my main one. I usually add the company email to it though so I can get those emails at my company.

Speaker 1:

I have like 3 GitHub accounts at this point. All of them with, like, slightly different open source contributions. It's kind of annoying to okay. So go to this one and go to that one. Cool.

Speaker 1:

If I have config files right now at work and I'm frustrated, should I try to migrate to q, like, and and do that, change? Or is it mostly for okay. I have a new project, so now it's it's worth checking it out.

Speaker 3:

It's a good question. Q is built in a way that is like a superset of JSON, very much on purpose. And YAML is also a superset of JSON. So in a way, if your project already uses JSON or YAML in some way, switching to Q or starting to use Q in some parts of your, for example, CI pipeline or Go code and so on, it should be possible without you having to throw everything away and start from scratch. At the same time, if you wanna get the full advantage of of this new paradigm of configuration language and unification, you probably should change the way you think about configuration a little bit.

Speaker 3:

Because, for example, q can do both schemas and data. Whereas if you think about yaml or JSON, they're mainly about data. And then there are set things like JSON schema, which is like schema as data. Right? But it's fairly static and and very much different.

Speaker 3:

In q, everything is the same. It's not like a strict separation between types and values. Everything is, like, in a spectrum between the 2 in the form of constraints, for example. So I would say it's perfectly fine for an existing project to incorporate bits of queue, and I've done that at work many times before. Because if if I'm an employee at a company, it's it's not reasonable for me to say, hey.

Speaker 3:

Please, everybody, stop, and I'm gonna change how we do configuration. Like, that's not something that's reasonable. Right? But at the same time, if you wanna take full advantage, I would say it's not like you have to throw JSON, YAML out of the window.

Speaker 1:

So you could do it like gradual, change.

Speaker 3:

Right. Cool.

Speaker 1:

I I this is, I guess, the best foot in the door for a lot of companies. Right? Because so we have this sort of new project that's currently in alpha. Let's use q there. And if it works well, maybe we can port it back to other configurations until it, completely takes everything over.

Speaker 3:

And I can give a brief example. At a previous company, we had a a CI YAML configuration that was, like, 500 lines of code or 500 lines of YAML. And it scared the bejesus out of me because, a lot of those CI steps had dependencies between them because we would build, like, 20 services, test them, and then deploy them. Right? So each of those steps had to have dependencies.

Speaker 3:

And a few times, developers, because we're, like, just monkeys typing on a keyboard, we would forget one of those dependencies, and then we would deploy something that doesn't pass the tests. Right? Mhmm. So I wrote some queue constraints that would take that yaml as input as a value. And that would say for every step with name service deploy x, check that it depends on a step called service test x.

Speaker 3:

Right? You can't do constraints like that on existing data. And I would also do things like check that all the services that we test are also built, check that all the services that we build are named in a particular way and have a directory that exists in this place. There's lots of things that I could sanity check.

Speaker 1:

Really cool. Sounds super useful, I guess. I I'll just I'll just use this, platform before we move, Jonathan moves us to the next topic. Just to use this platform to recommend everyone to at least check out the site. There's a really good documentation.

Speaker 1:

Just wait until there's this one pull request that fix a broken link. Just wait until it get merged, and then you can check it out.

Speaker 3:

Oh, no. No. I'm frantically thinking, oh, no. Where's that pull request?

Speaker 1:

I I fucked up. I opened it without, reading the the contributing guide. It's my it's my fault. My fault. So I wanna

Speaker 2:

talk about another project. This seems to be following a theme of I don't know if you would agree if this is sort of the trajectory your public projects take that you take an existing idea and try to make it better. So the project is sh or s h. Maybe, again, describe what the project is, and then we'll talk about, you know, the applications of it.

Speaker 3:

So the project is it started as a parser for the shell language, meaning post shell and or bash. And I did that fairly year like many years ago because I wanted to learn about parsers. And I saw that Go's parser was written by hand. And I I was straight out of uni, and at uni that I had been taught, you never wanna write parsers by hand. You're just automated with tools.

Speaker 3:

Mhmm. And I honestly found that kind of boring because I it felt like I was learning a tool and learning how to debug and fight the tool more so than writing code. And I'm not gonna say there's no advantages to using a tool. There definitely are, but I I always like just doing things by hand and learning how it works from the ground up. So I thought, well, I'm just gonna use write one for shell.

Speaker 3:

In hindsight, that wasn't the best idea because shell is not a very good language in terms of syntax. It's not like you can write a lexer and then a parser on top of it. Everything is, like, kind of a big mess of of I'm I'm looking at in a way, you cannot lex like, you cannot tokenize on its own. You have to do the whole parsing as a as a single step, if that makes sense as you read the bytes. But that is how it started, just with me having lots of free time and just wanting to play with it.

Speaker 3:

And then on top of that, I started thinking, oh, it could be nice to also be able to format shell syntax. And then I was like, oh, it would be nice if I copied the Go fmt idea, and I wrote a shell formatter. And then from that, somebody asked, hey. It would be nice to have an interpreter. So I also wrote 1, but a lot of this is best effort.

Speaker 3:

Like, I could I would say I've probably implemented 70, 80% of Bash in terms of what most people use. But Bash is a language and as an interpreter, as a shell. It has a tail end of features that nobody knows about and nobody uses

Speaker 1:

Mhmm.

Speaker 3:

Or some people use, but I I don't have

Speaker 2:

the time to implement all of those, of course. Is there a practical application then for using a Go interpreter for bash scripts? Or is it just a a hobby, a fun project?

Speaker 3:

For me, it's mainly a hobby project. I spend as much time as I want on it, which these days is not a lot. Mhmm. Because shell is shell can be a little bit infuriating to use. So it's even more infuriating to implement in many cases.

Speaker 3:

Like, for example, splitting words into fields, into strings. Right? It's it's surprisingly difficult to get right. I've had to reimplement it a a few times. I would say that shell is a language.

Speaker 3:

Like, it's it's very much hated by many people, and it deserves that some of that hate. But at the same time, it's ubiquitous. Right? It's in many places. And I think I think having tooling to be able to deal with it better than nothing or better than just bash the tool.

Speaker 3:

Because bash the tool, they can interpret, and but that's it. It it doesn't let you do anything else. Right? So having having some more tools in this space, I think, is good. And and I think I think it's perfectly fine that some companies and some projects build on Shell even with its deficiencies.

Speaker 1:

You're saying that this is like a small hobby project, but looking at the release notes, at least for the version from 5 days ago, looks more serious than a lot of, open source projects with, companies behind them. I'm wondering, are all these contributions yours, or are more people, like, jumping on the bandwagon and contributing to, SH?

Speaker 3:

It's a bit of both. I've started a number of open source projects, with various ideas in terms of whether I want this to be a personal project versus a community project, if you will. This one is one of the earlier ones I started. I I never intended for it to become a thing. Mhmm.

Speaker 3:

Like I said, I I was only trying to learn about stuff and just experiment. Some people have started building stuff on top of it. So they wanna pull me in different directions saying, hey, can you please do this or that? Or just code reviews. I'm perfectly happy with it as long as they don't expect too much of me.

Speaker 3:

But these days, I think the balance is pretty comfortable. I'm happy to review code. I'm happy for people to ask that I prioritize certain certain things. There's even a couple of companies that sponsor me on GitHub because they build something on top of of the project, But it's it's definitely not in exchange for my time or

Speaker 2:

anything like that. I don't set those expectations.

Speaker 1:

There are a lot of related projects like wrappers and, stuff like that at the end. People, like, wrapped it for Versus Code, emacs, Sublime, trunk, Vim, and, you know, it's included in some other hooks, precommits, like, seems like you could use sh to format your shell files even if you don't know that it's your learning project just by mistake by installing one of these plugins. Right? As recommended. Do you know how much usage does this project actually get, like, in day to day?

Speaker 1:

Do you have, like, analytics or anything?

Speaker 3:

There's no analytics, but I I would definitely say that the shell formatter program is the most used part of it. Like, the interpreter, for example, I would say is far less used. Also because it's far less complete. It's much easier to write a formatter for shell than an interpreter. Because a formatter, for example, the built ins and the options doesn't care.

Speaker 3:

They're just strings. Right? You don't have to implement all the logic inside them. I would say the formatter is fairly well established. My main metric being that it's packaged in pretty much everywhere.

Speaker 3:

All the Linux distros and and brew and and Windows and stuff. So that tells me that there's enough demand, out in the world.

Speaker 2:

It sounds I I wasn't aware that existed. I think, it sounds attractive. I'm gonna have to have a have a look at that and see if I can use it to make some of my shell scripts look more consistent.

Speaker 3:

Something I will mention is that there's a caveat section in the readme because something I learned fairly early on is that, like I said, shell as a language, as a syntax, is not super well designed. So it actually the spec actually requires you to backtrack as you parse shell, a POSIX shell. Because for example, if you start if you open 2 parentheses, it's ambiguous whether that means whether you're starting an arithmetic command, like an arithmetic expression, or if you're starting 2 subshells, one within the other. They're both valid options. This so And

Speaker 1:

you have to, like, go back and see if there's a dollar sign at the beginning and stuff like that to to figure that out?

Speaker 3:

No. No. Even without the dollar sign without a dollar sign, if you open to left to open parentheses, in bash, that means an arithmetic command. So you do some arithmetic, and you get the results as success or failure, pretty much. So if you do that in bash, what bash does as an implementation is it tries one path, and if that doesn't parse correctly, it tries the other path.

Speaker 3:

Oh. But but a parser that backtracks is fairly slow and complex because you could be retrying half the script for all, you know. Right? And you could be retrying multiple times in a nested way. So, for example, Go as a syntax is very much designed to not be ambiguous, and that is a great thing because then a a Lexar can just, like, always continue, and it it it always has a it will always finish in one pass, you can say.

Speaker 1:

I'm, like, wondering in between the this topic and that topic that, we're jumping between, if, I were to, you know, start a new development team with you, how would the developer tooling look like? I'm used to just someone opening a scripts folder. It's just a bunch of SH files, no linting, no anything. And that carries you until you're, like, 20 people. But I imagine, you know, with all the stuff we've mentioned, it seems like you we would be like, okay.

Speaker 1:

Let's model our data first and then queue and let's write some, command line tools and go. And it would go much more that way than just let's just hack a bunch of, shell scripts together to set up our, I don't know, CI pipelines and our deployment scripts and all that. I'm talking about, like, the basic developer tooling, not even talking about, like, the main product.

Speaker 3:

I'm I'm actually not that maybe I was more strict and opinionated, like, 10 years ago when I started a lot of this. But these days, I'm fairly lax in the sense of I just wanna get stuff done. If I have to, for example, automate something quickly in CI, I will write shell inside YAML, which is horrible. But I I will be fine with that as a starting point. And the moment it starts giving me pain, it is when when I will get rid of it, if that makes sense.

Speaker 3:

But I I'm not of the opinion that these tools have to be used everywhere. They can be used as long as you get value out of them, which I would say is once teams teams hit a certain size where formatting starts being really important. Right?

Speaker 1:

They're very programmatic, I guess.

Speaker 2:

That reminds me of a question I wanted to ask you for a while talking about, how you set up a project's automation. And and I don't remember how this came up. We we were having a chat on on Slack when you made a just a passing comment that you're not a big fan of Golang CI Lent. I'm curious and I I'm not asking for for shade on on the project unless you really wanna give that, But I'm curious what you what you use to lint your Go projects, if anything.

Speaker 3:

It's a very good question. Like, linting in Go has gone through many ebbs and flows. Like, way back in the day, it was only GoVet and Golint, which were both official, projects from from Go, like official commands. And Go vet has always been amazing. I continue to enforce it everywhere.

Speaker 3:

Golint was never good. Mhmm. But that shouldn't be a a controversial thing to say because it it said lots of things that weren't really issues. Right? It was very aggressive, and it it was just, like, all over the place.

Speaker 3:

Many of the things it said were just, like, stylistic knits, if you will. And we had we've had other tools, many other tools over the years, And I wrote some of them as well even though I decided against them. I just, archived some of them since. But these days, I mainly enforce GoVet and, static check. Those are the the two ones that are pretty much everywhere.

Speaker 1:

Mhmm.

Speaker 3:

The reasoning being that, at least in my experience, those are the 2 that have a fairly high standard in terms of false positives and in terms of quality. One aspect in which they differ is that GoVet only wants to invest the time in writing checks and maintaining checks that will fire fairly often. So they only one of the criteria for checks in VET is that this has to be a problem that's fairly widespread, where a static check will say, no. No. We have many more checks.

Speaker 3:

We don't really care that much about that. Even if that check only fires, like, 10 times in the corpus of public Go code, that's still fine with us. We just want to have as wide a set of a suite of checks as possible, as long as they're good quality and and so on. And Golang CI Lint, it takes a slightly different approach of it wants to be a meta linter. And there there have been meta linters in Go before.

Speaker 3:

I remember one, I I believe, by Alec Thomas called Go Metal Linter, which I did use back in the day. And the idea is to have a collection of 3rd party linters that do various things and then collect them together in a way that they're easy to run all altogether all at once. I think my main concern with Golang ci lint is that it does that in a way that it mixes tools of very different tolerances of false positives and quality and and goals. Right? So for example, if you run Golang CI Lend with every single Lendr that it includes, which many people do, I would say that probably half of what it's gonna tell you to do is not really, like, an issue that you need to solve.

Speaker 3:

It's like opinions or nets or sometimes even false positives that are not even something to fix.

Speaker 2:

Yeah. I mean, I I I do use Golang CLN, but I find that I kinda have to babysit the config to well, for one thing, you find some rules that contradict each other. You know, one one says you should, name every every variable in a function, and so others another one says that you should collapse those that have the same type. And, you know, so they obviously, obviously, you can't have both of them enabled at the same time. And which one do you choose?

Speaker 2:

I mean, someone has to decide which kind of defeats the whole purpose of Go fmt in the first place. Right? And then you have this other problem that if you're running static check and revive, they have some overlapping rules. And you're gonna either have slightly different versions of the same rule with one versus the other, or you need to go in and manually disable one of the versions or something like that. So, you know, there this it's a bit of a chore to keep it to keep it working.

Speaker 2:

And then, you know, whenever a new version comes out and things change, you have to go and babysit all that again. So there's definitely something attractive about sticking with something like whether it's static check or Go Critter or whatever. Sticking with one of them, I could see being a very attractive option.

Speaker 3:

Something I will say is that some of those tools, I do use occasionally. But I I use them as, like, queries to see let me see what they find, and I'm gonna cherry pick some things to fix. But I don't enforce them. Whereas static check and vet, sometimes they have bugs, and I report them for false positives and things like that, but they're very rare. In general, I can just enforce them and forget about it, which is exactly what you're saying.

Speaker 1:

I've recently talked to someone who does dev tooling, and she mentioned that many of the tools that aren't, like, perfect and you have to babysit and you wanna do for, like, Golangsi Island, you know, with just everything on or something like that, it's a good idea to have one version that's a blocking gate. So, for example, I run Golangsi lint with the config that just gives a static check and and vet and that's it. Or maybe just not even use Golangsi lint for that and, like, then like you're saying, just run that. But, like, every night, for example, just run Golangsi lint on the change files from yesterday and see what it finds. And if you want you know, if you look at that report every day and you find someone who like a line that you're looking at it, oh, maybe we should fix it.

Speaker 1:

It shouldn't be a blocking like quality gate that stops developers from developing but, you know looking at it, every night could be useful. I think it's a shift that many people don't do like we wanna add as many blocking quality gates as possible. That's like an approach you can have. The more automated checks the better. But that's not actually true especially if you run the same rules or they're conflicting or whatever.

Speaker 1:

It it could be very frustrating. But moving it to a lagging indicator is fine because just like, you said, you can check it at your pace and not whenever you wanna open a pull request. Suddenly, And you're all introduced to a linter you didn't even know about 2 days ago and was updated in Galaxy. Ali, now you have to deal with.

Speaker 3:

Yep. Definitely agreed. Although, I will also say that even for tools that you don't enforce, if their rate of noise is too high, they still become useless in my eyes. And this is what happened with Golint. I think this is what killed Golint.

Speaker 3:

One of one of its rules back in the day was every single declaration has to be documented. And honestly, I would run this at work, and it would complain about so much code that, a, was private or b, was never intended to be like a library. Right? It was only for, for example, part of the main package, or maybe

Speaker 2:

it was only imported in

Speaker 3:

a single place, or maybe it was used like 3 lines further down, and it was fairly self evident. I do think like, I get the point. Like, in general, you should document everything. But in practice, that only applies to public facing API for modules. Right?

Speaker 3:

Like, for the rest, it doesn't really matter that much.

Speaker 1:

Yeah. This is not really Go, but, Rough, the the Rust linter for Python. You know what I'm talking about from Astral? They just released a new version where they deprecated some rules that everybody disabled, which I was very happy to see. They disabled, that you have to add the type for self on a class because no one would do that itself.

Speaker 1:

And what you would write is self colon self. Doesn't help anyone, same for class. They just figured out that every every single user is disabled that, linter rule so they deprecated it. Again, as a metalinter, you can sort of make these decisions that I think that the best practice for the language is x, which is what happens when you run the metalinter with no arguments. Right?

Speaker 1:

It ends up being very opinionated. But again, if you move the noisy rules out of the way, can be useful.

Speaker 3:

Agree.

Speaker 2:

So, Daniel, one thing I've I've noticed about you is that your name pops up a lot in the Go issue tracker. You seem to be active in proposals and, you know, giving feedback and, yeah, seem to be pretty active. I that tells me you have your finger on the pulse a little bit, of the Go project. Do you have any insights you'd like to share about now that 122 is out and we're done talking about that forever, 123. We should be about 6 months away.

Speaker 2:

What kind of insights or thoughts do you have on on the future of Go?

Speaker 3:

I'm fairly optimistic with the fact that recent releases have done have brought a lot. We had a group of Go releases where they were focused on generics, and they were fairly conservative in terms of changing the language or adding big features. Whereas now, it feels like generics is done, and now they're getting a lot of stuff done that is, like, a quality of life improvement type of thing. Like, for example, the new HTTP router that we got in 1 22, that you could say that should have happened 5 years ago because it's it's such a relief. Right?

Speaker 3:

But at the same time, I'm so glad that it's finally being done. And I I think we will continue to having releases like that maybe for the next few years. Maybe, like, there's a cyclic thing where in a few in a couple of years, they will say, okay. Let's do something big like generics again and just stop messing with little things. But I I am very happy to see things like, for example, the V2 of MathRand is also very good.

Speaker 3:

Structured logging was also a pain to deal with before we had a standard one. There's also Encoring JSON v 2, even though that's a different beast. So but I'm really happy that the project is tackling these, what you could say, little things, which are not so little.

Speaker 1:

They they add up. They add up.

Speaker 3:

Yeah. And and something I would recommend as well in terms of following what things are happening, I started doing this by just reading the commits that went into master because I I was using Go. I wanted to contribute, but you're always in this position where you say,

Speaker 2:

I don't know where to start or

Speaker 3:

I don't even know what's happening. Like, I don't know why they're doing the things they're doing or or how they're doing them. So I I did start following the issue tracker, but I I think reading the commands that went into master was the most useful in terms of understanding. Also, because they read good commit messages. So even to somebody that is not super experienced with Go, you can read the context and usually understand most of what's happening.

Speaker 2:

Is there anything that jumps out at you? I know it's still early in the cycle, but that that's already been merged or that is on on the horizon to be included in 123 that you think is is worth calling out?

Speaker 3:

I think they're spending quite a lot of effort on PGO these days, the the compiler and front end team, you could say. Because PGO already PGO already landed in I can't remember if it was 121 or 122. But for now, it's only been used for fairly simple things. But now they're saying, okay, it's time for the compiler's function call inliner to get a lot better. And the way they're making it a lot better is with PGO information.

Speaker 3:

So up until now, it was fairly static in in in terms of guessing what function calls should be aligned in a static way. Whereas for 123, there's an issue called overhaul the inliner, and and the main idea is to do that through PTO. And I think that could be one of the bigger compiler improvements of recent times because in some in many like, there's been big changes in Go in terms of toolchain that improve performance, like, when we switched to the register calling convention, some time ago. Also, when PGO landed itself, as it is, which I think was, like, a 5% improvement in some cases. But I think a better inliner is gonna be another big maybe not double digit, but certainly noticeable improvement in performance.

Speaker 2:

A bunch of single digit improvements add up to double digit improvements over time, though, don't they?

Speaker 3:

Yeah. And it also depends on what kind of software you're writing. If you're writing software that just, like, does a lot of CPU logic and function calls and conditionals and stuff, better inlining is gonna unlock a lot of improvements. Because with the compiler, you have these situations where you cannot, for example, simplify some Boolean expression, because part of it goes to a function call, right? So if you can align things, then other compiler improvements can sort of kick in again.

Speaker 1:

Yep. I think you have tools today even before PGO landed. You could really push performance if you're, like, application was data intensive, you could use arrow with go right we had that person on the on the show and you could use profiling and the language is was already minded towards performance And it's kind of, at least for me, I'm I'm wondering when we will stop. Like, when are we getting to the point where, okay, we cannot improve a Go runtime anymore in terms of performance. So every time they I hear someone go, oh, we can take a look at this part and improve that part.

Speaker 1:

And I'm like, oh, right. I'm wondering when the law of diminishing returns will kick into play and it would be better to focus on, other areas. But I guess faster is faster. You can't argue with that.

Speaker 3:

There's definitely a trade off. And Go is Go is not like the languages like c plus plus or Rust where they say the optimization is king in terms of we don't care if compile times get slower. Because in in Go, there is there is that trade off that that is very much at play. And they have rejected compiler optimization steps that would be too expensive just because they say, maybe we think this will make programs 1% faster, but it's also gonna make compile times 50% slower. To us, that's not a good trade off.

Speaker 3:

So Go is not a micro optimization language. But at the same time, if you have spent enough time optimizing your Go code with pprof, with tracing, with whatever else, you will have run into the limits of how fast the language can go. Right? And I think one of the one of those biggest limits right now is the inliner just being too simple, bad. Because, for example, if you have a hotpath that just spends a ton of time calling out to other functions, because calling functions is relatively expensive if you do it enough times.

Speaker 3:

Right? If if that is your biggest contributor to a hotpath, you cannot get rid of it unless you manually inline the function call, which is a pain. It's a pain to maintain. It's a pain to do. Right?

Speaker 3:

So I definitely think that's this is a good thing to to improve the inliner.

Speaker 1:

So you can improve the inliner for everyone, but it's also cool that you can use PGO for your own, projects. Right? Like, it's not only let's use PGO to improve the inliner. You can take even now, you can take, profiles and shove them into PGO and get your own Copilot working better.

Speaker 3:

Yep. And I and this is a bit meta, but the way Go 1 22 builds the tool chain, such as the compiler and the linker, it uses PGO itself. So PGO made the compiler about 5% faster.

Speaker 1:

There's no better dog food than that. Right? Cool. Daniel, before we let you go, we have one stamper questions. We ask all our interviewees.

Speaker 1:

You're the second because it's a new one from last year. Last year, we asked everyone what feature would they add and what feature would they remove. And because we had so much interviews, pretty much ended up with the entire issue backlog, on both sides of the, of the equation. Right? Both let's remove it, then let's add it.

Speaker 1:

So what we want to ask is when you started learning Go, you mentioned it was 10 years ago almost. What was most challenging for you or surprising?

Speaker 3:

It's a good question. I came from Python and Java. I I guess what struck me the most is how quickly I was able to learn and get going. Because I remember learning Python and learning Java, and it took me maybe a couple of weeks before I felt like I could walk. Right?

Speaker 3:

Because I I just spend way too much time look reading tutorials and reading documentation and and looking at at errors. Whereas with Go, I think it only took me 3 hours before I was writing an HTTP server. And yes, I came from other languages, so I already knew how to program. But to me, it was super refreshing how I could just run with it fairly quickly. And that is what hooked me.

Speaker 3:

I am not a patient person. I am not a very intelligent person in terms of, like, mathematics or, like, complex languages and borrow checkers and stuff like that. So for me, being able to just run

Speaker 2:

and get on with it is is very important.

Speaker 1:

Cool. I can definitely resonate with that. I I also before I started to go, I started with the c plus plus You can read a file 10 times and not be a 100% sure what every, you know, template, macro, whatever it does. It looks like you needed to be really, really smart to figure it out. And then I joined the team that does go, and I was actually the team lead, and I never did go before.

Speaker 1:

I was like, okay. I have to understand that code really quickly. I read it, and I was like, okay. I I just understand what's written here. Line by line, it makes sense.

Speaker 3:

And and I think the biggest part of that is the human aspect. I don't I'm not a software engineer to be an expert at languages and compilers. Right? I'm a software engineer mainly. Like, my main contribution to my company is is the human aspect and and code reviews and and designing and stuff.

Speaker 3:

It's it's not fighting the macros and the compiler and macro optimizing things. At least that's the way I see my profession.

Speaker 1:

Very cool. If people wanna find you, reach out, what should they follow? What links should they look at? How can they get in contact with you?

Speaker 3:

So I think the main two social profiles that I have, if you will, one of them is GitHub mvdan, and the other one is blue sky, which I believe is domain based. So at mvdan.cc.

Speaker 2:

Very cool. We'll have links to both of those in the show notes. Daniel, thanks for coming on. It's been a real pleasure talking to you about a wide variety of topics. Thanks a lot.

Speaker 3:

Thanks, Steve, for having me. That's a very cool podcast you have here.

Speaker 1:

Great.

Speaker 2:

Thank

Speaker 1:

you. Thanks.