Cup o' Go

For show notes, swag store, Patreon community, and past episodes, visit cupogo.dev.

Discussions & Proposals

📊 metrics for the standard library
🗑️ gorename deprecation
📄 Documentation update for telemetry intentions
(psst; remember to run `go telemetry on`)
🚮 log/slog: add slog.DiscardHandler

Blog posts

🤖 Building LLM-powered applications in Go
❤️‍🩹 I hate that I like Golang

Our gracious patrons support this show. Consider joining as a member, too!
★ 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

Jonathan Hall:

Good morning, Go Nation. Welcome to the Go Gotcha news. Thanks, chat GPT. This show is sponsored by you. This is actually Cup of Go.

Jonathan Hall:

Stick around till a little bit later to hear more about that. This is cup of go for September 20, 2024. Keep up to date with important happenings in the Go community in about 15 minutes per week. I'm Jonathan Hall.

Shay Nehmad:

I'm sorry. I'm a text based, chat interface. I cannot answer this, question. What time, Shay?

Jonathan Hall:

Hi, Shay. Shay, today we're gonna be talking about some proposals, about discarding logs, about why you shouldn't use LLMs to write your, intro, for your news program.

Shay Nehmad:

I think we don't need to talk about that. I think it's already spoken for itself, John.

Jonathan Hall:

We We have a lot coming up today. Stick around, but well, let's kick it off with a discussion that is not yet a proposal about metrics. So this is interesting.

Shay Nehmad:

First of all, there's, like, a life cycle for for code to get into Go. Right? Someone thinks about, the thing. But because Go is such a big project, it has to go through a bit of a a process.

Jonathan Hall:

And by the way, that first step is a big one that a lot of languages don't actually do. The part of where people think about a thing before it goes Yeah. For sure.

Shay Nehmad:

No. But the the every language has its own thing. Right? C plus plus infamously has its committees, which we talked about the on the show with someone who was on the c plus plus committees in the past, the c plus plus standards. You know, there's for Go, it's all in discussions and proposals.

Shay Nehmad:

It's an idea, and then sometimes it goes goes through a discussion with the discussion tab, on GitHub. And from discussion, it turns into an issue, like a proper proposal. Then it can either get declined or accepted. And then someone needs to hand in a change list, and then it gets into the language. Usually, we I wanna say report.

Shay Nehmad:

That's not true. Usually, we ramble about proposals when they're declined or accepted because that's when, it's relevant and actionable for people if they've been waiting for it or if it's interesting. But this discussion, I think I I at least have a lot of opinions about, and I think people would be interested to contribute. Do you ever use metrics in your Go program?

Jonathan Hall:

I do, occasionally. Usually with, Prometheus.

Shay Nehmad:

Why not just logs?

Jonathan Hall:

Well, I use logs too. I don't I consider logs distinct from metrics though. For sure. But you

Shay Nehmad:

can definitely This is my matrix from your logs. Explain the difference sort of, you know Yeah. Segue.

Jonathan Hall:

You want me to explain the difference? Okay. So I think a common trope is that you have logs for for users to explain what's happening. You have traces to help debug what's happening, and you have metrics to explain what has happened. So Oh.

Shay Nehmad:

They they serve

Jonathan Hall:

That's good. They serve. I it's not mine. I didn't make that up. They I lost my train of thought now.

Shay Nehmad:

Sorry. It was just such a good sentence. I think metrics when I think about them at least is, okay, I wanna I want the graph to, like, tell me what happened and what like, how many things have happened in a certain amount of time. Logs are for more distinct, very unique events. Like, I wouldn't wanna see the same log a 1000000 times.

Shay Nehmad:

Because because that I I could just use a metric and raise a counter or whatever. The thing about metrics is usually when I review code and it doesn't have any metrics in it, you know, maybe it's a new service, I already have in my brain, oh, these are the metrics you need to add without thinking. Right? Let's say someone is developing a web service. Without thinking, I'd say, oh, you need metrics around number of requests and error codes.

Shay Nehmad:

Right? How many times is metrics around number of requests and error code. Right? How many times is your service returned to 100? How many times it returned 400, etcetera, etcetera.

Shay Nehmad:

Apparently, someone has been, suggesting adding more metrics for the standard library. The standard library already exposes metrics using the runtime metrics package, but most of these metrics are about to go around runtime itself. Right? Things like Mhmm. How many calls were made to see, and I don't know, things like CPU seconds for the garbage collector, and and things that are obviously interesting but are specific to the Go run time.

