You get an error, ⚠️ you get an error, ⚠️ you get an error. ⚠️ Everybody gets an error! ⚠️⚠️
This show is supported by you, the listener. Stick around to left foot news to hear a tiny bit about that. This is Cup o' Go for 03/20/2026. Stay up to date with the important happenings in the Go community about twenty minutes per week. I'm Jonathan Hall.
Shay Nehmad:And I'm Shay Nehmad. It's gonna be tough to stick to the twenty minutes Oh, yes. Frame this week. We have a lot to talk about. But first, how are you doing, Jonathan?
Shay Nehmad:What's up with you?
Jonathan Hall:I'm good.
Shay Nehmad:How's the weather where you are?
Jonathan Hall:Oh, yeah. It's great. I've got the window open. I can hear the birds singing outside. How are things there?
Shay Nehmad:It's hot. There's a heat wave in California, but last night, like evening, I had a housewarming party, pizzas and wine in the backyard, very American style. It was very nice. And I was like, man, I ate a lot of pizza. I better stay in good shape and eat, like, healthy things today.
Shay Nehmad:Not me. I'm walking into the WeWork office and they're like, free donuts.
Jonathan Hall:I want what?
Shay Nehmad:But I held steadfast. I did not take their promise of carb and sugar. Do you have any alternative sugar you can give me?
Jonathan Hall:I think I could talk about some some syntactic sugar if that would help satisfy your cravings.
Shay Nehmad:Let's take that.
Jonathan Hall:Alright. So I'm gonna try to explain this proposal that's been accepted, but it's it's kinda hard to do in a podcast format. I'll do my best. If if if I if I lose you, check the show notes for a link and you can read it yourself.
Shay Nehmad:So I imagine, like, 20% of the audience checked out, oh, wait until they get to the next item. Yeah. No. No. Stay with us.
Jonathan Hall:We can do it. We can do it together. So this is about generics. So I don't know if it'll affect you, Shay, since I don't think you're using generics much in Go. But for those of you who do use generics, imagine you have a type s that is a struct, and it has a field f that is a function type.
Jonathan Hall:Let's say func int. Okay?
Shay Nehmad:Okay.
Jonathan Hall:So a struct has a function type field.
Shay Nehmad:That makes sense.
Jonathan Hall:Now you have another type that's a generic type. Let's say g with type parameter t of any. And actually, this is a function, not a type. So function to generic function. Function G takes a type parameter of T, which is any.
Jonathan Hall:Okay?
Shay Nehmad:Okay.
Jonathan Hall:Now, can you assign that function, that generic function to the field of your struct? That's the question.
Shay Nehmad:To me, it makes sense because the field of the struct, you said it's a function that gets an int and the generic function takes any. So why won't I be able to do it?
Jonathan Hall:So you should be able to assign that assuming T is int, right? Since the struct is only func int, the struct field is only func int, as long as your generic function matches that signature int, you'd think you'd be able to assign it. Well, the answer is more nuanced than that. You can and you can't assign it. It depends on how you do it.
Jonathan Hall:So if you say you have a variable that is that struct type, let's say s, you could say s dot f equals g, that generic function, and that's fine. It infers the type is int. It lets you assign it. All is well and good.
Shay Nehmad:So what's the so it can be assigned?
Jonathan Hall:It can be. You can also assign it if you use a struct literal. So you say s equals and then say big s for your struct type, curly brace f colon g square brace int. So you're specifically saying, I want to assign this generic function of type int.
Shay Nehmad:So those two Wait. And in the first initialization, I didn't have to specify the
Jonathan Hall:type of did not have to say the type. It was able to infer that.
Shay Nehmad:Wait. So why can't the compiler, I guess, figure out isn't it the It same
Jonathan Hall:is the same thing. But right now, as a go one twenty six and earlier, if you do s equals big s curly brace f colon g without specifying the type in that format, it doesn't work. So the proposal is to make that work because why not? It makes perfect sense. It just doesn't work now for historical reasons.
Jonathan Hall:This proposal has been accepted. You'll be able to do that starting in Go one twenty seven. Was it worth it?
Shay Nehmad:Does it does it matter? Like, I can I can in all places where I use this assignment, can I just use one of the forms that work? You could,
Jonathan Hall:but it's annoying. It's annoying to have to say specifically int when you when it can be inferred. Yeah. Yeah. Of course.
Jonathan Hall:So it's it's not it's not adding new capabilities or making the language more powerful in any particular way. It's just a little bit of syntactic sugar, so you don't have to specify your type in certain very specific situations.
Shay Nehmad:Well, you're right. This doesn't affect me because I don't write this sort of code very often. But I I imagine being surprised by trying to assign it one way and it works and then another and it doesn't work. And it's nuanced enough that I think even Claude can figure it out for me. He'll probably write some Very likely.
Shay Nehmad:Hellish, workaround instead. So I guess good on good on them for fixing it. And this is not a breaking change or anything. Right? There's nobody who relies on the the one of the forms not working.
Jonathan Hall:Yeah. It's strictly additive. So there's no no previously valid code that would be made invalid by this, only the other way around. Alright.
Shay Nehmad:Well, you know what? All this, generics, function type, inference, this is, like, complicated stuff. You know me, I'm just, like, writing super simple code, just like concatenating string with plus, and everything's working and everything's great. No comments there. Right?
Jonathan Hall:Yeah. Nothing to say, on that topic. No reason to string this along.
Shay Nehmad:No reason to string this along is good. Alright. Man, I know a really good string joke, but it only works in Hebrew. Oh.
Jonathan Hall:Some of our listeners speak Hebrew. Go for it.
Shay Nehmad:Alright. So, Go string concatenation performance optimization. So I have to concatenate strings all the time, unlike, writing generic types and then assigning them to concrete struct types. I do it all the time. Am aware that plus is not the most efficient because sometimes I get a string, like someone tell me, oh, please use another function,
Jonathan Hall:but
Shay Nehmad:I actually don't know what's the best one. What's the best one?
Jonathan Hall:Can I say it depends? Nice.
Shay Nehmad:Can you give me, like, a rule of thumb?
Jonathan Hall:Rule of thumb, the best is probably the strings. Builder. Almost never use strings. Builder.
Shay Nehmad:So why is it, better? By the way, we we should say that we're basing this discussion based on a blog post from WinterJung, which is actually it's not super new. It looks like it's from last year. Yeah. So it might not even be, like, the most, up to date.
Jonathan Hall:Don't think anything about this has changed in that time frame, though.
Shay Nehmad:Yeah. For sure. But something, popped it up to my, attention. I got it, like, through some link or whatever. Mhmm.
Shay Nehmad:And I just wanna say the blog is pretty cool. Most of it is, like, in Korean, so it's hard for me to review. But it looks like someone who's a very strong Go contributor regardless in Korea. So, you know, I like I like seeing these, sort of real person blogs. So thanks, Winter, for sharing this blog post.
Shay Nehmad:So what's the best method?
Jonathan Hall:Yeah. So so first off, maybe explain why just concatenating strings with plus isn't ideal. The reason is because in Go, strings are immutable. You can't change a string, right? So if you say string equals string plus, quote, foo or whatever, you actually have to create a new copy of that string in memory, copy the old value with the new value to a new memory location, and the old memory location gets cleaned up by the garbage collector.
Jonathan Hall:If you're just doing that once or twice, generally not a big deal, but if you are doing something like, say, building an HTML output, you know, line by line or something like that or anything that you're doing this repeatedly, you're just creating tons of garbage for the garbage collector to clean up. So what's the alternative? Well, there are several. The blog post goes through using functions like fmt. Sprintf or fmt.
Jonathan Hall:Sprint, strings. Join, bytes. Buffer, and strings. Builder. Strings.
Jonathan Hall:Builder is the new kid on the block. It was introduced only in Go 1.1, what, six, seven years ago. So it's not that new, but of these options, it's the newest.
Shay Nehmad:Eight, right? If we're on 26 and
Jonathan Hall:this is
Shay Nehmad:10. Yeah. Divided by two.
Jonathan Hall:Yeah. Is that how that
Shay Nehmad:It depends if you're rounding it up or down, I guess. Oh. Oh, foreshadowing.
Jonathan Hall:So basically, bytes. Buffer and strings. Builder, which sort of improves on that slightly, is the idea of allocate a bunch of memory first and add your strings to that single allocation rather than replace and delete every time. So that's why strings. Builder is faster because it it sort of collects all your strings together.
Jonathan Hall:And then when you call I don't remember what how you use it anymore, but you you call the finalizer method and it returns the string constructed in one swoop instead of as a whole bunch of intermediate steps. But the reason I don't use it very often is because I'm very rarely doing lots of string concatenation, and for short things, it's very cumbersome. It's, you know, it's it's several lines of code versus just foo plus bar.
Shay Nehmad:Yeah. And, Winder note notes here that in fixed argument scenarios, so not like building, you know, a a very long HTML form or whatever, but, you know, just putting in three strings and putting them a delimiter between them or whatever. Mhmm. You can imagine building a, you know, a a version string. Right?
Shay Nehmad:So one point zero point zero seems like according to his benchmarks, it's kinda the same. If you use plus, it's like perfectly adequate. But always, strings dot builder with the grow method or strings.join is the fastest and most memory efficient. And here's my question to you. Why doesn't GoFix replace all plus calls with strings builder if it's always faster?
Shay Nehmad:Oh. Or at least at least I don't wanna say always faster, but at least
Jonathan Hall:Never slower?
Shay Nehmad:It's always one of the fastest, I guess is what I should say.
Jonathan Hall:So I can think of a couple reasons why. One is technical, that is that I believe GoFix requires a GoFix directive. Maybe that's not strictly true. Maybe it can detect certain patterns and fix them for you, but I'm not certain. So that would be one technical reason that I don't believe that it's possible.
Jonathan Hall:You'd have to go add GoFix directives to every one of your string concatenations to do that, at which point just fix it at the same time. Second, it's not strictly identical in all cases, so it could introduce breaking changes. The example I'm thinking of is where you take the address of a string. Guess you could do it with StringBuilder. You take the address of the return value rather than the string itself, but it certainly would hurt readability in many cases, many common cases.
Shay Nehmad:Yeah, you're just concatenating something for a log and then suddenly VAR builder, strings builder.
Jonathan Hall:Yeah. And so it's not that concatenation is itself bad. Like, maybe you're only using the string once, and so you just need to join foo and bar to use it. And, you know, in that case, using strings builder versus concatenation is probably exactly the same in terms of the operations. It's where you repeatedly add to a string and throw away the intermediate result that is a problem.
Shay Nehmad:It's worth to note that I've ran profilers a few times, and very rarely have I opened it up and have been like, oh, string concatenation. That's the actual slow part in my program. But still very I I was surprised.
Jonathan Hall:Where I have seen the worst abuses of this is the types of programs that somebody might write in Perl or Ruby or Python, where they just don't care about performance anyway. They're you know, if you could just as well write your your program in Python and it would perform adequately, then this is not your bottleneck, so you don't really need to care anyway.
Shay Nehmad:Yeah. For sure. One, I think, unfortunately, final thing for our news section, even though our backlog is screaming, is a podcast. Wait. You put another podcast link here.
Jonathan Hall:Don't listen to this podcast. We're really jealous about our listeners. No. We're not at all. This came up in our our channel, our Slack channel.
Shay Nehmad:Hashtag cup o' go with hyphen's cup o' case on the go for Slack.
Jonathan Hall:That's right. Ashu pointed out that they had a discussion about the error interface over on the fall through podcast. What do you think about the error interface, Shay? Is it a good thing? Is it a bad thing?
Jonathan Hall:Mixed feelings?
Shay Nehmad:I feel like it's it's very simple. It's as simple as as it can possibly be. I I love errors that, you know, have the stack trace and a reason and a code, and then you go, you know, like Postgres, you go to a page that's full of, like, error codes and their meaning, but keeping it very, very simple, it's just a string, right? There's literally nothing else in that interface. I think it's very Go y in nature.
Jonathan Hall:Okay. And is that a good thing or it's a mix?
Shay Nehmad:I think it's for me, it's, it's good because you can always expand on it. You can always, like, be, okay, my error is shrinkable, but also, you know, I'll I'll have the error code and the and the error type and the line where it happened and other tracing information. You can always add more. But I love things that are so simple, you can't substract anything. Okay.
Shay Nehmad:It's it definitely feels at times like, okay, this is a type error. This is just a redefinition of string that's called error, and let's all pretend that it's a special thing.
Jonathan Hall:Oh, it's it's a little different than a redefinition of string because as you said, you can add other stuff to it, right? Can add stack traces or arbitrary other things. So it's it's actually more like a redefinition of any. Oh.
Shay Nehmad:Why? Is any stringable?
Jonathan Hall:It's not, so this is maybe more strictly, it's more like a redefinition of the stringer, the FMT. Stringer interface.
Shay Nehmad:Yes, yes, definitely.
Jonathan Hall:Because you can, through what's often called interface smuggling, add other interfaces to it, like to include a stack trace or error codes, Postgres error codes or
Shay Nehmad:I will just say that definitely the the when I think about an error, the main thing I wanna do is read it so I can understand what happened and then, you know, fix it or ignore it or whatever
Jonathan Hall:Right.
Shay Nehmad:As a person. Like, if an error wasn't handled gracefully or whatever in some spot in my program, I usually I just wanna read it. I wanna read it in, like, my log output to understand what happened. So very programmatically, I I to me, it makes sense that it's a redefinition of of Stringer and nothing else. When I'm writing error handling code in my software, that's where I want, like, the error codes and the, oh, the what HTTP code did you get?
Shay Nehmad:Oh, you got a bad code, whatever. And then, you know, handle based on that. Right. That's specific to, you know, the it it's always gonna be specific to the type of error that I was able to predict had happened. So of course, I don't want it to be part of the error interface.
Shay Nehmad:That's my take on it.
Jonathan Hall:Yeah, I think you're aligned with the fall through guys. The problem is that it's when you're programming error handling, it's too unspecified. It's basically any at that point. For end users, a string is all you need. You want to send a string and that's fine.
Jonathan Hall:The problem is those two consumers of the error have very different needs, and we've only accommodated one of those, the the less interesting one. Right? Which is not very go like when you consider that we had this this we have strict types. We you know, one of the proverbs is any doesn't tell you anything, and error tells you almost nothing else. So the the point of of this podcast or the section of the podcast was that the error interface is is a smell.
Jonathan Hall:And he makes the analogy, what if we had the same construct anywhere else in the language? You know, maybe instead of error, you had some construct that returns a value that just returns that has a function an interface that returns has a function called value on it that returns a string and you use that for everything. Nobody would stand for that, right? We would just be like, that's ridiculous. It's stupid.
Jonathan Hall:I want to know the actual thing. I don't want to have to re parse this string every time I need a value from this this interface. But that's essentially what we're doing with error. Now, we've kind of improved that in the sense that error wrapping has become standard. It was out of the center library in 01/2013.
Jonathan Hall:So you can get at more underlying things, but then you're still at the any inner, essentially any interface where you have to type assertions and big if blocks and so on. So I largely agree with the criticism of the error type in Go. I'm less convinced about their proposed solution, which is to to use return, the multi return capabilities of Go functions to return a placeholder value for every error type your function might return. Can kind of see the argument. So let's say you have a function that could have two possible error types.
Shay Nehmad:It can fail on file not found or like connection failure. I'm going to get the value and then network error and then file not found error.
Jonathan Hall:Now that lends itself nicely to a function that could have both errors simultaneously, as you could easily check the one you care about and maybe pass the other one up the stream, you know, up your call stack to whoever else might care about the other one. You can kind of do that right now with Go with multi error, you know, errors. Join, but it's kind of smuggled through this single error interface. So it's a more explicit way to do error handling. And then each error type could be its own type that has nothing to do with error.
Jonathan Hall:It could be a struct, it could be a string, it could be an integer, it could be whatever you want, right? But the idea is to promote errors from this barely better than any to strict types that you want, and then you return one placeholder for every possible error value your function could return. I'm not convinced that's the right answer.
Shay Nehmad:Yeah. Yeah, go. You're saying let's you're describing it, and what I'm hearing is checked exceptions Java style, where every function has to declare all the possible exceptions it can throw, except you're not only doing it in the signature, you're forcing every caller. Like, can you imagine a useful function that you want to call all the time having to define all of its possible error types, and then you have to, like, get value, comma, underscore, underscore, underscore, underscore, underscore, for, like, ignoring all these error types that you don't care about, but you care about the seventeenth error type. I will say another thing.
Shay Nehmad:Making errors more type compliant doesn't mean your software will be better, because if what you want to do is you want to handle specific errors in a specific way, you know, there are I think there are, better ways to do it. Maybe not super type compliant, safe ways that, you know, are fully verifiable by the compiler, but just programmatic ways that are okay. Like if you really, really care about handling errors correctly, add an error code to every error and create a file called errors. Go and just put them all there. Or create error types in errors.
Shay Nehmad:Go and put them all there because it's specific to your program. But trying to do this sort of structure will not work with any library you're using. So why to do it anyway?
Jonathan Hall:It's not Idiometa Go, so it wouldn't work with existing libraries. But let me play the devil's advocate here a little bit. How do you feel about context values?
Shay Nehmad:You mean putting stuff in context, you're just using it as a bag of values? Right. Pragmatically, I'll put things like the trace ID there. Sure. But not, everything that's, like, mon everything that's noncritical as far as I'm concerned and cancellation signals, go into context, and everything else is explicit variables.
Shay Nehmad:That's that's how I'm thinking about it.
Jonathan Hall:Isn't context values the exact same thing going the other direction?
Shay Nehmad:So I don't think so because context values you choose how to use. If you don't wanna like, if if a library tells you, put the put this and that into context if you want me to behave a certain way, you can do that at the library boundary, but in your code, you can use them however you want. If you want to use them as a bag of values, do whatever. Isn't that the same for errors, though?
Jonathan Hall:I mean, doesn't doesn't the library tell you here are the types of errors I might return?
Shay Nehmad:So no, because the library most libraries don't do that. They're like, I'm returning returning an error and, you know, the error string is going to contain what happened. If you really care about the handling the errors specifically, which is, by the way, a relatively rare case, most of the time when you get an unexpected error, you either log in and move on because it wasn't critical or you crash your software. To me, it's relatively rare, or you retry, you know what I mean, on every error.
Jonathan Hall:I do error handling all the time when I could, so I don't know, that's not my experience.
Shay Nehmad:I do error handling as well. But what I'm saying is it's very rare for me to, based on the type of the error, I look into some specific number or error message and change my behavior wildly. You know what I mean?
Jonathan Hall:I I do that all the time. So, yeah, my my experience is that.
Shay Nehmad:I'll be surprised if most errors you handle, you actually handle. I'm not saying you don't do that a lot. I'm just saying for most errors, it's not the case. But putting that aside, what you're asking is, isn't it equivalent to pass random values in the context to getting random errors that are string? Both are kind of loosey goosey.
Shay Nehmad:I agree. You shouldn't normally put a ton of values in context, And normally a function shouldn't return a million different types of errors that are extremely unparsable. And if it is a highly complicated, sensitive operation that can return multiple errors, then just the normal error interface is not good enough. And then maybe it needs to return multi error or something like that. I there are exceptions where just the normal error interface is not enough, but all these cases, I think you can just wrap it with something that a list of some things like, you know, my apps errors interface or my libraries errors interface that extend error, that implement error.
Jonathan Hall:You can do that, but I think that's kind of the equivalent of having a sort of, you know, application level helper that takes a context and extracts value from it, isn't it? You're working in other words, I feel like that's working around the lack of type safety in a way that, at least in theory,
Shay Nehmad:wrapping shouldn't necessarily be the very simplistic type safety. Working around seems like I'm saying this is not good and I'm finding a different solution. What I'm saying is this is very simplistic. Sometimes I need a more complicated tool or a more powerful, tool, I should say. Alright.
Shay Nehmad:Yeah, reimplementing it is is kind of annoying, but I don't reimplement it the same way every time. Like, when I deal with HTTP or Postgres, I'm looking at codes, and then I have a helper that's like, you know, if if the problem in Postgres or h t if it was HTTP 500 or if the Postgres code was a transaction failed, then I'll send it off to a retry handler. And if I'm working with a different library where the errors, you know, are maybe they don't have codes because they decided to put it all as strings, or, you know, they just work differently, or they send multiple errors and I need to look at Like, error handling is different for every case, so I don't think any way you would generalize errors would help. Like, the way you're suggesting is sending a type with all possible error types.
Jonathan Hall:How would how would I even define that type? It would be individual types, is the proposal made in the in the podcast. Now I I wanna I wanna point out, I'm not convinced that their proposal is a good
Shay Nehmad:Yeah, you're devil's advocating.
Jonathan Hall:Yeah, it does bring up an interesting contradiction, at least in my own thinking, which was I've been a strong advocate for no context values except in extreme cases. Certainly, I wouldn't want to pass a database handle as a context value or something like that, right? But we kind of do that for errors all the time, and I'd never really thought about it before. So I think they bring up an interesting point. As far as context values, I definitely prefer explicit function arguments.
Jonathan Hall:So why shouldn't I also prefer explicit function return values? And I think the same argument applies that like if I get to the point where I have too many function arguments, that's a smell. Maybe if I have too many error return values, that's also a smell. I don't know how that plays out in the real world, though, because I'm thinking about things like context cancellation. Like, does every function that has its context argument need a special context cancellation return value as well?
Jonathan Hall:Because that seems pretty cumbersome. But maybe that's the solution. I don't know. I don't know what the solution is.
Shay Nehmad:I think it's just to spin your own words against you. It depends. Yeah. But I think in most cases, people would be happy to give up a little bit of type safety to get a lot of ergonomics and and, like, speed of development, especially if you can work in the cases where you actually care about it. Like, if I came into a company that was writing Go and they were like, our standard is every and we have a we wrote a specific linter for it.
Shay Nehmad:Every function must define all of its possible error types in the return value. And every time you call the function, you have to address all these values. And, you know, some functions have like 17 different errors, right? They talk to the network and then they write some file and then they do something else, right? Like a main of a CLI could do a million different things.
Shay Nehmad:But at the end of the day, you only care if it's zero or one. If it failed or if it succeeded, and then you can continue on in your shell script or it failed. I don't wanna be the I wouldn't wanna work in such a code base, but, you know, on the other hand, there were places where I've told people, hey, the error handling here is really lackluster, and you gotta look at all the cases, and because this is a critical part of the code, whatever. So you mentioned the passing databases connections in context, setting up a DB connection correctly, it's a great example of a place where I want, like, perfect error handling. You gotta take care of all the cases and retry and whatever because the app depends on it, blah blah blah.
Shay Nehmad:So I think, again, the answer is, like, it depends, which is not great, but it's not I'm not sure the answer is always add all the error types to your multiple return values. I will say this is not a pat it's not a pattern that I thought about, and I can imagine it being useful. Like for a function where I deeply care about the different error types, like one of them is okay and one of them is is breaking or something like that, having a value, like you call the function and then in return you get the result. Non critical errors and critical errors would be cool. I will say that normally in my code, I just have a logger for all this stuff.
Shay Nehmad:Again, because if there was an error and I don't care about it, I just wanna log in and move on, I'll just log it and read it after. Like, that's what I do with non critical errors. So why even return it from the function? It is a side effect. It's like not perfect functional code, whatever.
Shay Nehmad:But realistically, were I to bubble this, error up all the way across the stack, like, what would I do with it? I would stride it somewhere so I can take a look at it after and try to eliminate it at the source. Pragmatically, I I don't know. I I don't love this this idea. It is interesting.
Jonathan Hall:I so when I when I first heard the idea explained to me on on our channel, was I like, that's disgusting. I can't believe anybody would suggest that. After listening to the justification, I still don't like the solution, but I have a stronger respect for the problem, and I will look at errors differently from now on. Maybe a better solution will present itself to somebody. I sort of doubt, though, that they'll be deprecating the error interface in Go.
Shay Nehmad:Oh, no. This is definitely, like, a company specific, you know, the people on fall through might be like, okay. In my company, I added a linter that you can't use error, normally, and you have to import something from errors.go or whatever. So if Chris and Matt wanna come on the show and argue about it some more, of course, you're very, very welcome. We love doing crossovers.
Shay Nehmad:Even though we know, because we talked about it on the show, that, we're not gonna make any more changes to the error. That that was a decision that was made. Right? Stop talking about errors. Yeah.
Shay Nehmad:Well, that makes the show, I think. Let's, jump to a quick ad break. Let's do it. Thanks for listening to our show. As Jonathan mentioned at the top of the show, the show is supported by you.
Shay Nehmad:That means that we have a Patreon where you can financially support us, which is nice because this is a hobby, but an expensive one. We pay for hosting, editing fees, etcetera, etcetera. If you wanna find the link to the Patreon or our swag store or past episodes or all other things, cupo'go, you can go to cupo'go.dev. That is cupo'go.dev. Other ways to support the show, including leaving a review on Spotify, Apple Podcasts, or wherever you listen to your podcasts to now other than reviews, official reviews, also just writing content about the show, like a blog post or whatever helps a lot because it goes into AI, training.
Shay Nehmad:And I think, more and more people are finding us through, like, searching on Chad GPT or Claude, what are some Go podcasts to listen to or what's some Go educational content. So that's a good way as well. But probably the best way to support the show non financially is to tell other people about it. We don't pay for advertising, and we I think we never will. Mhmm.
Shay Nehmad:So, you know, whatever you can do to get the show in the ears of more listeners would be really, really cool. And someone mentioned last week that they're listening to this while working out. So if you're in the gym right now, push, you can get another set in. Get another set in. Yeah.
Shay Nehmad:You rock. Good stuff. Other than this, I also wanted to mention that I have a Go meetup coming up that I'm arranging in SF. If you're in San Francisco, come to my Go meetup. It's next week.
Shay Nehmad:Jonathan, you had two items you wanted to mention.
Jonathan Hall:I have a couple things. Yeah. I'm working on a new podcast, and I'm looking for guests. Podcast about coding with AI. I'm wondering if Shay might become be willing to come on my show at some point.
Jonathan Hall:I have already recorded two episodes.
Shay Nehmad:What's it called?
Jonathan Hall:I don't know yet. That's I don't know. I have an editor lined up. Our well known editor of this show is gonna do it for me. I have a couple other guests lined up, but, yeah, I don't I don't know what it's called yet, but I'm trying to learn about coding with AI kind of in public because I've kind of been a late adopter of this thing.
Jonathan Hall:So if you have some expertise to share, reach out to me. I'd love to have you on as a guest. The other thing I want to share is I have a course coming out.
Shay Nehmad:And I assume before you jump into it, I assume Cup o' Go channel is also a good place to suggest new names for your show.
Jonathan Hall:Sure. Sure. The last thing I wanna mention is I have a new course coming out on boot.dev.
Shay Nehmad:That is awesome.
Jonathan Hall:It is beta testing. It should go public in about a week, into the month of thirtieth, I believe. Official launch. It's about logging and observability in Go. And we have a special offer for listeners of the show.
Jonathan Hall:If you use Cup o' Go at checkout, you can save 25% off your first payment. It could be a monthly payment if you just wanna dip your toes in the water or 25% off the first full year if you wanna pay for a year. Use promotion code Cup o' Go and save 25 percent on your boot. Dev subscription. That's for my course or any other course on the platform.
Jonathan Hall:So I'll have a link to that in the show notes. My again, my course is learn logging and observability in Go.
Shay Nehmad:I don't know how good your course is gonna be. I honestly assume it's pretty good because you've been teaching me Go every week, and I've I've kept up on it. Even though, as you mentioned, every chance you get, I don't write a ton of Go in production. Yeah. But I can definitely tell you, not because Lane is was on the show and is a friend of the show, that but as a user, that the Learn SQL course is really good.
Shay Nehmad:I mean, when my wife was looking for a job, she took the Learn SQL course just to brush up on SQL before interviews, and her feedback was, oh my god. They taught me exactly what I needed for the interview. It's really well done. It's engaging. I've looked at it.
Shay Nehmad:It looks really, really cool. So I'm excited that you're getting a course there as well. Yeah. I'm excited too. Yep.
Shay Nehmad:I hope it'll be well received. What's that promo code again one more time?
Jonathan Hall:Cup o' Go. No kebab case for this time. It's just it's just I don't know I
Shay Nehmad:don't know why they do it at podcasts. Right? They'll they'll say they'll say the promo code 17 times in every
Jonathan Hall:Call that number on your screen right now.
Shay Nehmad:Alright. Cool. Cool, man. Alright. So with that, great news about your new Boot.
Shay Nehmad:Dev course. It might meet up next week. We're all very busy. We may have some exciting travel planned for the summer. There's a lot of things going on in Cup O' Go Land, actually.
Shay Nehmad:We'll, send you off. Program exited. Program exited. Goodbye.
Creators and Guests
