I recently got my copy of the Internet Phone Book. Look who’s hiding on the bottom inside spread of page 32: The book is divided into a number of categories — such as “Small”, “Text”, and “Ecology” — and I am beyond flattered to be listed under the category “HTML”! You can dial my site at number 223. As the authors note, the sites of the internet represented in this book are not described by adjectives like “attention”, “competition”, and “promotion”. Instead they’re better suited by adjectives like “home”, “love”, and “glow”. These sites don’t look to impose their will on you, soliciting that you share, like, and subscribe. They look to spark curiosity, mystery, and wonder, letting you decide for yourself how to respond to the feelings of this experience. But why make a printed book listing sites on the internet? That’s crazy, right? Here’s the book’s co-author Kristoffer Tjalve in the introduction: With the Internet Phone Book, we bring the web, the medium we love dearly, and call it into a thousand-year old tradition [of print] I love that! I think the juxtaposition of websites in a printed phone book is exactly the kind of thing that makes you pause and reconsider the medium of the web in a new light. Isn’t that exactly what art is for? Kristoffer continues: Elliot and I began working on diagram.website, a map with hundreds of links to the internet beyond platform walls. We envisioned this map like a night sky in a nature reserve—removed from the light pollution of cities—inviting a sense of awe for the vastness of the universe, or in our case, the internet. We wanted people to know that the poetic internet already existed, waiting for them…The result of that conversation is what you now hold in your hands. The web is a web because of its seemingly infinite number of interconnected sites, not because of it’s half-dozen social platforms. It’s called the web, not the mall. There’s an entire night sky out there to discover! Email · Mastodon · Bluesky

The use of std::string should be banned in C++ code bases. I’m sure this statement sounds like heresy and you want to burn me at stake. But is it really controversial? Java, C#, Go, JavaScript, Python, Ruby, PHP: they all have immutable strings that are basically 2 machine words: a pointer to string data and size of the string. If they have an equivalent of std:string it’s something like StringBuilder. C++ should also use immutable strings in 97% of situations. The problem is gravity: the existing code, the culture. They all pull you strongly towards std::string and going against the current is the hardest thing there is. There isn’t a standard type for that. You can use newish std::span<char*> but there really should be std::str (or some such). I did that in SumatraPDF where I mostly pass char* but I don’t expect many other C++ code bases to switch away from std::string.

Over the course of my career, I introduced a couple of engineers into the topic of query engines. Every time, I bumped into the same problem: query engines are extremely academic. Despite the fact that industry has over 40 years of expertise, reading foundational papers and then sort of just googling around is the only way to dive deep. Database courses and seminars from Andy Pavlo definitely help, but they are still targeted at academic audience and require a lot of extra reading to be useful.

Comparing gzip, brotli and zstd compression in Go. When a modern browser sends a HTTP request to a web server, it includes the following header: Accept-Encoding: gzip, deflate, br, zstd This tells the server that the response can be compressed using one of the following compression algorithms: gzip and deflate (oldest, very similar), brotli and zstandard. If your server is written in Go, which algorithm should you use? I wondered that myself so I decided to test it. I measured compression time and the size of a compressed data. In benchmarking it’s important to pick a representative sample. I’m currently working on Edna - a scratchpad and note-taker for developers and power users, like myself (this very article was written in Edna). It’s an SPA written in Svelte. After bundling and optimizing I get ~640 kB index.js which is a good test case for a real-life, production, optimized JavaScript. Here are results of compression test: found index-YpZ0JZes.js of size 639861 (640 kB) compressing with gzip compressing with brotli: default (level 6) compressing with brotli: best (level 11) compressing with zstd level: better (3) compressing with zstd level: best (4) gzip: 200746 (201 kB) in 12 ms brotli default: 206298 (206 kB) in 18 ms brotli best: 183887 (184 kB) in 977 ms zstd better: 106458 (106 kB) in 3 ms zstd best: 93966 (94 kB) in 14 ms the winner is: zstd level 3 zstd level 3 is a clear winner: it achieves much better compression ratio than gzip/brotli and much faster speeds. If you want the absolute smallest files, zstd level 4 has a slight edge over level 3 but at a cost of much higher compression times. the code We use the following Go libraries: github.com/andybalholm/brotli for brotli github.com/klauspost/compress for gzip and zstd The code of benchmark function: func benchFileCompress(path string) {   d, err := os.ReadFile(path)   panicIfErr(err)   var results []benchResult   gzipCompress := func(d []byte) []byte {     var buf bytes.Buffer     w, err := gzip.NewWriterLevel(&buf, gzip.BestCompression)     panicIfErr(err)     _, err = w.Write(d)     panicIfErr(err)     err = w.Close()     panicIfErr(err)     return buf.Bytes()   }     zstdCompress := func(d []byte, level zstd.EncoderLevel) []byte {     var buf bytes.Buffer     w, err := zstd.NewWriter(&buf, zstd.WithEncoderLevel(level), zstd.WithEncoderConcurrency(1))     panicIfErr(err)     _, err = w.Write(d)     panicIfErr(err)     err = w.Close()     panicIfErr(err)     return buf.Bytes()   }   brCompress := func(d []byte, level int) []byte {     var dst bytes.Buffer     w := brotli.NewWriterLevel(&dst, level)     _, err := w.Write(d)     panicIfErr(err)     err = w.Close()     panicIfErr(err)     return dst.Bytes()   }   var cd []byte   logf("compressing with gzip\n")   t := time.Now()   cd = gzipCompress(d)   push(&results, benchResult{"gzip", cd, time.Since(t)}) logf("compressing with brotli: default (level 6)\n")   t = time.Now()   cd = brCompress(d, brotli.DefaultCompression)   push(&results, benchResult{"brotli default", cd, time.Since(t)})   logf("compressing with brotli: best (level 11)\n")   t = time.Now()   cd = brCompress(d, brotli.BestCompression)   push(&results, benchResult{"brotli best", cd, time.Since(t)})   logf("compressing with zstd level: better (3)\n")   t = time.Now()   cd = zstdCompress(d, zstd.SpeedBetterCompression)   push(&results, benchResult{"zstd better", cd, time.Since(t)})   logf("compressing with zstd level: best (4)\n")   t = time.Now()   cd = zstdCompress(d, zstd.SpeedBestCompression)   push(&results, benchResult{"zstd best", cd, time.Since(t)})   for _, r := range results {     logf("%14s: %6d (%s) in %s\n", r.name, len(r.data), humanSize(len(r.data)), r.dur)   } }

This article was originally commissioned by Luca Rossi (paywalled) for refactoring.fm, on February 11th, 2025. Luca edited a version of it that emphasized the importance of building “10x engineering teams” . It was later picked up by IEEE Spectrum (!!!), who scrapped most of the teams content and published a different, shorter piece on March […]