Shay Nehmad:

How many bytes were allocated on the heap, things like that.

Jonathan Hall:

Right.

Shay Nehmad:

But, obviously, as the standard library is very useful, right, has a lot of things you can build an actual app with, you end up using the standard library, let's say, h t p server, right, net h t p, Then wrapping it with some metrics. This discussion is about which metrics would you add just to other libraries in the standard library. With the obvious, you know, Nethcp out of the way, things like incoming requests, request rates, and response times, which people have already discussed in this, discussion, I I guess. What else, would you add? I'm, like, thinking about every single package.

Jonathan Hall:

I think what else I would add would depend a lot on the application.

Shay Nehmad:

So you so you wouldn't put it in the standard library is what you're saying?

Jonathan Hall:

Or I wouldn't make it on by default at least. Because it

Shay Nehmad:

might have performance implications? Because it might make the API more complex? Like, why

Jonathan Hall:

not? I would assume performance implications. Although, if it if it's proven not, then I there's obviously no problem enabling it as long as I don't have to consume the data if I don't want it.

Shay Nehmad:

So, obviously, if you raise a counter somewhere and in the previous version you didn't do it, the code's gonna be slower. But I assume, you know, off by default and then opt in, could be a really good idea. And thinking about every single package, I'm like, okay, it should be obviously, it should be client maybe, SQL. Right? You have the SQL database thing, why shouldn't it have query latency and response sizes and, I don't know, error rates and connection pools.

Shay Nehmad:

And I don't know, maybe even things like crypto, how fast or JSON encoding, how fast things were happening. But I think this can go really far, and I think the reason I wanted to bring this up is if you have a case where you wrapped a standard library thing in your software and the only thing you did was adding logs and metrics, your voice is useful for this discussion. And I think this could be a really good pragmatic improvement for for Go. So I'm subscribing to this discussion. There's a button, by the way, on GitHub where you can subscribe to discussion if you're interested in how it's unfolds.

Shay Nehmad:

And I hope to see, you know, some proposal accepted at the end of it. It has certainly a lot of, people upvoting it and liking it and things like that. But people want metrics to just be built in. It used to be, I think, that metrics were like a special thing that you added and you have to really think about and whatever. But now it's totally by default.

Shay Nehmad:

Talking about LLMs, you you know, chat gpt sometimes in hallucinated metrics in in code I asked it to complete without me even importing Prometheus yet. Yeah. So it definitely seems like it should be a part of the standard library in the same way that, you know, error obvious error handling is part of the standard library. It's just part of, developing software today because usually the software you develop is deployed to some place else, and you wanna look at what it's doing. So super interesting discussion, and and if you have anything to add to it, just, jump on.

Shay Nehmad:

Obviously, the link is in the show notes. We haven't said that yet a 1000 times in this episode. The link is in the show notes.

Jonathan Hall:

Well, Shai, I've been thinking for quite a while. Basically, since an LLM wrote my intro this morning, that maybe we should rename the show. What do you think?

Shay Nehmad:

I'm glad you bring it up.

Jonathan Hall:

How about go gotcha news? Oh, what's this? Go rename has been deprecated? Oh, I guess we can't do that. What's go rename, you might be asking?

Jonathan Hall:

So long, long ago in a land far away before go, please existed, that's go p l s for those who don't realize it's pronounced go, please. I was one of you not too long ago. There was this tool called Go Rename. It's an xtoolcmdgo rename. It has been deprecated.

Jonathan Hall:

It lets you rename a a variable basically throughout a Go repository. It's basically obsolete now that Go Please exists and other and other, functionalities. It it has also taken over. That was a very awkward sentence. I'm sorry.

Jonathan Hall:

Anyway, the proposal that has been accepted to deprecate go rename, it'll be given a last tag and then then deprecate it. I guess not deleted yet. I'm not sure when it will be deleted.

Shay Nehmad:

The deprecation process means 2 versions. No?

Jonathan Hall:

Yeah. I think so. So I think it'll be deprecated now, and then deleted at some point in the future. I don't I don't know what 2 versions means for the x tools because those are version independently from Go Go versions. But anyway, don't use it anymore.

Jonathan Hall:

I I haven't used it for years if ever. So just don't use it. Don't rename things anymore. No. That's not true.

Jonathan Hall:

Just rename things in a different way.

Shay Nehmad:

This proposal is very much someone found something old, and then nobody cares. Clearly, if people actually cared about this, there would be at least one down vote. So I don't know. Nice catch by Allen Donovan. I I think cleaning up the old stuff is is almost as important as, writing new stuff.

