To bot or not to bot? • The Applied Go Weekly Newsletter 2024-10-13
Your weekly source of Go news, tips, and projects
To Bot Or Not To Bot?
Hi ,
LLMs are getting better every few months, and the discussions about the pros and cons enter a new round every time a new model is released. Some claim to observe skyrocketing productivity, others warn about decay in code quality, up to producing severe security holes without noticing. Did you try an AI coding assistant already? I did, and I share my findings in this week's Spotlight.
Plus more insights, from circuit breakers to self-hosting container registries.
Enjoy!
Featured articles
Writing a circuit breaker in Go
In distributed systems, "breaking the circuit" means to stop a repeating operation that has a high failure rate, such as sending requests to another service when that service is overloaded. A circuit breaker reduces or blocks further requests until the failure rate falls under a certain level again.
If you want to learn how a circuit breaker works, simply build one in Go, with Redowan Delovar's help.
Reflecting on Go Reflection
Neil Macneale apparently disregarded the Go proverb, "Reflection is never clear" when he dug into reflection to solve a problem that—admittedly—calls for reflection. Here is his report from the rabbit hole.
Go sync.Map: The Right Tool for the Right Job
What distinguishes sync.Map from the standard map type, and how does it work? "How", as in, "how, really, and deeply, and in every detail? With diagrams, please?"
Podcast corner
Go Time: Unpop roundup
The most unpopular episode since 2021! Three years after the previous Unpop episode, the Go Time podcast team does a new roundup of the most unpopular opinions in 2022. Yes, 2022. Assume that two more unpop roundups will be coming.
Cup o' Go: 🌬️ Air, Windows, and Shelves; Promise this is about Go! Plus, Willem.dev talks freelance Go Web Development
Willem Schot, creator of willem.dev, the Piet-Mondrian-ish website with interactive Go blog posts, is this episode's guest. You probably already came across these posts, as I follow Willem's blog for new articles to include here.
Spotlight: AI in programming: blessing or curse?
Discussions on social media about AI in programming often take one of two extreme standpoints. Either the AI is a total time saver and productivity booster, or it is an absolute nightmare that destroys productivity, creativity, and code quality.
Granted, taking extreme positions on a topic guarantees high visibility. As so often, the truth lies somewhere in the middle. Although "truth" is a strong word here, given that so many aspects have to be considered that there can't be a single truth. Rather, I observe a wide spectrum of experiences and a field that constantly changes.
So I'd like to share my own experiences with using LLMs for coding, and to make it clear from the beginning, my conclusions neither reflect the unconstrained enthusiasm of the AI tech bros nor the unrelenting pessimism of the eternal naysayers. (Don't get me wrong: optimism and criticism are equally important when dealing with emerging technologies. It's this going to mental extremes that I extremely, utterly reject.)
Here is my setup. I use Continue in VSCodium. Continue is an open-source AI coding assistant that is agnostic to the model used. You can, but don't have to, subscribe to any LLM APIs, as Continue can also connect to self-hosted models via Ollama.
Continue automatically indexes my workspace and can also ingest other context like online documentation or local files. With this context at hand, the LLM can do a lot of useful things, from generating code and chatting about code to modifying code selected in the editor and generating comments, summaries, and documentation.
So, how does it work in real life?
In a recent project, I had to write code to access multiple APIs that were quite similar in nature. I added the API docs as a context to Continue and asked the LLM to write a function for calling each API endpoint and processing the response. The LLM did quite well, and it even provided a sample use case, but for func main, with Printf and log output.
The generated function, however, is supposed to be called by an HTTP handler. I told that the LLM, hoping that it would provide sample code for this scenario instead, with proper error handling as an HTTP handler would do. Well, the LLM did, but it also passed the HTTP request and response parameters to the client func that did nothing with those parameters. I had to remove them manually after I noticed that flaw.
On another occasion, the LLM added "/v1" to the endpoint's URL slug, although the docs state that the base URL already contains the version string. And the model does not know that ioutil.ReadAll is deprecated.
In summary, while I got quite some code created in short time, and most of it was running on the first attempt, I also needed time and a keen eye to spot flaws that creeped in and weren't caught by the compiler. If I had no experience with developing software, many of these logical flaws might easily go unnoticed, introducing subtle bugs or even security holes.
My conclusion: LLMs in their current state are tools that require experience to use, much like a kitchen knife or a bicycle (no stabilizers!). Know what to expect from these tools and how to use them properly, and you get useful results. Or expect too much and shoot yourself in the foot.
But I recommend everyone to go ahead and run a few tests with AI coding assistants. See how far you come, and find out about the possibilities and the limits. If nothing else, you'll surely have some fun along the way.
Quote of the Week: Essentialist nonsense
The idea of a language “being” object-oriented or ‘functional’ or whatever isn’t really useful. Essentialist nonsense. Go, and all languages, have features. They are designed, the designers made decisions about what sorts of features the language would have.
More articles, videos, talks
Complete Backend Engineering Course in Go - YouTube
From "I can Go" to "I know the backend engineering basics" in 2.5 hours (plus your own hands-on time).
Gopher Golang Bookmark (single color) by MatiF100 | Download free STL model | Printables.com
Too bad I have no blue filament!
Fysion Demo from Template to Deploy - YouTube
The makers of Fyne, the GUI framework for desktop, mobile, and browser (WASM) GUI apps, are creating a commercial app builder that is currently in beta testing.
mmar - Devlog 1
Yusuf Musleh detected a race condition in a tunneling server and fixed it by using Go's basic communication mechanism—channels.
Interview With the Go Developer: Jon Rafkind | Golang Project Structure
An interview in written form—no podcast issue, no video. Great for advancing in your pace, taking notes, and reflecting on the content.
Projects
Libraries
GitHub - nidorx/sqlog: SQLog - Connecting the dots
An slog compatible logger using SQLite as the storage backend.
GitHub - Kei-K23/trashbox: Trashbox 🗑️ is a small, fast and cross-platform Go utility package for dealing with OS native Trash Box or Recycle Bin according to user OS. Include clean set of APIs for move file or directory to Trash Box, recovery and put back them to their original place and much more.
Garbage collection on steroids! Move files to your operating system's trash bin with Go.
Goilerplate - Modern UI Components for Go & Templ
Spice up your Go+Templ web app with ready-made UI components. See also rotemhoresh/shadcn-templ in this issue.
GitHub - denpeshkov/httpsign: Signatures for HTTP requests
Sign and verify HTTP requests with one of HMAC, RSA, ECDSA, or Ed25519.
GitHub - rotemhoresh/shadcn-templ: A shadcn/ui port to Go Templ
shacdn/ui without the JavaScript. This project (WIP) aims at porting the looong list of shacdn/ui components to Go+Templ. See also Goilerplate in this issue.
GitHub - go-batteries/bananas: Minimal opiniated golang project setup with api first approach
banana aims to be a kickstarter for API-first server projects, with code generation and a few "batteries" included.
GitHub - templ-go/awesome-templ: A collection of awesome templ related component libraries, techniques, tools and projects.
The a-h/templ library, a type-safe alternative to the stdlib template packages, seems to have become popular enough to get an "Awesome Tmpl" repository. It's still under construction but will surely grow as the maintainer plans to test and add packages and projects related to Templ.
GitHub - jayposs/bobb: DB Tool Using bbolt
A Key/Value server that might serve those use cases where relational or document databases would be an overkill and BoltDB would be a tad too basic.
Tools and applications
GitHub - amoghyermalkar123/selectstar: Your personal Query Manager
Manage your DB queries in one place. Made with Go, Templ, HTMX, TailwindCSS and Bulma.
GitHub - alebeck/boring: The boring SSH tunnel manager
Manage local and remote SSH tunnels in the terminal.
GitHub - kubewall/kubewall: A single binary kubernetes dashboard to manage your multiple clusters.
Pin your kubes to your wall: A web UI for your k8s clusters.
equ command - modernc.org/equ - Go Packages
When tk9.0 was announced, I made a remark along the lines of "this could be the start of seeing CLI-and-GUI chameleon apps.
Now here is the (probably) first Go-TK chameleon app: a TeX math editor that works as CLI and GUI app.
Even if you don't know TeX, you can point&click a complex formula together.
Completely unrelated to Go
Linearizability in distributed systems
It's more likely that you heard of serializability than of linearizability. I did not come across this term before reading Eli Bendersky's article. In a nutshell, linearizability is similar to serializability but focused on a single object, whereas serializability reasons about multiple objects.
At least, the article links to Consistency Models on Jespen.io, so I can refresh and extend my knowledge and understanding of consistency in distributed systems.
This Post Is Not About Python
This post is remarkable in two aspects:
It's not about Python, even though the text might make you believe that.
And it's the first article ever (at least that I know of) whose addendum was published before the article itself.
Self-Hosting a Container Registry
...and lo, there cometh the day when thou findest thyself with sundry security-sensitive containers to deploy, and thou askest thyself, "How might I host mine own private container registry?" And then thou rememberest that the Applied Go Weekly Newsletter didst have that answer in its missive of the thirteenth day of October, in the year of our Lord two thousand and twenty-four.
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