I retried Podman to replace a production service and did not wanted to re-installed Docker, mainly for security reasons. The fact that podman runs containers on the user-level and completely isolated from the system is a great alternative to the Docker deamon.

I'm trying something new for this episode, I'll try and get audio clips from people to add more dynamism to the episodes, if you can join the Slack channel and also I've started a Patreon if you want to chip in and help me keep the mic on.

Links:

• My new course Zero to Gopher (50% off for listeners)
• Blog post to view commands and the back story
• Build SaaS apps in Go
• Build a Google Analytics in Go

Please talk about the podcast, share the episode, join the slack channel. Purchasing my courses and Patron are great way to monetary support the show.

Jakub is returning to the show, he's about to launch a book called "50 Go Testing Mistakes" and we talk about the most common mistakes Gophers are making when it testing. Having a trustable testing suite is known to be critical for long-live software system. I can testify having maintained a .NET codebase for 20 years without any tests, it sucks.

Links:

• Jakub's website
• Mailing list
• LinkedIn
• Bluesky

One university published attracted my attention, because it was on Go, it's titled: "Assessing Golang Static Analysis Tools on Real-World Issues".
Do you find your static analysis and linters tools could be more helpful when reporting issues?
I'm mixed feeling really, I think that they're pretty damn good. Tools can always improve for sure, not sure if we will need the help of LLMs to mix static analysis checks and LLM analysis / proposed fixes, maybe that will be the next step for those tools.

Links:

• Paper's link

I finally gave Gleam a serious look and ho boy I'm excited. I've looked at Gleam a long time ago back when it started with the ML-like syntax. I've always been an Elm fan, I discovered functional programming with Elm. Near 2016-2017 I tried Elixir and Phoenix, and gave it a try multiple times following the years, but I'm not fully sure why it never clicked completely for me.
As someone engage with Go for the last 10+ years, I won't lie that I was looking for some excitement lately. Not because I'm tired of Go or anything, I've dabbled seriously into Python/Django in the last 3-4 years. But Gleam, at least so far, as this I don't know what that I felt when I started Go back in 2014.
There's so many programming languages these days that I suppose it's really comes down to a matter of taste. I do have some minimal checkboxes that a language must checked before I even considered looking at it, and Gleam was checking them all. It's a refreshing language after 10 years of Go. Just another tool in the toolbox, but I'm extremely picky about which tool I put in my toolbox haha, so Gleam for now is in the evaluation phase, but so far I'm excited and I haven't felt like this for a long time.

The message is everywhere: LLMs are here to make us 10x more productive and change software development forever. Venture capitalists are pouring billions into the vision, and big tech companies are pushing hard for us to adopt the tools. But as a software engineer who’s seen the demos and lived the reality, something feels profoundly wrong.

This week, I’m taking a step back to reflect on the current state of our industry. We'll explore the inconvenient truth that often gets lost in the hype: that relying on AI can sometimes make us slower, introduce more technical debt, and even erode the fundamental skills that make us valuable.

But maybe the real problem isn't the technology itself. Maybe it's that we're looking for a quick fix for a deeper issue. Join me as we discuss what really drives developer productivity, the crucial importance of domain knowledge, and whether anyone is even considering the quality of life for the people building our systems.

Because while the "going from 0 to 1" demo is impressive, our jobs are about maintaining complex systems from 1 to 1000. And maybe, just maybe, an agentic flow that doesn't care about our codebase isn't the real solution we need.

p.s. And yes, I used LLM to improve my description draft ;)

Let's talk with a friend of the pod, John Arundel. We talk about state of thing a little regarding Go's maturity, a bit of AI, I personally am a bit fatigue of the noise and "agent". The podcast is returning slowly. , John has written a new Go book that's beginner-friendly, but goes deeper than you'd expect, he produce excellent learning and training resources.

Links:

• The Deeper Love of Go
  • John's newsletter

Go is used by multiple programmers and software engineers. Lots of path can lead to want to try Go, and this week I talk with Yann whom eventually found Go and talks about his experiences writing internal tools at his company.

Links:

• Hupload
  • YBFeed

The part 2 of my talk with Ivan Fetch. We cover the remaining listener questions and go over some aspects in more details of being blind in tech.

This week I'm joined by Ivan Fetch. We talk about challenges and day-to-day life as tech professionals being blind, using a screen reader. This is the part one as we've a lot to cover. Since I started this pod after telling guests I'm blind and use a screen reader everyone wants to know more, so I thought doing an episode would be interesting to people wanting to know more.

The best way to support the show is by talking about it and sharing the episodes. If you can you can buy my courses which help keeping the lights on for the efforts invested to bring the pod, there's a 50% off discount for listeners of this show: Build a SaaS app in Go and Build a Google Analytics in Go.

This week I'm joined by Tristan Mayo, the creator of Zog, a Go library that helps with validation when receiving data from an HTTP POST or parsing data. 

Links:

• Zog on GitHub