Shay Nehmad:

You know, the the when you see GitHub, like, the pull request and you see a lot of new code added, you know, it's a junior engineer. You see a lot of old code deleted. You see, like, the red, boxes, you know, it's a senior engineer working. Nice stuff. By the way, this is, unrelated, but I do think the name of our show isn't great.

Shay Nehmad:

I think it's a nice, like, play on words, but it's not very searchable, at least in Israel. I'm, like, hey, search for a Capo. And they're, like, what? What did you say? Capo?

Shay Nehmad:

Mhmm. C a p o. No. No. No.

Shay Nehmad:

Cup like, like a cup.

Jonathan Hall:

C u p p a. Right? Capago?

Shay Nehmad:

It went really badly. However, LLMs aren't doing very very like, a lot better with

Jonathan Hall:

Go brew. Go gotcha news might be more accurate,

Shay Nehmad:

but I

Jonathan Hall:

don't think it's any more searchable.

Shay Nehmad:

Code canoe? Codecano. Combining code and the energy of the volcano. No, thank you. Alright.

Shay Nehmad:

I wanna update on something we talked about in the past. So in the past, we talked about it's also about sort of sort of metrics. It's about telemetry. Yeah. I'm all about sending numbers back home today.

Shay Nehmad:

So proposal to expand the scope of Go telemetry to include Delve and other external tools, which we talked about and even, like, commented on, got accepted. And 2 weeks ago, I've I've been, like, watching this issue. The change has been introduced to the documentation officially, as well. So it it went all the way, not just a proposal, like, I guess, a proposal feels like a non written like a verbal agreement, sort of, because it's not checked into the code. But the documentation for telemetry has been updated, and I think it's a very interesting update.

Shay Nehmad:

It's from Go telemetry is only intended for use in programs maintained by the Go team to, Go PLS, Go vuln check were added as options as well. Like, they were described as options as well. And then it says, Go telemetry is only intended for use in programs maintained by the Go team and their selected dependencies like Delf. A small change, but I think, a big change in mindset for for telemetry. Again, as long as telemetry is opt in, basically, nobody can complain.

Shay Nehmad:

Like, if you don't like your data being sent to the dev team to improve your debugger, it's not being sent, so you don't have to worry about it. So a small change, we talked about it in the past. If you haven't turned on telemetry yet, you can literally run go telemetry on, and that will opt in, which is, a really good idea, and go do that. The command is in the show notes and we'll even send it in the channel specifically as well. What's with the new discard handler you mentioned at the beginning?

Shay Nehmad:

Yeah.

Jonathan Hall:

I wanna talk about logs some more. We haven't done enough of that in this show.

Shay Nehmad:

Yeah. This So we we just need a traces one and we got the whole trifecta. That's right.

Jonathan Hall:

That's right. So I'm sure you all remember s log or slog, the new structured logger that came out in Go 121. Right? I I think it's been a couple of years or a couple of releases now about a year ago. Mhmm.

Jonathan Hall:

There's a proposal to adding this card handler.

Shay Nehmad:

It's already my default. I I never I'm already using it everywhere.

Jonathan Hall:

Yep. Yep. Yep. I've I've used it well enough to learn what parts I hate and work around them without it without being angry. Kinda kinda like error handling and go.

Jonathan Hall:

Like, it it eventually become you know, like it's annoying at first and eventually it just becomes second nature and you forget that you hate it. That's kinda where I am with with s log now. So there's a proposal to add a discard handler, which, I'm in favor of this proposal, but it's not nearly as big a deal as some of the commenters seem to make it out to be, I think.

Shay Nehmad:

Wait. What

Jonathan Hall:

The idea is to have a logger that just it just discards all your logs, throws them away.

Shay Nehmad:

Why would it do that?

Jonathan Hall:

Because you don't care about logs. These are for users, and you're not a user. You don't wanna see logs. No. That's not why.

Jonathan Hall:

You would use it for testing mostly. If you're, writing if you're writing tests and you don't want, to see logs of either log output or or to capture it somewhere or whatever, you just don't wanna discard it, then you can use a discard handler. I think it's a great idea mainly as a convenience because I already have a one liner to to discard logs. You just create a a standard logger that writes to i0.discard and you have a discard handler already. So I have that that one liner all over my code bases whenever I'm writing tests.

Jonathan Hall:

