The Cost Of (Avoiding) Dependencies • The Applied Go Weekly Newsletter 2025-10-05
Your weekly source of Go news, tips, and projects
The Cost Of (Avoiding) Dependencies
Hi ,
From custom SQL backends to time as a performance bottleneck: Another week of Go (and not-so-Go-ish) news. Enjoy!
–Christoph
Featured articles
Grafana's metrics backend for go-mysql-server
Grafana wrote a custom backend for Dolthub's SQL engine to support SQL queries in their dashboard. The Dolthub team got curious about how this was made. This article is the result.
Gist of Go: Atomics
Anton Zhiyanov about the atoms of data manipulation.
Subtest grouping in Go | Redowan's Reflections
While it's dead easy to create subtests in Go—simply call t.Run()—it takes careful consideration to group subtests meaningfully when test suites grow large.
Podcast corner
Cup o' Go | 🪿 Goose noose? 🤘 Excellent! 🎸
Jonathan and Andrew watch Go going to run on bare metal! Plus: GopherCon UK, FyneConf, Watermill 1.5, and more.
go podcast() · FreshRSS
Dominic peeks into the functional programming world.
Fallthrough | PHP Was Never Dead
Now the last thing you might expect in a Go podcast is PHP, but here it is...
Spotlight: The freedom to choose what to depend on
While I'm taking a break on the minimalist SaaS series I started in September, I want to zoom out and take a brief look at the idea of minimalism in software development. Specifically, at how to interpret this idea. Think about what minimalism could mean in daily life. You might discover that there is more than one way to approach minimalism, and these ways may contradict each other.
Let me illustrate this:
Consider you'd want to go minimalist. At some day, you decide you need over-ear headphones with noise cancelling, to shut out distractions. You can foresee that you'll need them at your workplace as well as at home.
The catch: - If you buy one pair, you have to carry it to work and back home, every day. Carrying extra baggage around isn't quite the spirit of minimalism. - To commute without a big bag or a backpack of possessions, you'd have to buy two pairs of headphones. But owning two pairs for the luxury of not having to carry them around is also against the spirit of minimalism.
Would you decide for minimal commute baggage or for minimal possessions?
(Or would you turn to become a maximalist and buy not just two pairs of headphones but also a pair of earbuds to enjoy music while commuting? Gosh, this thought experiment gets out of hand…)
Similar dilemmas occur with every software project that strives for minimalism:
- Minimal package dependencies (remember left-pad and xz!) or minimal development work ("don't re-invent the wheel")?
- Minimize the tool set (Neovim + shell) or minimize development obstacles through an extensive set of tools (language server, linters, AI assistant…)
- And when choosing a programming language: Should it be as lean and clean as possible (which might result in having to write lengthy code), or equipped with every possible feature a language could have (resulting in terse code that's quick to write but cumbersome to decipher)?
I reckon most decisions will end up somewhere in the middle between two extremes. But where is this "somewhere" exactly? You can't just say "pick the middle ground" and instantly know which dependencies, tools, or language to use or avoid.
Speaking of dependencies, you might have heard the advice, "use the standard library!" It's a frequent answer to questions on which library or (heaven forbid!) framework to use to implement some requirement. This advice is undoubtedly takes a bow towards the standard library, but it's not universally applicable.
As always, it depends.
I recently discovered an older article by pure chance that puts the usefulness of dependencies in relation to the size of a project (or, to be precise, to the amount of effort put into a project). The author, Eli Bendersky, came to the conclusion that "the benefit of dependencies is inversely proportional to the amount of effort spent on a software project." So, a project with a timeframe of two months between start and shipping can take quite some advantage from using libraries and frameworks, while a long-running project that is developed and refined over years may not get any value from doing so.
My minimalist SaaS project isn't planned as a long-running project; it's rather the opposite: In a few weeks' time, I want to have a running proof of concept that a functional SaaS platform with user management, email and payment integration neither requires writing tons of code nor adding massive amounts of dependencies.
So should I rethink the dependencies part? Would a quick SaaS project be better off bolting some external packages together and call it a day?
The answer is more nuanced than that. First, we talk about a Go project, and Go has a rich standard library that can save you from having to choose third-party libraries for many purposes. Second, there is another factor that drives a decision for our against an external library: the difficulty of the problem to be solved. For example, you can write a key/value store by yourself, but it wouldn't be wise (with exceptions) to attempt to write a production-ready SQL database from scratch. Or take security: anything related to securing an app exposed to the internet is non-trivial. Remember the saying: Never roll your own crypto. (Unless you are a security expert.) In general, the more effort (or risk) implementing a functionality or a building block of an app takes, the more it makes sense to use an existing library.
“Independence is the freedom to choose that which we will depend upon.”
― Craig D. Lounsbrough
Thanks to the extensive standard library, a minimalist Go project can achieve a sane balance between minimal own coding and minimal dependencies with a simple rule: Write low-complexity code by yourself, utilizing the standard library where you can; leave complicated building blocks to carefully selected external packages.
"A little copying is better than a little dependency", a Go proverb says. Note the word "little".
Quote of the Week: Thank you for being annoying - by Adam Mastroianni
Annoyance is the only truly renewable resource known to man.
More articles, videos, talks
How do you pronounce slog?
And how about you? "slog" or "es-log"?
Build a Water Simulation in Go with Raylib-go | by Tim Little | Sep, 2025 | Level Up Coding
♩♫ Let grasses grow and waters flow in a free and easy way... ♬♪
Go's builtin 'new()' function will take an expression in Go 1.26
Go 1.26 will (most probably) enhance the new() builtin to accept an expression, to help save one step when defining a variable from an expression and then creating a pointer to that variable.
3 Critical TTL Patterns for In-Memory Caching
How to manage time-to-live (TTL) properly, with an actual Go caching library as an example.
We tried Go's experimental Green Tea garbage collector and it didn't help performance
Go's new GC version "Green Tea" is still in the experimental phase. Zach Musgrave tested it on real-world code—Dolt DB—with sobering results.
Understand your process stdin/stdout: pipes, inter-process communication, GO
It's not just a pipe dream, or: How to make Go talk to other processes the Unix way.
GitHub - go-monk/playing-with-tls: Understanding basics of TLS by writing small programs in Go
A practical introduction to TLS, disguised as a repository.
Why Your 'Optimized' Code Is Still Slow: Faster Time Comparison
Don't look at the clock so often! Or: When checking the time turns out to be the biggest bottleneck in an in-memory caching library.
Projects
Libraries
GitHub - dbos-inc/dbos-transact-golang: Durable Workflow Orchestration with Golang and Postgres
Systems that offer durable workflows—that is, workflows that can be suspended over arbitrary durations (seconds, days, weeks,...) and resumed from external triggers or timers—typically build upon a central server running the execution engine. DBOS takes a different route: A PostgreSQL database is all it needs. Can a durable workflow system get more lightweight than that? (Maybe, by replacing PostgreSQL with SQLite...?)
GitHub - andrei-polukhin/pgdbtemplate: Go library for creating PostgreSQL test databases using template databases for lightning-fast test execution.
A database can be both a bottleneck in integration or end-to-end tests (by requiring migrations to run for each test) as well as a source of unreliability (by causing interference between tests). This package and PostgreSQL's template database feature come to the rescue.
GitHub - siddarthkay/react-native-go: A starter template with react-native and golang to demonstrate communication between a golang backend and a react-native client.
Specifically made for building Android and iOS apps.
Tools and applications
GitHub - nanvenomous/where-to: Highly ergonomic and portable helpers for terminal navigation.
A quite unconventional approach: Package your most-needed shell functions inside a Go binary for easy distribution.
Completely unrelated to Go
The grind won't get you there | Swizec Teller
Advice for managers and managed ones.
Organic Growth vs. Controlled Growth: What Kind of Garden Is Your Codebase?
Not far from where I live, there is a castle with two gardens: an English garden and a French garden. The French one has strict, straight lines while the English one looks organically grown (while being the result of planning, too). I had to think of these two gardens when I read this article.
Real AI Agents and Real Work - by Ethan Mollick
They do tasks, not jobs (yet).
You Want Technology With Warts
About every software product grows ugly over the years, mostly not on the UI but inside the code. But sometimes, these "warts" are just a sign of care.
Happy coding! ʕ◔ϖ◔ʔ
Questions or feedback? Drop me a line. I'd love to hear from you.
Best from Munich, Christoph
Not a subscriber yet?
If you read this newsletter issue online, or if someone forwarded the newsletter to you, subscribe for regular updates to get every new issue earlier than the online version, and more reliable than an occasional forwarding.
Find the subscription form at the end of this page.
How I can help
If you're looking for more useful content around Go, here are some ways I can help you become a better Gopher (or a Gopher at all):
On AppliedGo.net, I blog about Go projects, algorithms and data structures in Go, and other fun stuff.
Or visit the AppliedGo.com blog and learn about language specifics, Go updates, and programming-related stuff.
My AppliedGo YouTube channel hosts quick tip and crash course videos that help you get more productive and creative with Go.
Enroll in my Go course for developers that stands out for its intense use of animated graphics for explaining abstract concepts in an intuitive way. Numerous short and concise lectures allow you to schedule your learning flow as you like.
Christoph Berger IT Products and Services
Dachauer Straße 29
Bergkirchen
Germany