Freedom Of Choice

Hi ,

If you have been writing Go for years, you probably have mixed feelings towards LLMs and their creepy abilities of writing good code, fast. Maybe you even have used LLMs to generate code, and now you're torn between hand-crafting and bot-coding. After all, this is a question of keeping control versus handing over, and probably losing, control to a machine. Will the clanker end software development as we know it? I think it's not a total turnaround. If we consider LLMs as a tool, we can decide where to put it to good use and where to better leave it outside.

One way to keep control is to know your tools better. The two featured articles are a great start. One is about the Go toolchain, the other about a standard library feature that may observe data races if not used properly. Both help understanding the nature of Go better, not only for writing better code but also for doing better reviews of others' code (including bot-generated) and designing better Go apps.

Freedom of choice grows best on a substrate of knowledge.

–Christoph

Featured articles

Hooking into the Go Toolchain

"Photobombing the compiler"—Can't describe it better.

The Data Race That Wasn't a Bug (and the One That Was)

Jesús Espino examines a data race in Go’s HTTP client when reusing request buffers: The transport sends the body in a background goroutine and may return before finishing, causing races if you overwrite the buffer immediately.

TL;DR: Developers should avoid sharing stateful readers or mutating memory after calling client.Do.

Podcast corner

🌁 Cup o' Go LIVE in SF with Bill Kennedy! Hosted by Antithesis

The hat is similar, but the person under it isn't Jonathan... it's Bill Kennedy! Recorded live in SF, Bill and Shay talk about upcoming conferences, Go toolchain internals, and a pure-Go implementation of llama.cpp that intends to bring LLMs to small places (like a Raspberry Pi).

Spotlight: Ai Is Like Dynamite

In 1866, Swedish chemist Alfred Nobel invented dynamite, the first safely manageable explosive, but at the same time stronger than traditional explosives. While Nobel (probably) intended dynamite for use by civil industries, it became a deadly weapon for military, criminals, and terrorists. This is the fate of many tools: They can be used for good and bad.

Generative AI

AI isn't all sunshine and roses. The history of today's LLMs is a list of massive unethical and environment-hostile acts, including exploiting legions of click workers, ignoring intellectual property, and running data centers on gas-powered electricity generators lowering air quality in nearby cities. I won't defend this behavior; I condemn it as much as anyone else whose moral compass isn't entirely broken.

However, I don't think that AI as such is to blame. If the LLM breakthrough did not happen, the industry would have found another cash cow to milk and would still have given a dang on workers' rights, public health, and climate change.

But the current industry toy is AI, and unfortunately, AI happens to be an increasing threat for those not using it. Current models write code orders of magnitude faster than humans, and they become increasingly good at writing robust-enough code, too. What is happening today has been impossible pre-AI: A startup creates a suite of apps rivaling Adobe's app portfolio. The Linux kernel got nearly 2,000 vulnerabilities fixed in one single release. Everyone (including me) vibe-codes little tools and helpers with a few minutes of prompting.

My take on the future of development is this: Hand-crafted code will become too expensive to be an alternative to AI-generated one. Developers must shift towards tasks that AI cannot take over (that is, tasks that need judgement and, I'm not joking, taste). These tasks range from code reviews to designing the architecture and making sure the implementation is not only techincally correct but meets the intent of the designers.

Like hand-knitting, typing code by hand will become a mere hobby without an income. Of course, this only applies to code that LLMs know to produce from their huge memories. But this is perhaps 99% of all code. Specialized code in niche areas continues to require hand-crafting. (Until someone trains a model in that niche.)

The AI shift will come, whether we like it or not. I have decided to put my focus on answering this question: How can Go developers stay afloat if AI takes over all coding? I don't believe that hand-crafting code remains valuable for businesses. When money is involved, financial departments value ugly code that works over beautiful, hand-crafted code that takes significantly more time and money to write and isn't necessarily more bug-free. This future is anything but great for developers but I believe it's inevitable. LLMs are here and cannot be undone. We have to deal with this future, or we have to turn our professional energy towards jobs that AI can't eat.

Many believe that the whole LLM thing is just a bubble that will eventually burst. So far, LLMs only got better at their tasks, at a frightening pace. They deliver real, measurable acceleration of the software process. A bubble builds where exaggerated expectaions exist, and surely there are some greatly exaggerated expectations about where LLMs can improve productivity. However, in the realm of coding, LLMs already demonstrated that they're capable of insanely accelerating the development process. This is not a bubble.

The bubble is going to pop elsewhere: at companies that think they can replace human interaction with machines; in the hardware sector, when LLMs become more efficient and extended hardware manufacturing capabilities aren't necessary anmore; at AI companies who accumulate debt to pay for the race to becoming the #1 monopolist; or at AI gold rush startups whose products are nothing but thin wrappers around a standard LLM.

Pop.

In defense of the AI sector, there are AI data centers that take sustainability goals seriously[^1]. Research projects have proven that it is entirely possible to train an LLM without infringing intellectual property. The AI world isn't entirely black or white, and these examples are but a small drop in the bucket, but they have set a precedent that I'm pretty sure others will follow because it's the right thing to do.

Other challenges of LLM use are much harder to tackle, and by "much harder", I mean that I can see no feasible solution on the horizon. These challenges include what you mention in your bullet points 3 and 4: Decreasing skills in software development and the increasing difficulty to become a junior developer, let alone work one's way towards senior-level expertise. When LLMs can do what junior devs can do, but much cheaper, who will still pay people on their journey from junior to senior?

What we can do is trying hard to become a centaur (where the human is the head and the AI the powerful body) rather than a reverse centaur (where the human has nothing to decide but must carry all the consequences). This isn't "resitance is futile" but rather "resistance means keeping control over our decision to use AI when it makes sense."

I'm trying hard to dig up ways to make Go developers thrive amidst of the challenges imposed by AI. There are many aspects of AI to remain absolutely critical about (and raise once's voice). But AI as a technology will stay, and we have to make the best of it.