I even wrote wrote I even did a whole video about how to mock the logger. And and that's kind of the conclusion is just write your logs to i0.discard. I've I've also seen some open source projects that like, go to all the effort of creating a, new interface that implements the logger methods and then doesn't do anything like that. So a lot of effort for a test when you could just write to IO dot discard, or when you could just use the new as log dot discard handler. So that's a proposal.

Jonathan Hall:

I suppose the discard handler would be a little bit more efficient than writing to IO dot discard because it could optimize for not formatting your your logs before it discards them. That doesn't seem like a really big concern for tests, which generally are small and run very quickly anyway. But, you know, every little performance benefit helps. If you can improve improve your test performance by 5%, why not? So that's for the proposal.

Jonathan Hall:

It's not yet accepted, but I kind of expect it probably will be. I don't see a lot of negative, reaction to it. It has 57 thumbs ups and 0 thumbs downs. If you feel strongly one way or the other, go check it out and leave your comment.

Shay Nehmad:

So what I'm thinking is I'm trying to think back on, like, the big Go project I've done, where I cared enough about not logging in, tests. And the project has to be of a certain size. Right? Because otherwise, you just, like you create a new logger anyway, and if the test if you're not running Go test with minus v, you're not gonna see that anyway. So who cares?

Shay Nehmad:

Right? I almost never log to files. I always log to std. I always log to s tder. So it doesn't matter.

Shay Nehmad:

I don't have to worry about, like, files being created or anything like that. In almost all of them, I had to create, like, a a no op logger or, or a fake logger or something like that. So this makes sense to this makes sense but something about it does feel like if you can pass, I o dot discard, why just why have that variable built in, not just pass I o discard? It's not like you're asking someone to really program a lot of very complicated things. You're just telling them, hey, write the logs to I o discard.

Shay Nehmad:

Yeah. Is it about discoverability? What's the what's the benefit?

Jonathan Hall:

I suspect discoverability is the biggest win for this proposal. And like I said, I saw an open source project recently that they'd gone to the effort of putting all the all the methods, which is kinda silly once you realize the alternative. So I'm sure if they had seen Iod or s log dot discard handler, they would have gone, oh, let's use that instead. I think that's the biggest benefit in my opinion and and secondary is is the possible performance benefits, but that's not a strong reason in my opinion to to add a new method for testing.

Shay Nehmad:

The main rationale here in the post is, not having to do nil checks for the logger itself.

Jonathan Hall:

But but that's solved with the IO discard thing.

Shay Nehmad:

Okay. Again, I really did have to implement the same no operation handler again and again, when there's an API that logs, which I like, you know, when I use packages from, like, big software, companies, mostly b to b, I always tend to find they they include these sort of things to make their SDK look more serious even if it does have a lot of benefits. And sometimes it actually does have benefits, like you see the logs from, I don't know, some DB, connection handler like driver or LaunchDarkly clients or or or cloud, SDKs or stuff like that. Posthog comes to mind as well. Like, all these sort of companies that sell to other companies, they want their logs to show up in your output.

Shay Nehmad:

So you see what's going on and you're able to debug without bothering their support teams. Right? It's it's better service. So it makes it would make sense for these packages to expose s log and be extremely chatty and not really respect the severity levels that are reasonable. And use, like, info for things that are clearly debugged.

Shay Nehmad:

That sucks in tests and even maybe in general, you just wanna disable that package and set up its logging level specifically. Anyway, s log discard handler. It's also a very easy implementation, which is attractive. Like, it's literally just create an IO discard inside the package. Right?

Jonathan Hall:

I could write that code.

Shay Nehmad:

I'm sure you can. How would you test it though?

Jonathan Hall:

Yeah. It's a good question. I don't know.

Shay Nehmad:

You end up discovering where's, where's the IO discard all going. It's that planet from Thor. What's that called? Sakaar. All the all the log output is sent to Sakaar where Jeff Goldblum lives and makes it fighting gladiatorial arenas.

Shay Nehmad:

Little did

Jonathan Hall:

you know that opting into telemetry sent all your discarded logs to Google. Okay. That's good. Let's take a quick break here. We have have a couple more things to talk about.

Jonathan Hall:

We don't have an interview coming up, but we're gonna do our little ad break thing and then back to a couple more news items before we end the show.

Shay Nehmad:

Welcome to our ad break. We mentioned at the top of the show that this show is supported by you. We wanna thank you all for the support. There are a few ways to support us. The most direct one is to support us financially via Patreon.

Shay Nehmad:

We wanna welcome our new member, Martin Ruby. Thanks for joining, man. We really, really appreciate it. Hey, Martin. Welcome.

