Metal! 🤘 Bare metal go, config libs, building response writers
This show is supported by you. Stick around till the ad break to hear more about that. This is Cup of COBOL for 05/09/2025. Keep up to date with the important happenings in the COBOL community in about fifteen minutes per week. I'm Shay Nehmad.
Jonathan Hall:And I'm Jonathan Hall.
Shay Nehmad:How are you doing, Jonathan?
Jonathan Hall:I am great. I am so excited about this new GCC release. It's going to make my COBOL programming so much better.
Shay Nehmad:So what's going on there?
Jonathan Hall:Yeah, so GCC 15.1 finally supports COBOL. Incredible. It is incredible. So I can start doing all my COBOL hardcore coding with the GNU compiler. I'm so excited about this.
Shay Nehmad:Nice, nice, nice. Link in the show notes of course if you wanna dive deep into that. I know most of the listeners mostly care about procedures and names and things like that, not compilers. So we won't dive too deep into that. But you should let your bank know.
Jonathan Hall:Definitely.
Shay Nehmad:All right. In other news, the security release we talked about yesterday.
Jonathan Hall:Last week. I don't
Shay Nehmad:know why I keep saying yesterday.
Jonathan Hall:I mean, you may have talked about it yesterday.
Shay Nehmad:I I didn't talk about it yesterday. We talked about it last week. Go versions one point twenty four point three and one point twenty three point nine were released with security fix or the OS packet where it was possible to improperly access the parent directory. Mhmm. So exactly the sort of thing when you talk about directory traversals, you can do root dot open dot dot slash, which allows escaping.
Jonathan Hall:It's kind of funny that this happened because that's like exactly the thing this feature was intended to prevent. And they kinda brain farted, I guess, about this particular instance of it and and let it through. But I'm glad they caught it.
Shay Nehmad:Yeah. The the this escape like only permits opening the parent directory itself, not ancestors. So you can't go higher than what you did, if that makes sense, but not ancestors of the parent. Yeah. Or the files within the parent.
Shay Nehmad:So it's not as bad.
Jonathan Hall:Yeah, could have been worse.
Shay Nehmad:But yeah, thanks to Dan Sebastian. Dan Sebastian Thurane for reporting this issue. You can actually go look at the issue report right now, and just take
Jonathan Hall:a look
Shay Nehmad:at the change list and everything now that it's open. Very simple fix, if you use the dot root thing, you should probably upgrade. Yes. This is important. Unlike unlike what we usually say when, this is a niche case of HTML parsing, probably not relevant to a lot of listeners, probably relevant to a lot of listeners.
Shay Nehmad:You should always upgrade anyways, but you know, go upgrade. And upgrading miners, like it's so easy anyway, so it shouldn't be a big deal. You have some none proposal that I'm really excited to understand because I don't understand it. Can you explain what's going on?
Jonathan Hall:Yeah. So there's this new proposal. This has been proposed a few times apparently. But this new proposal is different because it comes with a working implementation. The proposal is to add a Go OS equals none.
Jonathan Hall:In other words, booting your Go application without an operating system.
Shay Nehmad:So Go OS normally I would use it like I would put what operating system I wanna compile my Go program to.
Jonathan Hall:Right? Usually Darwin or Linux or Windows or whatever, whatever operating system you're compiling for.
Shay Nehmad:I'm I I was waiting to see if you will mention Windows on that list.
Jonathan Hall:Of course.
Shay Nehmad:Of course. Of course.
Jonathan Hall:I won't use it, but I'll mention it. Yeah. So the idea is to do OS equals none. So everything, which maybe sounds kind of cool. I mean, I guess maybe first, why would you want this?
Jonathan Hall:If you want to boot directly from say your BIOS or whatever into your Go application, I would imagine this is mostly useful for embedded types of applications. But yeah, that's what you want to do, you don't want to have to install Linux or Windows or whatever. First, you just want have your app, your server, your computer that does one thing and one thing only, it boots directly into it. It probably has some interesting implications for VMs as well. So you could have a lighter weight VM that just boots one application only.
Jonathan Hall:So that's kind of the general use case, but it has a lot of interesting implications because when you think about what are the things your operating system usually manages for, your things like your TCP stack and your file system memory management, a whole bunch of things. These things all have to then be handled by the Go runtime. So the interesting thing to me about this is that there's actually a working or at least mostly working implementation that's being used to influence this proposal. So I think it's getting traction in ways that others never have. It's still very early.
Jonathan Hall:This was only proposed three days ago, but it's getting a lot of discussion. It's kind of an interesting thing.
Shay Nehmad:Originator, this doesn't come out of nowhere. There is a project called TamaGo.
Jonathan Hall:Yes.
Shay Nehmad:It's bare metal go already, which has like, you know, almost 1.5 ks stars. I like the motivation. You're like, oh, it could be useful for embedded stuff. The motivation of the project as they lay it out is reducing the attack surface of embedded systems.
Jonathan Hall:Oh, right, yeah.
Shay Nehmad:So when you push out sensors to the field that do something, you know what I mean? Just like, and you need to run some code on them, and you don't want them to become a botnet, it's a lot easier if they don't run Linux and C libraries on them, but just your code and nothing else. Right. Because that normally makes them even even if they're not super secure, they just don't show up on like scans for botnets and things like that, which I think is the main attack factor you're worried about with embedded stuff. Although maybe also, you know, smart locks things like Like, that's very interesting.
Shay Nehmad:My thought process is also if you wanna create, like, a Go thing that runs before you run the operating system. If you wanna do, like, sandbox your machine or something like that.
Jonathan Hall:You wanna rewrite Grub and Go?
Shay Nehmad:Yeah, basically. Like, why not? I'm sure there's some cyber security companies out there that it's relevant for them.
Jonathan Hall:Mhmm.
Shay Nehmad:So is this like obvious gonna go in or is this like, this is this bad for Go in general because it introduces a lot of, new things that it has to deal with, but it's good for Go, you know, OS none specifically because it becomes available? Like, what's the what's the vibe on the discussion right now?
Jonathan Hall:I think it's getting serious attention. I mean, I see well known Go team members and other prominent Gophers commenting that this looks fascinating. They'd like to look at this more closely, and not getting the sort of dismissal you would expect from something that might seem outlandish if it didn't have- What do
Shay Nehmad:mean you would expect, Jonathan?
Jonathan Hall:If it didn't have a working prototype attached to it. So yeah, I guess I'm also curious if the no OS would work on all architectures or if it would be limited to certain architectures, at least initially, because I don't know.
Shay Nehmad:From my voice, it's limited to specific architectures. So if it's based on that, I assume it's gonna be limited as well.
Jonathan Hall:Yeah, I imagine the same. But yeah, well, it'd be fascinating to see because of course different hardware platforms have different requirements when it comes to implementing a file system or a network stack or talking to the video driver and all that, or the video driver, but the video hardware and all that stuff. So quite fascinating. Yeah, I have no prediction whether it will ultimately be accepted or not. But the fact that there's a live vibrant project behind it, I think increases those odds drastically.
Shay Nehmad:Yeah, I think one of the things that's very interesting here is this is not actually anything new other than the Tamago implementation, right? So this proposal is just like, hey, core team, support this.
Jonathan Hall:Like, don't
Shay Nehmad:the core team have enough to deal with?
Jonathan Hall:So I could see that argument for sure. And like I said, like I was alluding to, there's a lot of different hardware out there regardless of the CPU architecture and stuff like that. It's like, how you talk to a video hardware on an old Mac or on a Raspberry Pi or on whatever sorts of hardware might matter? There's a reason operating systems are complicated and I don't know how much of this they're wanting to take on, but I could see that being a deal breaker. You know, if Go runtime now has to support 15,000 different video chipsets, I'm sure they don't wanna do that.
Jonathan Hall:So, I don't know. It'll be interesting to see what happens here. I think in principle, like the idea. I don't know if the all the particulars, which I mostly haven't thought of, really make it practical.
Shay Nehmad:And by the way, don't like, I remember a talk from the recent the latest Go thing I went to, the Go for Con Israel, that talked about like, hey, if you wanna do embedded, you can use TinyGo. Why not just use TinyGo? Like what's the difference?
Jonathan Hall:I'm pretty sure TinyGo still needs an operating system of some kind. But somebody asked this, how do you see the overlap with usage of TinyGo? And the person who made the proposal, whose name is Andrea Barzani, his answer is, I don't see overlap as TinyGo's different implementation, which also targets entirely different classes of targets, different instruction sets, and doesn't provide 100% compatibility with runtime and or the language. And they have an FAQ entry about that as well. So this is clearly something they've thought about and at least the Tamago group feels that it's justified to be a very separate project, so.
Shay Nehmad:And actually that program for the TinyGo project commented as well. Generally he said he's excited about this. I I think that we can summarize this as a low level nerds excited by proposal, not no model understands. You saw a library that maybe I can't figure out. Can you tell me a little bit about that on Reddit?
Jonathan Hall:Yeah. So I was scouring Reddit this week for interesting stuff and I came across this post by r3z4boris called, I've built the most ergonomic Go config library. I'm curious, before I talk about the details here, Shai, how do you manage configuration in a typical Go project? Like if you were starting from scratch, not something inherited that that you have to go with their choices. How would you do it from scratch?
Shay Nehmad:Until I got to three or five configuration values, would just envar it with no library.
Jonathan Hall:Mhmm.
Shay Nehmad:Because it's easy to add, but it's kinda hard to mess with. And then I would define my own config struct and use something. Usually I end up doing the CobraViper thing. Although I don't love it, I end up doing the CobraViper thing just because I'm so used to it, and there are so many examples, to like load the configuration from like a JSON or YAML or TOML file and allow overrides with environment fire builds just because it's easy for, like, staging versus production kind of thing Mhmm. Versus local development.
Shay Nehmad:That's usually where I stop. That's usually good enough.
Jonathan Hall:Cool. That's pretty close to what the author of this library claims is sort of his default. He points out a couple issues he has with this. One is that you typically end up your configuration struct may end up with substructs in it. Say you have a Stripe integration, so you want to have your Stripe config in a struct and you have database configuration in a struct.
Jonathan Hall:And these are all pointed to by a master struct. So you end up with your configuration of Cortis sort of sprawled out in various parts of your application. They're not centrally defined somewhere. And then when you use the configuration or validate it, you have that sprawled out in various places and so on. So he talks about the problem of configuration sprawl and having multiple sources of truth, defining your structs in different places.
Jonathan Hall:So his goal with this library called Zero CFG is to simplify all that and mimic the standard libraries flag package to handle YAML and TOML and arbitrary other types of configuration environment variables. So that's that's the gist of this library. I'm curious if you have thoughts on that already.
Shay Nehmad:Yeah. I I also like building Straumann and then winning arguments against them. It's really easy and fun. But no, in reality, there is a problem with when you define your configuration that you have to put tags, right? Have to put struct tags as well.
Shay Nehmad:But I don't know, it doesn't feel like a real problem to me because, yes, you can put your configuration all over the place and the validation all over the place and the defaults all over the place, and then you're gonna have a bad time when you wanna figure out what your configuration is. But you can just have a file called config. Go and not do that. Like, is forcing you, there is no technical limitation that's forcing you not to arrange your code in a way that avoids these. It is true that you have to put tag fields with metadata and nest structs for hierarchical settings, but that's just fine.
Shay Nehmad:And I'm using TypeScript right now in backend for NestJS projects, and that's how I do my config as well. I just make sure that it's all in the config dot whatever file.
Jonathan Hall:Right.
Shay Nehmad:So I don't think it's a real problem. I do think Viper and Cobra and all those, like Viper and Cobra, I always use them together, but Viper like alone, you know, every time I open it, I'm less happy about it because, you know, it's heading towards v two and it has all this documentation and all these options and it's like, I don't know, it feels a bit too over engineered to me and a bit like it has so many users at this point that I like, you know sometimes I'm just like, maybe I can use something smaller. So if zero so I think the Straumann argument is is not relevant, but if zero CFG is awesome, I I would check it out. Is it awesome?
Jonathan Hall:Well, I think it depends on your your taste. My complaint after looking at it for an hour or so, best I can tell, unlike the flags package in the center library, it requires that you use global configuration state. So there's no way to like instantiate a config object and pass that around to your tests and so on. You have to depend on global state, which would make testing a bit awkward. And even when I'm using the flags package, I like to use objects because I just feel like they're a cleaner way to deal with state rather than using the global functions in the flag package.
Jonathan Hall:Also, don't really like the flag package. So building something based on that would not be my preference in the first place. So yeah, I guess I have mixed feelings. So on the one hand, I think you're essentially right. That is a straw man argument.
Jonathan Hall:I have had some complaints about basically the pattern you described for configuration. The biggest one being using struct tags feels clunky, especially for they tend to get overloaded. You specify here's what the JSON key is or the YAML key, here's what the environment variable version is, here's how the validation works, here's the default value. It's really mixing concerns there. And then many of those things can't really be set in flags.
Jonathan Hall:Like if you have something that the default value of this is built from three other things, then you have to have a function that does that somewhere. Sometimes you have custom validation logic somewhere. So there can be some sort of sprawl of the sort, but I don't think that this solves any of those problems because I'm going have the same exact problem. If I have the option to specify a database DSN or to specify a user and a host and a password, etcetera, all separately, I have to have that same logic to figure that out using this approach as well. So it doesn't really solve the problems that I feel like I have, and I'm not excited about the solution.
Jonathan Hall:So I don't entirely agree with the premise, and I certainly don't agree with the outcome. But that's not to say that some people wouldn't love this. If you like the flags package, prefer to handle your YAML that way, you should look at this.
Shay Nehmad:Generally, think having read over the library a little bit, it seems like a very simple opinionated solution. I might like It might be the case that you don't like it. Like you said, Jonathan, I don't like the the global thing because it makes my tests harder. But if you if you, I don't know, all your tests are end to end tests instead of unit tests, so it doesn't bother you that there's just one global thing because you don't change them between tests or whatever, and that's your decision, then this will work for you.
Jonathan Hall:Devil's advocate though, if all you're doing is end to end test because you never change those configuration variables, you don't need configuration variables, you need constants.
Shay Nehmad:That's not devil's advocate because that's the position you don't believe in. That's just Jonathan's advocate. Yes, of course. All I'm trying to say is, you know, there is, I tried to come up with a scenario where, you know, you pragmatically, you change your configuration variables, like, you know, maybe it's a script that you run locally, right, for internal support agents in your organization, and you just want to be able to override it with CLI, but have a file and you don't care about anything else. This is a good, like it is readable and nice, seems simple.
Shay Nehmad:It's very feature bare, like if you wanna pass a config struct around, or if you wanted to do validation, etcetera, etcetera, you're gonna have to start implementing these on your own. That doesn't mean by the way that you're gonna have a better time with a big ass framework, but I will say that, you know, just for fairness sake, like there are a lot of options there. We said, or Viper or this, but like what about the Elastic one, right? Elastic has a universal config thing, although I don't know if it's very maintained. Like there many configuration options in libraries because people like developing those in Go because Go is good for this.
Shay Nehmad:If the person's claim is that it's the most ergonomic, it's like designed for long term health, efficiency, and comfort, I don't think that's the case. Think this is like the best food of configuration libraries. You can Uber this, this configuration library, it works in a minute, but long term, it's not gonna be good for you.
Jonathan Hall:Yeah. I I have to admit the ergonomic the most ergonomic was the clickbait that got me to read it in the first place. So kudos for picking that headline, even if I don't agree with it.
Shay Nehmad:Talking about clickbait, you're not gonna believe what we have for you in the ad break and the lightning round. Two links you're not gonna wanna miss.
Jonathan Hall:Woo hoo. So first off, we have a new Patreon level by popular demand, meaning one person asked for it. You can now become a Patreon at $3 a month instead of 8. So if you, as our one listener pointed out, if you already support a large number of other podcasts or other efforts and $8 a month stretches your budget, you can still join us for $3 a month. So we have a new Patreon level.
Shay Nehmad:Yeah, it's a membership called Gopher Mini.
Jonathan Hall:It's like an espresso shot of Go news. Yeah.
Shay Nehmad:So this is for, you know, this is a half calf espresso shot versus the Cup O Gopher, which is like a proper cortado. Damn, I want coffee right now.
Jonathan Hall:Who wants coffee? I just made a fresh pot of coffee. Does anybody want coffee? Hey, hey, hey. Who wants coffee?
Jonathan Hall:Does anybody want coffee? Who wants Do we have any new patrons this week, Shay?
Shay Nehmad:I don't think so, but it's a good chance to shout out some of our audience members. Moshe Viner. Oh, wait, we do have Moshe Viner. Moshe Vayner, thank you for joining, Liz Lam, Kelsey Wolf, Jess Brisson, Jay Martin, Jamie, Sager, David, Jose, David, Chaney, oh, Dave Chaney, yeah, I always forget that. Suddenly you see names you recognize.
Shay Nehmad:Gilead, thank you for joining and also being on the show and also being awesome. And all the, and CodeSank, of course, every time I see it. Rob Prentice, Adelina, of course, friend of the show, Thank you all so much for supporting and more. This is the pagination limit we have so far. We really appreciate all of you.
Jonathan Hall:I'm gonna let you talk about the next link because it's really your link.
Shay Nehmad:It is, it is. So I'm arranging a Go meetup in San Francisco, and it's going pretty well. It's being sponsored by Elastic and in the meetup, we're gonna record the episode live, which is super cool. So if you are in San Francisco in May 27, we're gonna meet up at 5PM at Elastic's offices. There's gonna be food, there's gonna be swag, Josh Bleecker Snyder's gonna give a talk, Ishai Shore is gonna give a talk, I'm gonna do the podcast episode, which is sort of a talk, actually originated, like the podcast actually originated from Go Meetups, right?
Shay Nehmad:Yeah. So this is a full circle kinda thing. Mhmm. We're gonna talk about what's new in Go. Nice.
Shay Nehmad:And also do a sponsored interview with someone from the Elastic team. Because they've been kind enough to host this event and we're really really happy for them doing that. I'm gonna ask for two things. If you are in the Bay Area, try to make it because I really want a lot of people to come. I'm new here and I wanna meet you all.
Shay Nehmad:And if your company has like an SF or even a Bay Area office, let them know. Like, again, I'm new here in the Bay Area and the reason I'm doing this meetup is just so I know who are the gophers like around me, you know what I mean? Which is good for for many things, professional network included, but it's also a lot of fun. So you know, if you know where to push this event, please do that. There are two links in the in the show notes, one for Eventbrite, one for Luma.
Shay Nehmad:I don't know why, but people here in the Bay Area, they like Luma more. So so yeah, try and push it. I would really appreciate it. And I'm sure Elastic would as well, and maybe they would continue to sponsor us, which would also be cool. So yeah, go meet up in San Francisco.
Shay Nehmad:I'm excited and kind of terrified.
Jonathan Hall:I wanna do a quick shout out to Christoph Berger, who does the Applied Weekly Newsletter. He is the reason in part that we've kicked off the program with COBOL.
Shay Nehmad:Yeah.
Jonathan Hall:I just want to explain that for anybody who has made it this far.
Shay Nehmad:What's up, Christophe?
Jonathan Hall:Yeah, he mentioned our podcast as he often does in his weekly newsletter and he challenged our title last week, which was something about being surprising. He said it wasn't surprising that we had a new episode out, so we decided to inject
Shay Nehmad:a little surprise there for We're we're starting to bore Chris off. But it's good, GO is like boring software and it it just makes sense that the show is boring as well. I I like being that slot. No no not a lot of drama.
Jonathan Hall:That's right.
Shay Nehmad:Until the next time they introduce, you know, Opt Out Telemetry.
Jonathan Hall:It is, of course, our final spiel here. Share the program with somebody, leave a review, leave a rating that helps promote the show. We don't pay for promotion, so it's all word-of-mouth. Gottogo.dev is the website for swag and for joining Patreon and for emailing us your requests for new Patreon membership levels or anything else.
Shay Nehmad:Yes. And, people have been telling me they've been, using the transcripts to catch up on the show. Like, instead of, listening to old episodes, they would just like skim through them and even summarize them with, LLMs, which I thought was pretty cool. So you can find transcripts on the site as well. Cool.
Shay Nehmad:Let's do a quick lightning round. Let's do it. Lightning round. My thing for the lightning round is not Go specific, but I've been way like this last week, I've been way deep into AI Cursor LLM land. I know people are already sick of hearing of it.
Shay Nehmad:But actually yesterday, I went to AI at the Frontier meetup here in San Francisco with people from some like, you know, head of API engineering at OpenAI, and head of engineering at Stripe, and someone who used to be on the Notion, like one of the Notion founders, like pretty respectable panel. They sat there for an hour and talked about, you know, vibe coding, etcetera, etcetera. So I wanted to share like one blog post that's called From Design Talk to Code, the Groundhog AI Coding Assistant. It's basically about how to vibe code with cursor correctly end to end. The part that's Go ish about this is that basically this person claims that it's really really better to use strongly typed languages.
Shay Nehmad:They use Rust for what they're developing. They claim that using well typed languages is much better for agents, not just LLMs in general, which makes sense to me. And we know that Go is pretty good for LLMs because all the code is formatted the same because Go FMT is built in, right?
Jonathan Hall:Mhmm. Mhmm.
Shay Nehmad:So I would implore anybody who's exploring, you know, using agents, development agents, things like that in the company to read through this. I just wanna bring one quote that's really funny to me from the this is the rule that the person is writing for the LLM, so they embed it into the you know, into cursor and every request you do that this is part of the context, right? You know what I mean? Yeah. Mhmm.
Shay Nehmad:You are an expert software engineer who knows Rust. In fact, you are the software engineer who created Rust. So I I wanted to I wanted to just float like what what is the prompt for you're the best gopher ever you would put for an LLM?
Jonathan Hall:I I haven't thought about that. That's a good idea. I would be afraid to do that for something like
Shay Nehmad:Pearl or
Jonathan Hall:or Ruby, like, an
Shay Nehmad:expert GoLang engineer. You listen to Cup of Go religiously every week. Oh, no. No.
Jonathan Hall:I'm afraid what kind of result that will produce.
Shay Nehmad:In fact, instead of writing code, a % of your day is spent debating on GitHub issues. Alright. So that's my thing for the lightning round. A pretty cool blog post on a pretty cool out there blog called ghuntley.com, which is pretty cool.
Jonathan Hall:Cool. Well, I wanna shout out a blog post came out May 7, so it's pretty new. It's called Build Your Own Response Writers, Safer HTTP and Go. I don't know how many people realize, but the Response Writers, if you're building an HTTP handler, the Response Writers is an interface, which means you can implement your own. Oh really?
Jonathan Hall:Yeah, I've done this a few times, but the blog post goes into some details about not only how to do it, but why you might want to. Maybe you want to enforce certain behaviors or the certain headers are always set or require a handler to specify a status code rather than assuming 200 if it doesn't get one and stuff like that. So this is the lightning round, so I'm not going into details, but it's a cool little blog post, pretty quick read. And it kind of gets into, I wouldn't say the depths of go, but some interesting implications that many people probably don't think about. Comes from Antonio.
Jonathan Hall:Thanks, Antonio, for the great blog post. We'll have a link in the show notes.
Shay Nehmad:I love the person's blog. Colors are so nice. Cool. Well, that makes it for our show. We'll see you all next week.
Jonathan Hall:Program exited.
Shay Nehmad:Goodbye. Program exited. Goodbye.
Creators and Guests
