Depth

Hi ,

Put some performance in a bowl, mix it with function colors, generously sprinkle some memory management over it, et voilà: Brain food for one evening. Or morning. Or whenever you read this issue. I don't mind, I'm happy as long as one or more of the articles or repos make you want to hack away some Go code.

Then I can say: mission accomplished.

–Christoph

Featured articles

Sloc Cloc and Code - Did I just get Buster Scrugged?

Where do you get your motivation for improving your apps from? Ben E. C. Boyter got his motivation from a github issue claiming superior performance for another tool in the same category as Ben's. Challenge accepted.

Why Function Arguments Are Not Function Colors

context.Context function arguments drip down the call chain like wet paint on a wall. Should we call context-carrying functions colored then? Well, the idea of function colors stems from async programming, where asynchronous functions (that require a callback function) are red and synchronous functions (that have "proper" return values) are blue.

Does the blue/red allegory apply to context/non-context functions too? An attempt by Jeremy "Jerf" Bowers.

Swap, memory pressure and the Go GC · Fernando Simões

Garbage collection is a convenience service, at least in IT. (IRL, I would consider GC services a necessity.) But every convenience comes at a cost. Garbage collection costs a few CPU cycles, so the natural question for high-performance apps is, how does the GC behave under load? What happens if the Go GC gets in conflict with the OS kernel's desire to swap out unused memory pages when memory is full? Fernando Simões inspected a near-production setup under severe (memory) pressure.

Podcast corner

A big episode about tiny things

Now THAT's a shopping list of topics on this episode! No wonder it's 1:20 long. And the "things" discussed aren't so tiny, after all...

Spotlight: There Is So Much Left if You Have the Depth

On Friday, Simon Willison commented a blog article titled "I'm sad about AI". Simon acknowledges that many software developers have felt the existential crisis caused by LLMs writing code of decent quality in much less time. But many managed to escape this crisis. As Simon observed:

Once you come to terms with the idea that translating an exact specification into decent code isn't a unique skill any more, you can start looking at the larger set of problems that you face as a software engineer and realize that there is so much left, and your existing skill and experience mean you can master these new tools, provide value, and execute at a level far greater than anyone who is just getting started building software using agents without any of your depth.

(Source)

This comment has two parts that both resonate with me. First, "there is so much left." This is so true, and it reminds me on a [quote] from Albert A. Michelson (sometimes wrongly contributed to William Thompson):

There is nothing new to be discovered in physics now. All that remains is more and more precise measurement.

(The actual quote is a bit longer.)

As Michelson, many developers today believe that LLMs are slowly taking over software development. With every release, they get better, until there's nothing left to do for human developers.

I don't see this happen anytime soon.

While LLMs seem to get better and better at coding at an insane speed, the way they're constructed prevents them from ever understanding what they're doing. In the 1980s, John Searle argued that computer programs can never achieve consciousness. He constructed the following thought experiment:

Imagine a program that is able to take Chinese characters as input and provide a meaningful output to that input, again in Chinese characters. (The program apparently was written by an English person in an English programming language, or else the story had no point.) We would not know if the program behaves intentionally, or even consciously.

Now change the scenario: John Searle sits in a room at a computer running this program. Someone slips in sheets of paper with Chinese characters under the door, and Searle, without knowing what these characters mean, passes them to the program, which returns other Chinese characters. Searle writes them on a paper and slips them back out under the door. At no point does Searle get an idea of what these characters mean. He is just following a recurring set of manual steps.

Now Searle argues that if he is not able to understand the conversation, the program, which essentially also just executes steps mechanically, isn't able to understand it, either.

And this brings me back to Simon Willison's conclusion that there'll be still so much left. An LLM can mechanically write a program based on a description given to it, but, as the bit matrix calculator it is, it cannot understand the intention behind a decision a developer makes; after all, an LLM is merely trained to generate the most probable answer from a huge set of data it was trained on. So there is, and will be, plenty of work for humans to do in the endeavor to bring an idea to a finished program. This work will just be at a different level as we're used to today.