Shay Nehmad:

And thanks for, everybody here on our CapaGo Patreon community, all the members, in the channel, in the Patreon, wherever. We really appreciate it. It's fun having you all here. This show is is a hobby for Jonathan and I. We use it to learn about Go and about the process.

Shay Nehmad:

I, for example, learned about Go rename today for the first time. Very useful as it's just getting deprecated. And, you know, we do it for us. However, it is an expensive hobby, it takes up time, and we print out swag sometimes and give it out and editing fees and hosting fees, etcetera etcetera. You supporting the show financially is the best way to make it sustainable.

Shay Nehmad:

If you wanna reach out to us, you can do that at capago.dev, although we might change the name apparently, so be on the lookout for that. But we just we spent the last 2 years building up the brand, exactly the time to do a rebrand, the Capago Gopher Slack channel. It's kebabcase with hyphens, or email us at news atcapago.dev. That is news atcapago.dev. There are a few other ways to support us, mostly telling other people about the show so they can find it.

Shay Nehmad:

If you want to just share it with someone you're talking to about Go, maybe at work, maybe at university, maybe at a meetup, that would be really, really cool. Or you can leave a review on Spotify, Apple Podcasts, or Overcast whenever you, listen to your podcast. And one last time we really wanted to say a lot of thanks to our Patreons and Martin for joining and the rest of the people. You know, Patreon is not a one time thing. So just to be super fair for all the people who have been, contributing every month, we won't mention all of the names all of the time because that will take up all of the show.

Shay Nehmad:

But we really appreciate y'all. You know that.

Jonathan Hall:

If you wanna hear that show, you can subscribe to Patreon. We'll give you a free Patreon members only, Patreon only episode where all we do is talk about Patreon members.

Shay Nehmad:

That would sound like a anti virus. Obviously not. Yes.

Jonathan Hall:

In the spirit of sharing things that you find useful, like this show with your colleagues, I want to do a big shout out today to Fine. They're doing their conference today in Berlin, which I was kinda hoping to go to, but it just didn't work out with timing. I've actually been using Fine for the last few weeks and, been having a pretty good experience. You played it a little bit. Right, Shay?

Shay Nehmad:

Yeah. Mostly, you know, as part for the show, I played around with it before our interview with Andy to learn more about it and how it works. I think I developed a small GUI thing that tries to enumerate news and then I got distracted and gave up on that. And I've been doing it manually ever since.

Jonathan Hall:

Well, I've I've been having fun with it. So if if you're interested in GUI programming, check out FIND. And if you're at the conference today, do us a shout out on the the channel. Let us know that you're listening to the show from Berlin. And, yeah.

Jonathan Hall:

Thanks to to Andy for being a friend of the show. Let's get back to some news.

Shay Nehmad:

Welcome to the second part of the show. This is usually an interview, but we just had too many good news items to discuss, so we decided to make the show a bit longer. Sue us. It's our show. We'll do what we want.

Jonathan Hall:

So Please don't sue us. We don't have any money anyway.

Shay Nehmad:

Yeah. Don't sue us. Building LLM powered applications in Go. I saw this blog post coming on the Go blog, and my first response was I was a bit surprised. Right?

Shay Nehmad:

LLM powered applications is for Python. Right? Because AI is for Python.

Jonathan Hall:

Of course. This is

Shay Nehmad:

just the gut reaction. Actually, when you read the blog post, it's not about building the LLM itself and go. The long and short of it is that most of the LLM stuff you do is, at this point, externalized to other services. You have, for example, a vector database that's good at, storing embeddings, and you have an embeddings model, that an API will provide for you, and you have an LLM that an API will provide for you. So the example they give here in the blog post is developing a RAG server, retrieval augmented generation.

Jonathan Hall:

Do you

Shay Nehmad:

know what that is? No. In very short terms, it's information retrieval. Right? You generate things, but you generate things based on a subset of, like, information you already have.

Shay Nehmad:

Super classic cases, you have a bunch of documents and you want to add labels to each document. Right? So you retrieve the document, but you generate the labels. It's super useful. Right?

Shay Nehmad:

A lot of the things we see, like joking aside about how sometimes funny and awkward and and non human and stilted LLM chats can be, they do have their use cases and, retrieval augmented generation is really one of them. Sort of customize the LLMs knowledge base for something domain specific like your company's documents or your specific users interactions or things like that. The process of building such a thing is you need to have some data, you need to embed it, turn it into vectors, store the vectors in a vector database. You can sort of imagine this is a audio show, so I don't know how well this is will carry, but imagine a room, right, a 3 d room. A vector basically points to a point in that space.

