Language Is (Ir)relevant

Hi ,

How time flies! It's two weeks since I asked you to help me shape the Go eBook I plan to offer while my courses are frozen due to legal concerns. Thank you to all who participated! I read all of your answers, and I got some really useful insights.

Stats first:

Format: Of those who answered the question, most prefer PDF, followed by ePub, then HTML (online). One participant disclosed that they prefer Markdown, to generate audiobooks and Anki cards. There are so many different ways of learning!

Example code: Most who answered this one want downloadable code, followed by "both downloadable and running in the browser." The code is already downloadable; making it run in the browser is a challenge that I accept with pleasure.

To manage expectations: In the staged rollout that I'm planning, advanced features like this might appear in later stages.

Structure: The answers were clear: The book shall be restructured for a reading audience (rather than following the course's linear structure). I shouldn't have asked this question lightly! I might have greatly underestimated the effort for imposing a new structure over the existing content. But I'm sure I'll find a good way to make the book a great reading experience.

The most annoying aspect about eBooks (that I should avoid): I got so many insightful answers! I cannot comment on every single one here, but let me summarize a few:

• Code shall be well formatted, syntax-highlighted, and runnable without contorted maneuvers (such as copy-pasting multiple fragments and cleaning it up from uncommented annotations). And it should work as described.
• Cover real world topics and applications. I have to mark this one for closer consideration, as my assumption (back when I created the course) was that embedding code examples in real-world contexts might add noise that can distract from the core idea to get across. But I get that examples that float in thin air without relatable context might not necessarily be easier to understand than examples with contextual "noise" around them.
• Avoid walls of text (which is indeed something I see in too many technical books).

Plus many more comments and tips. Again, thank you for taking the time to answer my questions. I'll work out a suitable concept that meets these wishes and suggestions in the best possible way.

–Christoph

Featured articles

Security: Go 1.26.2 is released (and Go 1.25.9, too)

This release contains quite a few security fixes—is this something to worry about? Maybe it's a good sign: LLMs become increasingly capable at spotting security issues in code.

Nevertheless, keep calm and update quickly.

When the compiler lies: breaking memory safety in safe Go

Related to the recent Go minor release: Jakub Ciolek, cloud security engineer, describes how he discovered two of the CVE's fixed in Go 1.26.2.

Podcast corner

080: Ship it anyway: fighting the urge to refactor

The "one more improvement before shipping" virus and what you can do about it.

Go 1.26.2 is a beast. Go upgrade!

Jonathan Hall and Pato Whittingslow (filling in for Shay) discuss the many security fixes in Go 1.26.2 and the use of Go on an ESP32 microcontroller. (Note to self: Looks like Wifi support for TinyGo on the ESP32 has finally arrived!)

Spotlight: The Best Language for AI-Assisted Coding Is...

If you ever had an LLM generate code for the same problem in different languages, you might have wondered whether some languages are more suitable than others for being read and generated by LLMs. Maybe you even observed a notable difference in quality between the different outputs.

Could there be a specific aspect of a programming language that helps LLMs to better understand code they're reading, or generate better code?

In other words, will we witness an "agentic coding singularity" in which all coding agents use a single, synthetic "hyper language" that pushes all other languages into oblivion (or into the shelter of human developers who still love to craft code by hand, discuss languages and programming techniques, and be familiar with a codebase)?

Will all programming languages become obsolete?

Or does the choice of a programming language become increasingly irrelevant, because LLMs can emit code in almost any language you ask them to? Like, "Write Space Invaders in SQLite!"

On measurability

When asking about differences in quality, we need to define "quality" and determine measurable aspects of this definition. A few aspects come to mind:

Functional correctness

Does the code do what the spec requires? (Yes, writing a spec is a good idea.) Are the tests meaningful and do they pass?

The rate and nature of errors and bugs

How many errors does the code produce when running? How many bugs are hidden in the code that may cause wrong behavior, break data, or open security holes?

Clarity

Is the code clear and readable to a human reviewer (and to an LLM that has to maintain the code)?

Token efficiency

How many tokens does the LLM burn through when reading a certain amount of code? That's not just a question of cost; rather, if code translates efficiently into tokens, more code fits into the LLMs context window, allowing it to analyze larger codebases and better understand the bigger picture.

Studies have been done, but...

There are plenty of studies and benchmarks that evaluate how LLMs perform at coding tasks in various languages. Don't expect that a clear winner has emerged from all this research activity; there is none. Moreover, I wasn't able to find a study that evaluates the latest frontier models. There's a broad consent among LLM users that these models enter new levels of coding quality. But even without, some language characteristics seem to increase a language's suitability for LLM coding.

For example, static typing is a clear advantage for coding agents, as they get helpful feedback at compile time already and don't have to run tests to uncover type-related bugs.

A bachelor thesis found some indication that LLMs work better with languages that have low levels of abstraction, a clear syntax, and straigthforward semantics.[^1]

The one thing more important than language characteristics

This doesn't help much with answering the initial question, though. There is still a wide range of statically typed languages that aren't too abstract and convoluted. But there is one more aspect that turns out to be important, and it's not related to language characteristics.

Consider that LLMs don't "understand" programming. They cannot draw logical conclusions. All they do is calculate the most probable answer to a given input, based on their huge knowlege base encoded in the nodes of their neural networks. A fact that quite naturally leads to the following conclusion:

An LLM gets good at writing code in a given langauge when it is exposed to large bodies of code of that language (and hopefully, that's mostly code of good quality). So the more popular a language is, the more code is publicly available, and the better an LLM can generate working code in that language.

What this means for Go

It's one and a half decade since Go 1.0 was released in 2011, and this means a lot of Go code is already out there, ready for LLMs to learn form. But so is code written in languages like C, C++, Java, C#, Python, JavaScript, and Rust.

For me, Go is still a winner in the discipline "most suitable LLM language". It has quite a number of [wonderful advantages](< ref "why-go" >), and some of them are a match in heaven for LLM coding:

A fast compiler

Go's insanely fast compile time is a game changer for agentic workflows that test code repeatedly until the LLM is satisfied with the result. While compile times of other languages pile up to hour-long sessions, similar edit-compile-test loops in Go complete in minutes.

A rich, battle-tested toolchain

The benefit of tool execution increases with the capability of each tool. Go's toolchain is mature, battle-tested, and covers many tasks that other language ecosystems would have to pass on to third-party tools.

Long-term stability

Go has proven to be exceptionally stable over the years. Code written in Go 1.0 still compiles with Go 1.26 with very few exceptions (usually caused by security fixes that sometimes cannot avoid breaking things). LLMs love language stability.

And so much more

There are so many more great features of Go that make Go a superb choice for both humans and LLMs. As long as agentic coding workflows require a human in the loop, the choice of language remains important.

As a software developer, you are responsible for the code you ship, whether you craft it by hand or let an LLM do the task. So until (and if ever) we reach the Final Tipping Point after which humans don't need to look at generated code anymore, you'd better choose a language that is easy to read and easy to review, and generally pleasant to work with.

[^1]: Evaluation of the Code Generation Capabilities of ChatGPT 4 A Comparative Analysis in 19 Programming Languages

Quote of the Week:

The loudest voice in the room is the one in your head

– [Siddhant Khare, Why you stop caring mid-review]()

More articles, videos, talks

ByteLearn — Free Developer Courses

Learn Go by writing a concurrent file scanner in 11 lessons.

The System Monitor | Internals for Interns

Meet the Go scheduler's best friend: sysmon. Living at the edge of infinity (as in: infinite loop), sysmon ensures the scheduler never gets stuck.

Stacked log lines considered harmful | Redowan's Reflections

When your app starts emitting a cacophony of log messages, it's time to rethink the logging strategy. If each layer in a call chain logs their version of the same error, collect the info instead and assemble a single log messager with a better signal-to-noise ratio at the top.

Calling a Rust library from Go with CGO_ENABLED=0 | Stoolap

CGO is Go's standard way of talking to code in other langauges via the C ABI (application binary interface). CGO has some quite unfortunate disadvantages, however. Enough for Semih Alev to search for CGO-free ways to call a database library written in Rust. The way he found (or rather, developed) is not straightforward, but for projects with similar requirements and calling patterns might benefit from his approach.

watgo - a WebAssembly Toolkit for Go

An interesting new kid on the WASM block: watgo parses, validates, and encodes WebAssembly Text, a textual representation of WASM bytecode, into WASM binary format.

Building slogbox

Alex Rios married FlightRecorder's ring buffer with slog, to get a "last-N-logs" in-memory store.

Go Bitwise Flags and Bitmasks: Configuration Pattern Guide • Asaduzzaman Pavel

Bit(wise) flags have a long tradition: In the Unix call open(), they allow enabling desired features like so: O_RDONLY | O_CREAT | O_TRUC. Go's standard library also has bitwise flags. Asaduzzaman Pavel explains what they are and how to use them for your configuration needs.

Projects

Libraries

How I made --dangerously-skip-permissions safe in Claude Code

The optimal habitat of an AI agent is a sandbox. And in April 2026, there are plenty to choose from: Docker sandbox, bubblewrap, microsandbox,...

This one, Hazmat, sticks out: A crucial part of it (setup and rollback ordering) is formally verified with TLA+. (But alas, it's for macOS only. No way to use it on a Linux server.)

Tools and applications

antst/go-apispec: Generate OpenAPI 3.1 specs from Go source code via static analysis — zero annotations, automatic framework detection · GitHub

Another code-first approach to the problem of avoiding double work—for writing an API spec and the corresponding code. Analyzing the AST to eliminate the need for annotations is an interesting approach with a small but important restriction: Anything that happens at runtime, such as dynamic routing or status code calculation, is invisible to static AST traversal.

safedep/pmg: PMG protects developers, AI agents from malicious open source packages using proxy, sandbox and SafeDep's threat intelligence feed. · GitHub

If you're a Gopher, then PMG wasn't made for you. Sorry!

But it's written in Go, at least. And a wonderful case of how Go can help other languages' ecosystems.

Oh, wait, the tool actually works with Go as well, if you distribute your Go binaries via uv.

Completely unrelated to Go

Stamp It! All Programs Must Report Their Version

Version numbers aren't just some pretty decoration or a means for bragging about progress made. Michael Stapelberg could have saved hours if the software he was fixing had proper versioning.

TIL: Dishwashers teach us a lot about versioning.

It's all relative

Even principles are relative.

Tracing what agents do, not what they say

Siddhant Khare worries about the lack of observability in the lower layers of agentic coding systems.

I worry about the huge amount of code AI generates for some companies on a daily basis.

Dynamo: Amazon's highly available key-value store

Findings from reading the Dynamo paper that could drive your architectural decisions for your next distributed Go app... maybe?