[^1]: The company linked to is a EU-based company that runs open-weight models within the EU (and that means, goverened by consumer-friendly, privacy-respecting EU law). I want to see more such companies in Europe, where I live, and in other parts of the world. Markets flourish by competition and freedom of choice.

Quote of the Week:

Tech companies trying to replace people with AI, only for people to start replacing tech companies with AI has gotta be the funniest plot twist of the century

– wono, reacting to the release of ArtCraft, an open source, AI-assisted alternative to Adobe's software stack

More articles, videos, talks

Hacking the Go compiler to efficiently map IPv4 to IPv6

Go lacks a To6() method for netip.Addr and the recommended workaround is inefficient. Not because of a bad implementation but compiler limitations. So the natural move is to hack the compiler, at leat for Vincent Bernat.

Dancing backwards with Go: why TDD is weird

To write good tests, you have to start from the desired result and work your way backwards to a working function. By John Arundel

connect-go v2 is here · Buf Blog

The protobuf library Connect got a major version bump. One aspect caught my attention:

Killed our overly complicated use of generics

Generics can be helpful, unless they aren't.

Adding Go's defer to the TypeScript Compiler

Could TypeScript achieve simpler resource cleanup patterns by "implanting" Go's defer statement into the TypeScript compiler? Andrew Healey volunteered to find out.

Projects

Libraries

PlantControl/controlsys: Go library for linear state-space control systems

A Go library for linear time-invariant control systems.

A rule of thumb for me is: If I can't grok the buzzwords in a Go project description, it's probably not for me. For anyone else who's curious about linear state-space thingies, here is some brain food for a start.

Francis

A database is all you need: If frameworks for durable workflows are too heavyweight for your needs, try Francis. If required, it can shrink its footprint down to a library and a SQLite database file.

Tools and applications

nanolathe-gg/nanolathe: Total Annihilation engine reimplementation in Go.

Total annihilation? Oh, it's just a dramatic name of a game engine. The point of this re-implementation in Go is to bring back the 1997 game of the same name.

Golang tool to check SPF, DKIM, TLSA, and TLS settings for mailservers

Not so interesting code-wise because vibe coded, but maybe a helpful tool for a Go-centric network toolbelt.

Berk-Unsal/atom: High efficiency RF planning module written in Go.

We all dream of building a cellular network in our free time, don't we?

Completely unrelated to Go

How to read code

You can't read code as if it was a novel. It's designed for execution and often read as diffs. While this can become a drag, leaving code reviews to LLMs isn't a sustainable solution: LLMs can assist, but due to their lack of alignment and standards, they can't replace human reviews entirely, says Sean Goedecke, and suggests to read code with a technique called dyadic scanning.

When code is cheap, judgement becomes the job

How to maintain code quality when LLMs write (almost) all code? Swizec Teller shares some learnings from two years of AI-accelerated software development.

Software's centaur age may last decades

AI will eat all developers' jobs!

No, it doesn't, says Sean Goedecke. At least as long as humans teaming up with AI continue to have an advantage over both pure AI and pure human work. Human-AI-hybrids are like a centaur, the mythic creature that is half horse, half human, and thus has both human intelligence and the power of a horse's body. (See also: reverse centaur. Apologies to long-time readers; I think I shared this link with you already once or twice.)