chriscbr

Random self plug - I liked a lot of these quotes from Alan Perlis, so around a year ago I bought the domain https://perl.is/ to display them.

nit: On my first read, I was a bit confused trying to solve the puzzle (without TLA+) because the second question was underspecified:

> If the algorithm terminates with b = 1, what must have been true at the start?

For anyone that wasn't clear, "b" isn't the number of beans in general, it's specifically the the number of black beans. Introducing a variable before defining what it is can be a bit confusing, hope this comment helps others.

Maybe "Rust maintainers' perspectives on AI" or "Rust contributors' perspectives on AI" would be better?

The author also posted a follow up about forge-specific repository folders ("magic folders" I suppose): https://nesbitt.io/2026/02/22/forge-specific-repository-fold...

Does Facebook/Meta still use Phabricator or Phorge directly? Or do they use a fork of one of them internally?

Here's my site! https://rybicki.io/

On my current team we run a centralized task scheduler used by other products in our company that manages on the order of around ~30M schedules. To that end, it's a home-grown distributed system that's built on top of Postgres and Cassandra with a whole control plane and data plane. It's been pretty fun to work on.

There are two main differences between our system and the one in the post:

- In our scheduler, the actual cron (aka recurrence rule) is stored along with the task information. That is, you specify a period (like "every 5 minutes" or "every second Tuesday at 2am") and the task will run according that schedule. We try to support most of the RRule specification. [1] If you want a task to just run one time in the future, you can totally do that too, but that's not our most common use case internally.

- Our scheduler doesn't perform a wide variety of tasks. To maximize flexibility and system throughput, it does just one thing: when a schedule is "due", it puts a message onto a queue. (Internally we have two queueing systems it interops with -- an older one built on top of Redis, and a newer one built on PG + S3). Other team consume from those queues and do real work (sending emails, generating reports, etc). The queueing systems offer a number of delivery options (delayed messages, TTLs, retries, dead-letter queues) so the scheduling system doesn't have to handle it.

Ironically, because supporting a high throughput of scheduled jobs has been our biggest priority, visibility into individual task executions is a bit limited in our system today. For example, our API doesn't expose data about when a schedule last ran, but it's something on our longer term roadmap.

[1] https://icalendar.org/iCalendar-RFC-5545/3-8-5-3-recurrence-...

I liked how this piece cuts through nostalgia and maps out (or at least gives a sketch of) where the valley actually is today. A few highlights that stood out to me:

- The sharp contrast between the '90s "Jeffersonian", hacker-libertarian spirit and today's more "Hamiltonian", state-capacity mindset, and how they're tied to the geopolitical and technical shifts that nurtured each era.

- The clear taxonomy of the new "tribes" (EA, abundance, American dynamism, New Right, tech ethicists, network-staters) and the axes they vary across -- human nature, progress vs preservation, role of the state. Nadia did a similar breakdown of climate activist tribes in "Mapping out the tribes of climate" a few years ago that I thought was interesting as well.

- There are some data nuggets that upend cliches, e.g. nine VCs controlling ~50% of 2024 fundraising, and tech elites being less anti-government than either party’s base.

- The insight that valley thinking now shapes national politics (e.g. J.D. Vance), showing tech culture's reach beyond product launches.

Same story with the Mojo language, unfortunately.

To me this raises the question of whether this is a growing trend, or whether it's simply that languages staying closed source tends to be a death sentence for them in the long term.

I only see around three .cpp files in the entire project?

I really appreciate this essay.

I've never been a [traditional] artist, but I reckon that those working in the arts, and even areas of the programming world where experimentation is more fundamental (indie game development, perhaps?), would intuit the importance of discovery coding.

Even when you're writing code for hairy business problems with huge numbers of constraints and edge cases, it's entirely possible to support programmers that prefer discovery coding. The key is fast iteration loops. The ability to run the entire application, and all of its dependencies, locally on your own machine. In my opinion, that's the biggest line in the sand. Once your program has to be deployed to a testing environment in order to be tested, it becomes an order of magnitude harder to use a debugger, or intercept network traffic, or inspect profilers, or do test driven development. It's like sketching someone with a pencil and eraser, but there are 5-10 second delays between when you remove your pencil and when the line appears.

Unfortunately, it seems like many big tech companies, even that would seem to use very modern development tooling otherwise, still tend to make local development a second class citizen. And so, discovery coders are second class citizens as well.

Neat concept.

I had a similar idea a few months ago about whether it's possible to achieve some form of comptime with TypeScript. I didn't get too far unfortunately, but I think the implementation would need to interact with the TypeScript compiler API in some way.