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 storyBuild SaaS apps in GoBuild a Google Analytics in GoPlease talk about the podcast, share the episode, join the slack channel. Purchasing my courses and Patron are great way to monetary support the show.
--------
31:46
--------
31:46
063: Common mistakes when testing with Jakub Jarosz
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 websiteMailing listLinkedInBluesky
--------
57:55
--------
57:55
062: Your Go linters don't know how to fix your code
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
--------
20:29
--------
20:29
061: As a Gopher I'm excited about Gleam, maybe you'll too
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.
--------
35:33
--------
35:33
060: 10x Developer, or 10x Distraction? A Reality Check on AI
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 ;)
New Zealand