My Blog

Cloudflare Pages

Tue, 25 Aug 2026 19:46:08 GMT

This is the first blog entry after migrating from GH pages to Cloudflare Pages. Hopefully this page gets displayed without additional intervention from me.

Learning Go

Tue, 25 Aug 2026 15:01:19 GMT

After years of writing Node.js professionally, I spent a few weeks building small tools in Go. This post is a running list of things that surprised me, annoyed me, and eventually won me over.

Goroutines

Goroutines are Go’s unit of concurrency. They are cheap enough that spawning thousands of them is unremarkable, and the runtime multiplexes them onto a small pool of OS threads.

The mental model is close to async/await, except there is no colored function problem: any function can block without holding up a thread.

Channels are typed pipes through which goroutines communicate. Do not communicate by sharing memory; share memory by communicating.

Error handling

Errors are values. There are no exceptions to catch — functions return an error and you deal with it immediately:

func fetch(url string) ([]byte, error) {
 resp, err := http.Get(url)
 if err != nil {
  return nil, fmt.Errorf("fetch %s: %w", url, err)
 }
 defer resp.Body.Close()

 body, err := io.ReadAll(resp.Body)
 if err != nil {
  return nil, fmt.Errorf("read %s: %w", url, err)
 }
 return body, nil
}

Verbose? Sometimes. Explicit? Always.

What I like so far

Single static binaries — go build and copy the file.
The standard library covers most of what I used to reach for packages to get.
go test ./... needs no configuration.

And a short list of things I miss from JavaScript:

The npm ecosystem
Destructuring everywhere
Array.prototype.map

Comparing defaults

Concern	Node.js	Go
Concurrency	Event loop	Goroutines
Typing	TypeScript (opt-in)	Static (built-in)
Deployment	`node_modules`	Static binary

Overall: still early, but the language spec is surprisingly readable.

React Server Components, One Month Later

Sun, 12 Jul 2026 12:00:00 GMT

We shipped our first production feature using React Server Components last month. These are my notes on what actually changed, for better and worse, once real users hit it.

The model

In RSC, components run on the server by default. Client components are the exception, marked with the "use client" directive:

async function ProductPage({ id }: { id: string }) {
 const product = await db.products.find(id);

 return (
  <>
   <h1>{product.name}</h1>
   <AddToCartButton productId={product.id} />
  </>
 );
}

The data fetching happens on the server; only the interactive island ships to the browser.

What worked

No client-side waterfalls — queries start on the server.
Bundle size dropped noticeably once data-fetching code stopped shipping to clients.
Composing server-rendered content with small interactive pieces felt natural.

What hurt

Debugging serialization errors across the server/client boundary is unpleasant.
Every state library needed rethinking.
The mental model shift was bigger than the docs suggest:

It’s not “React but faster”. It’s a different split of responsibilities between server and browser.

Verdict

Promising, but treat the migration as an architecture change rather than an upgrade. For this blog, incidentally, plain static HTML remains entirely sufficient — which is exactly why this site is just Markdown files.