Shay Nehmad:

And when you embed a new document, you find what's close to it, what's near to it in that space. Space. And then when you retrieve it, you find the closer things to it. And then you just pass all this knowledge to an LLM like here are the embeddings here are the documents. Please generate what I want you to generate based on that knowledge base.

Shay Nehmad:

Log post says, this is the normal architecture of a simple LLM application. Here's the architecture. You have an h t p

Jonathan Hall:

server, which Go is pretty

Shay Nehmad:

good at. You can use the Google Gemini API, which is a bit you can use other, APIs that weren't developed by the same company that is behind, Go. I don't know if you've heard about OpenAI or Claude or Anthropic or like any of these, big names in, LLMs. But sure, Google. You have you developed Go, you get to plug Gemini.

Shay Nehmad:

No problem. Even though the first thing I did when I turned it on my phone instead of, like, the old Google citizen was turning it off again because it's strictly worse. It just can't do things. Like, it can't write a note or set up a thing on my calendar or call someone, like but it it can auto generate some BS. Anyway, this is not about Gemini.

Shay Nehmad:

You you have externalized all these LLM things to or or vectorization or embedding, to other services. And then you end up just, you know, writing very simple Go code with the new server mux in go 122, right, where you have the routing enhancements that, you know, handles some HTTP requests and talks to these externalized services, lm, embedding model, vectordb, just as you would any other application. So I'm I I I'm not sure about this, title. While I think it is great for people who are new to programming ish or new to go, and they need a sort of make it your own DIY guide for building in, this specific application. Feels weird to have a blog post dedicated to a specific use case in a specific application without adding anything other than recommendations for use Google Gemini, use Weeviate for the DB.

Shay Nehmad:

Feels very, like, opinionated and application specific. Morning, what do you think about this being on the go blog?

Jonathan Hall:

I suspect it's SEO bait. Everybody's looking for LLM AI stuff, and, oh, we have to do it in Python. I'll bet this is trying to get some of that SEO juice to say, actually, you can do it in Go 2. But I do it just sounds like a more accurate title would be building an LLM powered application with a go front end. That is true.

Jonathan Hall:

The application real like you said, it's these other things. Right? And the front end, it's it's the HTTP server that they interface to it that's really written in Go, but whatever.

Shay Nehmad:

That's the the first part of the blog post. The parts that come after, I'm even less cool with, I guess. The first one is, using langchain for Go which is straight up langchain is a popular framework in Python for LMS. Langchain go, it's that in Go. I haven't used it so maybe it's really good But, it's just sort of weird to see non by the way, this is not by the Go team, like Django.

Shay Nehmad:

It's not like, supported by the Go team. Sort of weird to see this, like, recommendation that looks very official. It's on the go blog, for this 3rd party library who who who knows who contributes to it. Right? Very peculiar.

Shay Nehmad:

And finally, even more peculiar is Genkit. So they're saying, like, earlier this year, Google introduced Genkit for Go, open source framework for building LLM powered applications. It's sort of like langchain, sort of wraps the entire LLM interaction with easy interfaces so you don't have to build all that boilerplate yourself and has plugins and things like that. But it has some production features like prompt management, prompt engineering, and has integrated developer tooling. Which sounds maybe, good on the servers, but I think it's a 100% Google thing.

Shay Nehmad:

Like, you can you can use it with Google AI for developers and Google Cloud Vertex and it does have Olam and Pinecone plugins, but telemetry, it only has for Google Cloud. So it definitely sounds like if you're not using Google Cloud right now, at your company, this blog post isn't relevant for you and therefore, it's a nice blog post. I think it's good that we get more people writing Go even for these use cases because it is better, you know, if you're externalizing all the LLM stuff. But I really don't like these sort of blog posts that feel market y to Google's cloud services in my Go language.

Jonathan Hall:

It kinda reminds me of when you Google for, like, an apple pie recipe and you're told you should use this brand of

Shay Nehmad:

sugar. Exactly.

Jonathan Hall:

Obviously, it's marketing from the sugar company not not, you know, the best apple pie recipe out there.

Shay Nehmad:

The thing is, I I get what you're saying because sometimes these recipes are good. Right? It doesn't necessarily mean if it's commercial and it's sponsored, like our show was sponsored by, a few different companies including, I don't know, COIP. That doesn't mean that, there are better or worse cloud providers out there. I've been following COIP.