The second part of Simon's comment is even more important, and true: Depth of knowledge and skills is what sets experienced developers apart from the non-programmers who vibe-codes apps without ever looking at the code because they cannot make any sense of it. When your knowledge of programming languages and concepts is deep, your programming skills are battle-tested, and your mind is open and curious, you're in the best position to steer an LLM to generate the code you need without having to blindly accept its outputs.

If you know the fundamentals of software development and learned and mastered at least one programming language (and Go would be an excellent choice), LLMs turn from an (perceived) existential threat to nothing but new, interesting tools under your toolbelt.

Quote of the Week: What We Fear

What we fear says a lot more about ourselves than about the future.

– Heebie-Geebie

More articles, videos, talks

Designing Cadenya's API - Cadenya

If you design an API, it must be good. Once published, you won't have the chance to modify the API often. But an API is not just a list of endpoints to call. Its design decisions touch many other parts, from client to the database. This article explores the API design of Cadenya (an agent runtime) that includes Protobuf envelopes, Ent schemas, cursor pagination, and Envoy gRPC-JSON transcoding. (Whoa, that's quite a mouthful of techniques.)

Signing TLS handshakes inside a TPM

How do you determine if the remote end of a connection is in an expected status of operation? That's what remote attestation is about. One part of remote attestation is the ability of the remote machine to maintain an identity it can reliably show to other machines. Which requires a trusted connection. How to build one? Mutual TLS. Sounds like a solved problem, right? But it's still more than importing a lib and calling a func. (Yes, the article is long.)

Sum types in Go, or how to model events the compiler can check | Valentin Vivier

Event sourcing wants sum types! While Go does not have them, they can be modeled with the sealed interface pattern, without becoming overly un-idiomatic.

Go 1.27 Explained by the Go Team | Release Party - YouTube

The recording of JetBrain's Go 1.27 release party is online.

I contributed to Golang, here is how you can too

So you found a bug, a glitch, an aspect to improve in the Go toolchain, and you're eager to contribute your findings (and maybe even a solution) to the Go project? That's great, but there are a couple of steps between you and a successful contribution—both technical and organizational. Fortunately, Alex Pliutau went through the process and describes the steps you need to take (and how).

kavak studio runs Go code

Kavak, an in-browser IDE, can run the Go compiler in the browser via WebAssembly. According to the author, while some features still wait to be implemented, a "significant portion of the language" already works.

Rune is now open source. Rune Blog

There aren't many IDEs specifically tailored for Go. Now there's one more: After working for nine years on Rune "in the dark", the author released it to the open source community. And it's definitely not your usual IDE. It feels more like a terminal multiplexer, centered around a command prompt rather than UI elements. (macOS & Linux only)

Projects

Tools and applications

MichaelMure/benchspotter: A developper assistant for go benchmarking and performance

What do you do with all the results from benchmarking, profiling, escape analysis, other analyses...? benchspotter runs various performance tools and saves their results so the developer only needs to examine them. Super-lazy devs pass even this step to an LLM; benchspotter is prepared for this scenario.

Giammarco-Ferranti/deja: Predictive inline shell autosuggestions for zsh. Go daemon, no TUI, no sync

Predictive inline shell autosuggestions for zsh. A reddit comment: "Peak programmer behavior: spend 20 hours building a daemon just to save 2 seconds in the shell. Love it." Author's reply: "Those two seconds add up." Me thinking: "When is the break-even?"

Zasper: High Performance IDE for Jupyter Notebooks

If Jupyter Server is too slow and bulky for you, try Zasper: up to 5× less CPU and 40× less RAM than Jupyter Server, in a single 8 MB binary.

markel1974/gowolfenstein: a go wolfenstein rich clone

A 3D first-person shooter from the 90's (one of the, if not the, first of this kind), a Go reimplementation from 12 years ago, and a switch to open source now. Play Castle Wolfenstein 3D written in Go!

KeibiSoft/KeibiDrop

KeibiDrop is Airdrop for the rest of us, and its development advances in big steps. Not only can it fuse-mount a whole folder (rather than just send files back and forth), a mount now also survives restarts, long idle times, and other interruptions. And all data in transit enjoys end-to-end post-quantum encryption.