I know, I know: It's complicated. But have you heard of AI agents?

But I just onboarded 4 interns on a project where all they had to do was

  1. Install the Nix package manager
  2. Install direnv, enter the project repo, and `direnv allow`
  3. Toolchain, git hooks, MCP servers, in-repo issue tracker, everything is available

Putting wrong information is README is so outdated when you have programmatic setup of your entire toolchain.

So picking languages for their compilation and especially runtime properties is key.

What I've learned, though, is that languages with reckless error handling produce more errors at runtime. My Rust programs just don't crash because I don't need it to be explicit about reaching a "total" approach.

If you're in a C# environment, I see a case for F#. And if you want fast but more solid than Python, why not Mojo? Although who reads code.

This article convinces me. But I suspect like my lack of domain knowledge of Lisp makes me spend time learning the runtime: how and when can I switch to JIT, what's the async story, how does the harness become part of the Lisp program, etc.

You did... what? You mean you asked AI?

It would, of course, be easy to say "But that's not the fault of monorepos! Clearly, 50GB is a nonsensical amount of source code, and clearly someone committed something they shouldn't have in the past."

But also, with monorepos, the probability of that happening to the repo you use the most is the cumulative sum of all of its projects, since more people's potential git mistakes now happen in the same place.

For the sake of comparison, nixpkgs is 4.5GB right now. It hosts ~140.000 packages, ~12.000 open PRs, one million commits, yadda. So when you reach ten times that size with, presumably, less traffic, I would consider cleaning up the history.

Polyrepos can definitely work; I use them extensively in open-source. I also wouldn't be doing that without Nix flakes all over to chain them together. And even then, I have constant drift because one repo is pinning an old version of another repo, and once I bump the pin, things break lazily.

The biggest benefit, by far, you get from monorepos, is eager evaluation of your dependencies.

I get that there’s cognitive debt. Some just seem to never even pay interest or get a basic understanding of the domain model.

My suspicion is that these people were always lazy programmers, but now they can take the laziness to a point where, after weeks of working on a project, they don’t get the basic vocabulary right.

I just want to say: #notallvibecoders

By the time you’re “at scale” (who knows), and all these monorepo at scale problems start to overwhelm, you can switch strategy, because the economy of polyrepos is so obvious by then.

So far, I’ve started a new job a handful of times by collapsing a premature polyrepo strategy: people were not experienced enough to merge two git repos without a common root.

I’ve only once went the other way, and it incurred so much overhead, it decreased developer productivity by some small but not insignificant percentage.

To be clear: I’m not a maximalist. All of my open-source work is exceedingly compartmentalised. My DNS library is separate from my external-dns webhook is separate from my fork of external-dns. They could all live in one repo. But FOSS encourages reusability, commercial software encourages clumping and vendoring.

Sounds like unbounded, dynamic allocation to me!

Here's an AI-generated pull request I made, but you wouldn't know because there's no slop:

https://github.com/numtide/devshell/commit/a67c0f87b63bcbdbd...

It got merged by someone who is too busy to respond to personal emails.

"Don't waste my precious attention" is only getting more real.

Points of no return.

I run NixOS, work with Kubernetes, code Rust, use a 40% split, layered keyboard with Dvorak layout and open source firmware, kaj mi parolas Esperanton.

They're just hobbies that, once you've sunk the hours in, they're awesome.

I don't actually type faster. Or maybe I do type a little faster because it made me use all 12 fingers instead of the ad-hoc 7-finger system you taught yourself in primary school, but typing was never a bottleneck, and split keyboards actually hurt my wrists more.

Jujutsu is marginally better than git, but costs time. If you like to spend the time, it will probably make you a little better. If you care deeply about your time, and it's already being allocated for anything but arbitrary intellectual pursuit, it's not worth it. Some people grow businesses, plants, or sedentary habits.

  "for all" / "there exists" instead of "every" / "there's at least one"
  "let" as an imperative for establishing facts
  "fix" for choosing a value
  "given" instead of "if"
  "modulo" instead of "except for"
  "if, and only if," when the occasion warrants it
  "implies" instead of "means"
  "trivial" without intending to be mean
  "yes" when asked an "or" question
  "transitively"
  "by symmetry"
  "it follows"
  "canonical"

You can say a lot with few words when you have rich definitions.

I don't cringe when I know it went through their head, because they didn't literally copy-paste it.

It's just a side-effect of immersion. It's exactly a tic, and I don't frown when people tic.

Economists say "all things equal" (which they're never outside of economic models).

My vanity compels me to not use Claude's linguistic identity. It gets sooo boring.

And in spite of reading hours of Claude every day, I don't sound anything like Claude.

Maybe I'm not as impressionable as Nolan. Maybe I'm less aware of my own words.

I was cultivating a "make an effort when you write" mental space, and this area only got stronger in my brain with Claude.

I suppose it's a fight to preserve my own linguistic identity. Or maybe I have enough monologue to keep the pressure out always.

Also, unrelated, I already had one of Nolan's blog posts open in my most recent tab. It should prove a thing or two about authentic human voice.

I hadn't thought about it before, but this is precisely what I did in one project.

After replacing a webhook that I've been monkey-patching for ten straight bugs, I had enough of an idea of how the software worked and what edge cases to look out for to reproduce the software without the bugs and with a well-modelled, well-tested foundational client library.

After testing the foundational client library with all the methods I know (unit tests, property tests, mock tests, integration tests, and live tests), I had a race condition in my live tests that accidentally turned into a fuzz test of the live service the client connects to, and discovered a bug in the server.

The actual webhook has been brewing for a long time. For weeks I've just casually added more tests. Nothing interesting happened. I've went live with it now, and nothing comes up. So on to make a load test with mock endpoints.

I love how AI makes advanced, extensive testing techniques (and TDD) take little enough time to justify using them all.

As someone who taught CS for some years, it is very satisfying to finally come to a point where "we're not testing" cannot be justified from an economic perspective, it is purely a cultural (or lack of cultural) decision, and a lack of knowledge of any testing techniques beyond unit testing.

Anecdotal: I recently rewrote a service in Rust for a much needed 100x performance boost (largely due to architectural changes, somewhat due to better runtime).

My colleague who now maintains the app is not a Rust developer and knows little about threads and tokio. Debugging a problem, he said he’d reach the context window before pinning the problem. I never have that problem and effortlessly find problems in the first 100k tokens without trying.

The difference must be in the wording that initially guides the agent.

Some of the items have tiny electrics inside, e.g. an actual tiny LED lamp.

The "scenery" (much like Warhammer battlefields) are then made from cardboard and hobby materials. You can also buy them pre-assembled, but they're much less impressive (usually one color, generic, e.g. "doll house" or "house sliced halfway"). There's a subgenre for 3D printing the scenery.

My wife uses small glass jars upside down. so the items live on the jar's lid. Looks very cute with a small LED lamp and lights off.

I think none of this is rare, but surely some items are more unusual than others.

The rarity comes from this being a hobby that not many know about.

Tiny magnets seems to be the item you run out of.