Shay Nehmad:

They've been doing really good work. They're not sponsoring me anymore to say this. Right? Right. Sponsored doesn't necessarily mean bad, but there is something about the Go blog supports.

Shay Nehmad:

I would really hate for example, the Go documentation. Right? My ID documentation for the Go language, which is an open source project to suddenly include, oh, the API for in the Go standard library auto auto completes to Google Cloud. Like, that doesn't really make sense to me, especially, and that I have no problem saying this, I don't like Google Cloud. I've used all cloud providers.

Shay Nehmad:

I work at a cloud security company. I haven't enjoyed using Google Cloud. I wouldn't use it again if I had a choice to use, other big cloud provider. Obviously, if Google Cloud sponsors this show, this is I'm I'm gonna sing a totally different tune. But, you know

Jonathan Hall:

So I have no problem saying I like Google Cloud. The only reason I don't use it is because I found cheaper alternatives. But I like Google Cloud. But, you know, opinions are are worth nothing.

Shay Nehmad:

Yeah. Anyway, all I'll say is, this is an interesting blog post if you're looking to write your, you know, chatgpt wrapper, in Go. It has a pretty good structure. It goes over the basics. It has sample code, not in the blog post itself but in links.

Shay Nehmad:

And if you do use if your company is like Google Cloud company in the sense that, you know, most of your production is on Google Cloud or you have maybe a startup agreement with them, this is really like startup credits, I mean. This is really useful. But I do have some comments about the stylistic choices, we should say. So building LMM powered applications in Go.

Jonathan Hall:

Very cool. So you're not gonna jump out and and update your fine app to include, LMM stuff on the Google Cloud now?

Shay Nehmad:

We just had an acathon at at Orca and so many so many of the groups were like x but with AI. It was really cool actually because some of them were really useful, but it's it's getting kinda tiring to me to see x but with AI. I just wanna see good x's. Exactly.

Jonathan Hall:

Let's move on to, a community post and before we wrap up the program. This one comes from Reddit, and it's such a Reddit topic. The title is I hate that I like Golang. And I I think you've read it too. There's just there's a bunch of hot takes in here that somehow I just love, some are kinda silly.

Jonathan Hall:

So the the the author of the original post is apparently a TypeScript developer. He says he learned go in about a week. And then he says, last weekend I had some free time and decided to build a couple of really small projects. And it was a pleasure to do it in go, which he finds surprising because he loves declarative code and Go is completely the opposite of that. Although, if you is TypeScript declarative?

Jonathan Hall:

It doesn't mean I guess it maybe has some of that in it, but, like, declarative sounds to me like Kubernetes YAML files. Anyway, I think the TLDR, if you sort of summarize all of the the sort of opinions here is that Go is easy to like because it's easy to read. Even if you don't like some of the things about it, it's easy to pick up quickly, easy to read, much easier than than with, say, TypeScript. Let me see if I can find the comment that I liked here. I'm finding it right now.

Jonathan Hall:

But one of the comments was to to the effect that when I'm writing TypeScript, I have to think about what the language is going to do with my code. With Go, I don't have to do that. I can just write the code and it does essentially what it what it says it's gonna do. I don't have to think at that metal level, about what it's doing.

Shay Nehmad:

This is, I heard What

Jonathan Hall:

do you think?

Shay Nehmad:

I heard, I'm really trying to remember the guy's name. Peter Bergen, the person who's behind the GoKit, which is framework for building microservices which I really really like. It has a very practical take to just doing small things and dividing things to layers and things like that. I would even hesitate calling it a framework. Said that he had a talk about, like, GoKit and why it's good and why Go is good for these sorts of, things, and he says something to a similar effect.

Shay Nehmad:

He says, like, when I read, Go code, I know what's happening on the CPU, like, there's no extra magic there. You know, when you read Python tests, for example, there's just no way to know what's happening because the something might have been declared in the conf dot test py of the entire project and they got conf dot test py of the current thing on, some pytest, flag that was passed, some decorator to the function, magic mocks that might have been used in the production code. Like there's simply no way to know when you read line by line what function is actually going to be called and every line can throw an exception as well. So you have to think, like, in 4 different dimensions when you try to read this code. Not for any benefit, like, you can do all these things, but you can do all these things and go as well.

Shay Nehmad:

They're just straightforward. Might be a little more pain to ride, might be a bit more verbose. You might try to run, go run, and it's gonna tell you no because you have an unused import. But you know what? That's good.

Shay Nehmad:

I I really agree with that, comment. Just making it I like I like very clear and readable. It's a very practical choice.

Jonathan Hall:

I like one comment here by, Schooner Doner. Schooner Doner. I don't know how you pronounce this name. Start and go feels like buying new shoes, but they somehow fit like you've worn them for years.

Shay Nehmad:

Oof. I need new shoes. That's the only thing I can think about. It is very Reddit y and I hate that I like it, but there's one sense that that really popped out to me which is I'm a typescript guy. Now, we usually don't do this on the show but just like Homelander, I'm I'm talking to you now.

Shay Nehmad:

This it's just you and me here. Alright? Languages are not, religions. Languages are not tribes. Languages are not nationalities.

Shay Nehmad:

Languages are tools. I have a Go podcast, a Go, a Go podcast mug. I'm the head of the Golang guild at my current company. Well, I'm not the head of because it's not official. But I'm definitely one of the people who are who's pushing it.

Shay Nehmad:

I've spoken at Go Conferences, I've arranged Go Meetups. I'm not a Go guy. Go is just a language. It's a tool. And as you as I've matured as a software developer and then software architect and team lead then blah blah blah, I've come to realize that sometimes, you know, there are tools that are strictly better than others but your identity should be completely separate from that.

Shay Nehmad:

Because if you put your identity next to a tool, let's say, a tool that's backed by a company, let's say Google, a company that's infamous for killing, pro, like, things, you know, they might kill Go next year. Who knows? Oh, no need for Go language anymore. We're just gonna have AI write all our code in in in assembler directly. Whatever.

Shay Nehmad:

You know, Go is great but maybe it's not great for all use cases. When I used to write Python, I would be like, oh, I need an ORM. Then I switched to Go and I was like, great. Now I use Go ORM and I'm better. But actually, all this time, I should have learned SQL.

Shay Nehmad:

That's the tool I should have been using. Now I have a good compromise with SQL c, compile SQL to go, to go. There was a recent discussion that was similar. I don't know if you, heard about this, like the Rust maintainer guy who stopped maintaining the Rust for, the Linux kernel project after 4 years. So it's just in their main mailing list.

Shay Nehmad:

Someone's like, I've been maintaining the Rust for, the Linux kernel project for 4 years and I'm leaving because of non technical, blah blah. Like, I don't I'm not sure what's going on there. But it sparked a big discussion about, you know, some people using Rust in the in developing stuff for the Linux kernel exposes a lot of things that, you know, in c you didn't have to deal with because c isn't as strict as Rust about memory management, about the, you know, you have to go through all the cases in the switch, etcetera etcetera. And some people being, no, it's only c. We should only use c for this because it's a better tool.

Shay Nehmad:

Now there is a discussion about whether Rust or c is a better tool for specific use cases. Right? It's a technical discussion that's interesting, relevant, professional. There are a lot of people online especially that disengage from the professional discussion and engage, I'm a Rust guy or like just like Homelander said, I'm a TypeScript guy. And you know, no, the Rust people, they all want x.

Shay Nehmad:

All the Rust people are furries on Twitter and all the sea, people are neck beards in their, you know, garages in Alabama. Like, that's not how programming works. These are just tools. That that sentence just I saw it I was like, it's already a programming language subreddit. Right?

Shay Nehmad:

It's already placed for this sort of, I don't know, tribalism. It just doesn't make sense for me. I don't know I don't know if, Homelander just said like, oh, I know TypeScript. Just decided to write, I'm a TypeScript guy. But with all the recent drama in the, Linux kernel thing, which spent a lot of energy on doing the wrong thing.

Shay Nehmad:

Right? There are vulnerabilities in the Linux kernel that we need to fix instead of arguing about which language will eventually be better. So don't be a go guy or a go girl. Just be a good programmer, I think.

Jonathan Hall:

Alright. I think that wraps it

Shay Nehmad:

up for this week. Thanks a lot for listening, y'all. Fair amount of time. Mhmm. Next week, maybe an episode, maybe not.

Shay Nehmad:

We'll see. Our schedules are a super mess. Jonathan is, moving.

Jonathan Hall:

Yeah. I'll be I'll be out for the next 2 weeks. I'll be in Houston, by the way, next week if anybody if anybody listening is in Houston and wants to meet for a beer, hit me up. Oh. Or not next week, but the 1st week of October, I'll be in Houston.

Jonathan Hall:

Yeah. I'll see you all in 3 weeks then.

Shay Nehmad:

We'll miss you. Thanks, everybody. Program exited.