joel.place

Can Anthropic Write Software?

Sat, 02 May 2026 00:00:00 GMT

It is somewhat in vogue right now to criticize Anthropic. In particular, much ink has been spilled over the color of the Claude Status page and the corresponding lack of reliability, as well as accusations of fear-mongering about their latest model, Mythos. In these and many other domains, I have great sympathy for Anthropic. It is a hugely challenging problem to try and accommodate the pace of growth in agentic coding, made worse by their limitations in compute.¹ Furthermore, although they are certainly financially incentivized to espouse a belief in the overwhelming power of AI, I have found their employees to be genuine in their concern about its impact.² I wasn’t looking for an excuse to pile on. Nonetheless, when I accidentally found myself administrating my startup’s Claude subscription, I found myself a little shocked by the experience.

Lamentations

Let me briefly list out a few of the problems I’ve had in the “organization settings” page off the top of my head:

UI updates usually require a page refresh. If I change an employee’s status, the page will print a success message, but continue showing the old status.
Adding employees to the plan does not reliably succeed. After enough people telling me they didn’t get my invites, I’ve found myself refreshing the page to check the status after each invite so that I can retry if it wasn’t registered.
Downgrading users is nigh impossible. If I attempt to downgrade someone, I’m told I must schedule for it to occur at the end of the month, but then when I take any other action (e.g. adding or upgrading anyone else) I’m required to cancel any scheduled changes.
Employees are identified by first name only. If someone requests to increase the limits on their usage, I have no way to disambiguate (e.g. by their employee email they were added with).

Don’t even get me started on the janky broken scrolling experience that exists on certain pages.³ I’d report these issues properly if their process for such issues weren’t notoriously slow and painful.

Why I’m Surprised

To me, there are two main reasons for this to be so shocking:

Incentive: This is the bread and butter of the company’s revenue. They sell Claude Code to enterprises. I’ve focused my complaints here on the pages I can use in order to send them more money. Shouldn’t that be the very place they want the experience to be smoothest?⁴
Capability: This is also the key thing their product is considered best at. Claude Code makes beautiful web UIs faster than the most experienced humans. Presumably Anthropic engineers should have the most access to and be the most adept at using their own product?

Anthropic should be uniquely able and motivated to fix this. So why haven’t they?

Root Causes

So far I have two main theories to explain this:⁵

Carelessness: It is possible that, although important, this sort of work sanding down rough edges in the UX is simply seen as low status within the organization compared to the sort of research that might lead more directly to the goals of recursive self-improvement and super-intelligence. There’s so much else exciting going on that it’s easy for things to fall through the cracks. If that were the case, I would be a little bit worried about Anthropic, and its ability to maintain its enterprise advantage as it scales into a bigger organization.
Kool-Aid: It is possible that rather than appearing despite the power of Claude Code, these sorts of issues are in fact symptomatic of the ways that language models can now intermediate between developers and their products, and of an organization uniquely enamored with this capability. Perhaps a human more tightly integrated with internal testing might have caught these before they reached me. If this is instead the case, then I worry not for Anthropic, but for all of us who’ve begun to rely on agentic coding more heavily, and may soon face the costs.

I won’t claim to know which of these or the many other possibilities is more true, but I certainly hope it’s something closer to the former, and that Anthropic can assign a few more people to tighten all this up and prove that to us.

I’m even amenable to Dario’s arguments that, given what they knew at the time, aggressively acquiring more compute earlier would have been irresponsible. ↩
Many had similar beliefs before any of this was profitable, and it’s only sensible that they’ve updated them to be more aggressive given the pace of advancements. ↩
But not others, since there is limited consistency to the UI even when representing seemingly similar-shaped data. ↩
Perhaps admin pages are universally secondary to those for the end users, but they’re still an important stakeholder to have on board. ↩
A third possibility could be that organizations like ours doing our own administration are simply too small to matter compared to the biggest customers. ↩

A Path Not Taken for OxCaml

Fri, 24 Apr 2026 00:00:00 GMT

OxCaml is Jane Street’s effort to oxidize OCaml, that is, to make it more Rust-like. In particular, the aspect of Rust focused on here is its “fearless concurrency” where the compiler can protect against data races, which is important in light of OCaml 5’s new multicore capabilities.¹

The project adds a significant number of exciting new features to the language (modes, kinds, layouts, etc.), but is careful to act only as an “extension” to the language, promising on its front page that

all valid OCaml programs are also valid OxCaml programs

I’m going to argue that this promise, while noble, was ultimately misguided, forcing it to give up on what could have been a simpler language. To do that, we’ll first have to go over a little OxCaml, talk about how it’s complex, consider its use in practice, and then finally explore an alternate path. Hopefully by the end you’ll understand why, despite this promise, the Core validation library went from looking like this

type result
type 'a check = 'a -> result

val combine : result -> result -> result
val of_list : result list -> result
val name : string -> result -> result
val name_list : string -> result list -> result
val fail_fn : string -> _ check
val pass_bool : bool check
val pass_unit : unit check
val try_with : (unit -> unit) -> result
val first_failure : result -> result -> result

to instead like this (sans comments for brevity)

type result : value mod contended
type%template ('a : any) check = 'a -> result @ p [@@mode p = (portable, nonportable)]

val%template combine : result @ p -> result @ p -> result @ p [@@mode p = (portable, nonportable)]
val%template of_list : result list @ p -> result @ p [@@mode p = (portable, nonportable)]
val%template name : string -> result @ p -> result @ p [@@mode p = (portable, nonportable)]
val%template name_list : string -> result list @ p -> result @ p [@@mode p = (portable, nonportable)]
val%template fail_fn : string -> (_ check[@mode p]) @ portable [@@mode p = (portable, nonportable)]
val%template pass_bool : (bool check[@mode p]) [@@mode p = (portable, nonportable)]
val%template pass_unit : (unit check[@mode p]) [@@mode p = (portable, nonportable)]
val%template try_with : (unit -> unit) @ p -> result @ p [@@mode p = (portable, nonportable)]
val%template first_failure : result @ p -> result @ p -> result @ p [@@mode p = (portable, nonportable)]

Modes

So what’s that word “mode” we’re seeing above? OxCaml’s mode system is sort of like its type system, in that every value x : t @ m has some statically known type t and mode m, where @ is the syntax for mode annotation.

Modes are deep properties (so m applies recursively to the contents of x) and are formed as a lattice of different mode axes which are generally orthogonal to types and each other (although values of some types can disregard or “cross” certain modes). To make this concrete, let’s look at some examples of how they might map onto Rust’s type system.

Modes & References

At Rust’s core is a borrow checker, which enforces each value x: T has a single owner, but allows it to be temporarily borrowed as &x: &T or &mut x: &mut T, with these borrows reflected in the type system. How might we express something similar in OxCaml?

Well, rather than being forced to change the type of our value to reflect these, we would put this additional information about how it can be used into its modes:

&x: &T might loosely correspond to x : t @ local read aliased
x: T might loosely correspond to x : t @ global read_write unique

Here, we see our first three mode axes:

Locality: local indicates a value which cannot escape its scope, whereas global values can do so (analogous to Rust’s lifetimes).
Visibility: read indicates a value which can read from but not write to its mutable state, whereas read_write values can do either.²
Uniqueness: aliased represents a value which may have other references to it, whereas unique values act like Rust’s affine type system.

So far I’m relatively fond of these modes: they create clarity about what they each control rather than intermingling in a single concept of ownership, and don’t need to corrupt the type of x to represent this in the way that Rust’s version is also inextricably linked with whether we have a reference with indirection.³ However, you can probably see already the danger of a sort of combinatorial explosion in possible states as the number of axes that can be set independently increases.⁴ If each value can have a type, a locality, a visibility, and a uniqueness, that’s a lot more to hold in your head than usual.

Modes & Traits

OxCaml also has some modes that don’t map as directly onto Rust’s concepts of ownership, but instead look more like what Rust might put in a trait. In particular, I’d like to focus here on the portability mode:

Portability: portable indicates a value which can be shared with another thread⁵, whereas nonportable values cannot do so.

Portability can be thought of as analogous to Rust’s Send and Sync traits, which determine a type is safe to be shared across threads.⁶

Note here a crucial distinction. Our Rust concept was a property of types: if T: Send + Sync, then any value of type T could be shared between threads. Meanwhile, in OxCaml this is a property of values. It is possible to have values x1 : t @ portable and x2 : t @ nonportable with different portabilities despite having the same type.

This may be initially unintuitive to a Rust programmer, who is used to thinking about types as determining thread-safety. Canonically, atomically reference counted Arc<_> values could be shared, while non-atomic Rc<_> versions could not. However, the important thing to remember is that, in OCaml, functions are all values of the same arrow type:

val func : t1 -> t2

and the space of possible functions is very large, including both those which can clearly be shared across threads, as well as closures which capture mutable state, and therefore cannot be called from multiple threads without risking data races.

This means the arrow type cannot have one deterministic portability applied to all of its values.⁷ Furthermore, since any abstract type could potentially contain a function, this means just about every OCaml value must maintain some portability state (apart from those which are explicitly annotated as containing no functions and therefore “crossing” portability).

OxCaml divides its 9 currently documented modes into 4 “past” modes like the ones we saw earlier, and 5 “future” modes like portability, which are relevant only for types which contain functions for similar reasons to this.

Default Modes

Now, we’d said earlier that OxCaml promised backwards compatibility with any OCaml code. One immediate observation is that old OCaml code did not have mode annotations everywhere, and so OxCaml must be able to handle code which does not specify modes. To do so, it uses “default modes”.

Each mode axis has a default position, which is assumed when no mode is explicitly annotated. These defaults must be chosen carefully so that they do not break backwards compatibility:

Locality: In OCaml, we never had to worry about whether a value was allowed to escape its scope. Therefore, our default mode must be global.
Visibility: In OCaml, we never had to worry about whether we had permission to mutate a value of a type with mutability. Therefore, our default mode must be read_write.
Uniqueness: In OCaml, any value could be freely aliased, or have been so in the past. Therefore, our default mode must be aliased.

In general, so far we’ve set all of our modes to be maximally permissive, allowing you to do as you please with your values.⁸ Now let’s think about how we should extend this to the portability mode.

So, legacy OCaml code was always single-core⁹, and therefore there’s no legacy concept of whether values could be shared between them which we need to maintain backwards compatibility with. It would be nice if we could therefore continue to use the permissive modes, and by default allow values to be shared between threads.

However, this doesn’t mean we’re free to just set any default that we want, as we’d made another promise: that OxCaml would statically prevent data races. And as we discussed earlier, there exist some values which could cause data races if shared across threads. Therefore we must set

Portability: In OCaml, there exist functions that are not thread-safe. To be free from data races, we must conservatively assume all values are nonportable.

Unfortunately, this time we must choose the default mode that is more restrictive. Because the default mode applies to all legacy OCaml code, this means that all OCaml code, when used in OxCaml, must be presumed not to be thread-safe.¹⁰ That’s going to cause us some pain when writing code.

Portabilization

So what does it mean for us to say that all legacy OCaml code is going to be nonportable? Well definitionally, it means that those values cannot cross threads, but let’s think about the further implications.

One thing OxCaml likes to emphasize along with its backwards compatibility story is its “pay-as-you-go” complexity. That if you don’t need some particular new advanced feature, you can simply avoid it and continue to write plain old OCaml. Can that work out in practice?

Portability Interoperability

If we took that literally, we might want to write most of our code in OCaml, which OxCaml would interpret as nonportable. Then we would only adopt OxCaml’s concurrency features and their corresponding complications when we needed them for scaling performance-critical apps.

In this world, we might further hope that when we wrote a new app or moved some existing app to portable concurrent OxCaml, it could still take advantage of the larger OCaml ecosystem and preexisting libraries. Unfortunately, that’s going to prove difficult.

You see non-portability is infectious. We’d said earlier that modes are deep: applying recursively to all of a value’s contents. So a portable value cannot contain anything nonportable, and any function which calls a nonportable function must itself be nonportable.

Given that all values in the default mode are nonportable, asking you to write portable concurrent OxCaml that depends on nonportable legacy OCaml is sort of like asking you to write synchronous code that depends on a library in which every function is async. It just doesn’t work!

However, this does not mean that all hope of true backwards compatibility is lost. There remains a ray of hope in the opposite direction, if you want to write OCaml code depending on OxCaml. A nonportable function can call portable functions. This opens up a path for how our OCaml and OxCaml might coexist.¹¹

Migration

If we want our portable OxCaml and nonportable OCaml to share dependencies, we’re going to need to start from the very bottom of the dependency stack, where no existing nonportable code is depended on. Converting that library to portable OxCaml is safe, because existing OCaml code can still use it, and now portable code can too.

Once we’ve done that, we’ve now opened up another few libraries which we might be able to migrate, because they now only depend on portable libraries, and so they themselves can become portable. Gradually, we can expand the scope of our migration out to the entire ecosystem in a process we’ll call portabilization.

As we’re performing this migration, we can effectively find ourselves in one of two states¹²:

Either our code is already thread-safe, frequently via use of immutable persistent data structures, and just needs to be annotated as such in its signature.
Or our code had the possibility of data races in the presence of multiple threads, and needs to be fundamentally rewritten or restructured to avoid this.

The former of course is simple, but the latter can create real work. Especially when porting the sort of performance-critical code we’d most like to move to OxCaml. That’s the same code most likely to use heavy mutation.¹³

However, we persevere because we can see the light at the end of the tunnel. If we can take all of our libraries and move them one by one from OCaml to OxCaml, then we will finally be able to inter-operate between the languages: choosing to write code in either portable or nonportable fashion and share the same dependencies. For an organization like Jane Street with a large quantity of existing OCaml code that cannot all be migrated at once, this is essential.¹⁴

Bifurcation

Still, does it feel like I pulled a bit of a sleight of hand on you there? I started this post talking about how the language was fully backwards compatible, and could compile all old code with no changes. Yet now I’m describing a world in which we must actively migrate all libraries from OCaml to OxCaml?

And even once we’ve done so, and all our libraries are in portable OxCaml, granting us the freedom to choose which way we want to write apps depending on them: which way do you think we’ll choose? The one where nobody else can depend on us and we might have to migrate in the future? No, we’ll probably stick with this new portable OxCaml.

In that case, incorporating OxCaml into an OCaml ecosystem risks feeling like migrating languages completely. You have to get used to new unfamiliar syntax for modes and layouts. You even have to substantially rewrite the logic of some of your code to fit the paradigms of the new language in which closures over mutable data are restrictive.

It’s not quite as bad as the Python 3 migration¹⁵, but the backwards compatibility promise wasn’t quite what we’re used to for regular language evolution where we can mostly avoid touching our old code. It’s like we’re migrating languages, but with a special property: that OCaml code can depend on OxCaml code, and the two can share the same toolchain.

To some extent that was unavoidable. There was genuinely a lot of OCaml code which was safe only because it was known that it could never cross threads. That couldn’t be magically transferred to a multicore language without modification. Still, if we acknowledge that kind of migration is all we can do, then perhaps we can widen the design space we consider.

Another Path

So what if we took that literally? If we decided that we’d never quite achieve true backwards compatibility between a language which required thread-safety and one that only ever used a single thread. If we concluded that the best we could hope for was the existence of a migration path from OCaml due to the ability to gradually swap out components and still use OCaml code?

This sort of change might feel like Rust’s concept of editions: where a project decides which edition of the language it will be written in, and the editions aren’t necessarily backwards compatible with each other. However, they still keep compatible interfaces, and even provide automatic migration tooling to convert from one to the other.¹⁶

How would we design our thread-safe successor edition? Would we choose to write OxCaml? I would argue not. As we saw in the setting of default modes, the constraint that this language be able to compile plain OCaml really placed a lot of restrictions on us. And those restrictions led to complexity: in the combinatorial explosion of modes as we’ve focused on here, but also in the ways we can use unboxed types, layouts, and other OxCaml features.

The space of possible languages is huge, and I won’t claim to come here with the perfect version. Still, let me talk through at least some of the ways we might improve upon the ailments we’ve discussed for a hypothetical better OxCaml.

Portability

In a language designed for multithreading, portable should be the default mode, and nonportable values should feel like an exception. This is especially true in a functional language where immutability is the default, but holds even outside that. Rust requires static mut to be wrapped arduously in unsafe, and this sort of thing should feel similarly discouraged in OCaml. Instead, this sort of globally shared mutable state is made to appear easy and idiomatic by the language.

If you look through OxCaml branches of Jane Street’s core libraries, this is already effectively the case, with most files starting with @@ portable to indicate that the entire module’s contents should be taken as portable. Still, I don’t want to have to scroll up to the top to learn how to interpret a declaration. If this is what’s sensible, I’d argue it should apply in general, and nonportable values should have to explicitly inform us of their presence.

A migration tool here might mark every value as nonportable, or only those the compiler could not automatically infer to be portable. To legacy OCaml edition dependencies where modes are erased, this would of course have no impact whatsoever, as there would still be no concept of crossing threads.

Functions

Still, it is possible to imagine better: a world not just with a sensible default, but where we could get rid of the portability mode altogether. To do that, we would have to represent the difference between a thread-safe and non-thread-safe function in the type system, sort of like Rust’s Fn, FnMut, and FnOnce.

A function which is intrinsically nonportable is one which mutates values held in its closure, which could cause a data race. Another way to say that, is it is a function which, in order to be called, should have read_write¹⁷ access to the contents of its closure on the mutability mode. Ordinarily, our modes are deep and apply recursively to a value’s contents. A function’s closure is the one exception where we don’t track or enforce this.

You could imagine expressing that in the type of our functions. Where rather than having type (-in, +out) fn, OxCaml might have type (-in, +out, +mode) fn, where mode is the mode in which you must hold that function in order to be allowed to call it.¹⁸ Now data races on the contents of closures could be handled by the same mechanisms that stop data races elsewhere. Migrations could assume conservative requirements of their functions.

Suddenly, we could basically cut out our future modes. While this risks its own form of combinatorial explosion, it’s one much more limited in scope. These parameters apply only to functions, not to all values like our modes, and in most cases you probably don’t need to be generic over all of them, and might have some expectation about what manner of function should be allowed in a given use case.

Beyond

One could imagine even crazier proposals to eliminate further modes or simplify OxCaml’s other features. It could even adopt linear or affine types as the default rather than an as after-thought mode, since linear logic really does simplify many of our problems. I won’t try to iterate all of these possibilities.

It can sound here like perhaps I am saying that OCaml should cease to exist, and that if it is going to adopt some Rust-like features it should just go all the way. I’d like to make clear that I do not believe that. I find OCaml to be a particularly elegant language, and it is for exactly this reason that I am both eager to increase its capabilities and hesitant to add complexity.

Perhaps Jane Street could not have feasibly offered a proper edition without backwards compatibility when they don’t control the language and can’t always pull upstream with them. Still, if some of these changes make it back into upstream, that would offer an opportunity to consider such choices and add this power in the best possible way.

I believe OCaml should learn as much as it can from the experiences of other languages for how to offer safe concurrency. It is understandable that doing so may require new syntax, but when that is already the case, I don’t think making the syntax only nominally an exact superset of what exists is worth making it more complex than it needs to be.

OxCaml contains other Rust-like features, such as its ability to handle types with multiple layouts beyond OCaml’s standard one-word option, but we won’t focus on those for this post. ↩
There also exists an immutable mode for values which can only access the immutable parts of their state, which has no real parallel in Rust where all fields are potentially mutable. ↩
Rust has had repeated proposals for &own references that can decouple responsibility for cleaning up memory from whether or not you have a pointer, among similar messiness. ↩
That explosion is even actualized by ppx_template we saw in our example, which really does expand out to all of the different mode combinations. ↩
Here the proper term would really be “domain”, which is OCaml’s version of a green-thread, but I’ll continue to use the term “thread” interchangeably in this piece, as does much OxCaml documentation. ↩
Send and Sync may feel distinct, but it is able to capture both simultaneously due to yet another mode tracking “contention” which roughly captures whether a value is exclusive to its thread. ↩
Whereas in Rust, each closure has its own anonymous type, so that not all closures need to share the same Send and Sync state. ↩
More formally, the mode axes include a notion of submoding, and we have always chosen the least mode which can freely move to any of the other modes. ↩
Here I’m considering “legacy OCaml” to be OCaml 4, with OxCaml as a potential upgrade from that. OCaml 5 does introduce multicore without these safety features, for which OxCaml does not make the same backwards compatibility promise. ↩
This is made even worse by OCaml’s use of explicit .mli interfaces separate from .ml implementations. This means that even when the compiler can infer some values are portable, that can’t be exposed without annotation. ↩
I realize there is an implicit assumption here that OxCaml code is necessarily portable. While not strictly required, I argue that if you were going to forgo multicore capabilities, you might as well write ordinary OCaml instead. ↩
Alright 3 states: it’s possible our values are portable but the compiler can’t prove it and so we’re sprinkling Basement.Stdlib_shim.Obj.magic_portable everywhere. ↩
It was in fact, a common practice in certain circles to pre-allocate a single global value and then mutate that to hold current data in non-recursive functions. This avoided allocations that might trigger a garbage collection cycle. ↩
Even their much smaller-scoped migrations need to be careful not to disrupt existing systems, e.g. https://signalsandthreads.com/swapping-the-engine-out-of-a-moving-race-car/. ↩
In which Guido Van Rossum famously made the opposite promise

There is no requirement that Python 2.6 code will run unmodified on Python 3.0. Not even a subset. (Of course there will be a tiny subset, but it will be missing major functionality.)

↩
Admittedly Rust’s editions offer somewhat stronger guarantees in that they allow dependencies in either direction. This causes its own pain for things like Pin types. ↩
Strictly speaking it also needs to be uncontended on the contention mode, but the idea still applies. ↩
Although currying makes this somewhat more unwieldy, and you wouldn’t want to have to annotate every arrow of a t1 -> t2 -> ... -> t_n. So you’d probably have to keep the existing syntax to denote the case which does not make any requirements on the mode of its closure, which would be by far the most common case, and certainly apply to early curried arguments. ↩

Dwarkesh, Lex, & Ezra

Mon, 20 Apr 2026 00:00:00 GMT

I am eternally grateful to Dwarkesh Patel for creating real competition to the Lex Fridman Podcast. I find Lex to be a completely unbearable podcast host, capable neither of contributing anything I want to hear himself, nor eliciting interesting opinions from his guests. That made it a tragedy that for so long he seemed to monopolize the big name guests in CS, AI, tech, and the like. I’m also not that enthralled by his secondary bro-y focus, much preferring Dwarkesh’s excursions into history, China, and the like.

However, as of late, particularly after his relatively combative episode with Nvidia’s Jensen Huang, there has been more chatter online about whether Dwarkesh too could be lacking in some ways. Most of this conversation has been picking sides: determining whether Dwarkesh or Jensen was right about whether AI chips should be sold to China, and which one of them was the more skillful debater. Although those are interesting questions, I’d like to ask something else: whether the nearly 40 minutes spent pressing Jensen on this produced the best possible podcast as an artifact, and whether Dwarkesh’s craft could be improved by dropping things sooner.

Interview Podcasts

Dwarkesh’s podcast fits into the broader genre of interview podcasts. These are perhaps the most dominant form of podcast, usually involving some persistent host, along with a rotating cast of guests per episode who they converse with. Guests are typically chosen to be noteworthy or interesting figures within the field or domain that the podcast and its host focus on. The host and guest then engage in a somewhat free-form conversation, with the host usually guiding and bringing up topics, but allowing the guest to provide most of the content.

This is in opposition to podcasts with more simultaneous participants, where keeping a single thread of conversation and taking turns at the mic can be harder, as well as podcasts that are exposition of a scripted narrative, often by only one person. You can see why interviewing is such a popular format. Rather than relying on the host or hosts to be a constant wellspring of new and unique thought at the pace demanded by the modern internet, they only need each guest to have enough depth to make one interesting episode. Topics fall out naturally from their expertise, and the variety keeps things interesting.

Conversation

With so many of these interview podcasts aiming to feel like a sort of conversation, a natural question for us to help elucidate their purpose might be “why should somebody listen to such a podcast instead of having a conversation of their own?” Surely it would be more engaging to be part of the conversation rather than a passive observer to it, and that would in turn help you learn more. Well, there are a few obvious difficulties with that, mostly centered around scale.

Many of the most exciting guests with interesting knowledge and experience are in high demand. We can’t all get our turn talking to the CEO of the most valuable company on the planet. However, if one person records their conversation with him to a podcast, then all of us can listen in. Additionally, if we’re all going to hear that same conversation, then it becomes worth the host’s time to prepare well: reading up on relevant context and planning out good questions that will result in hearing better stories. Maybe this lets all of us get access to a better dialogue than we would have had ourselves.

The Platonic Ideal

Still, there is a way in which the best version of this for me as an audience member is one close to the conversation I might’ve had myself if I had the same level of access to guests and time to prepare for interviewing them. I synthesize information best when I am actively working with it. So in much the same way as I felt the best way to listen to lectures in college was to try and constantly predict where the next five minutes would go and what conclusions would be drawn, I like to listen to podcasts by silently looking for holes in the explanations and arguments given, or connections to other interests.

That is to say, during a lot of my listening I am effectively considering what questions I might ask, or where I might take the conversation if I were the host. So there’s a special joy I get, when in fact a podcast’s host has the same curiosity as I do (or that I would, if only I had the same level of preparation). In these cases they are able to explore that idea and get the answers for me. In doing so, they are getting as close as possible to the world in which I actually got to have these conversations. In contrast, when they go on tangents I don’t care about, or prevent the guest from exploring something interesting, that gets further away.

The Ezra Klein Show

For me, the podcast host who comes closest to this ideal is Ezra Klein. He clearly does the reading, and can engage meaningfully with guests across a variety of topics (even if that makes it a pity that so much of his content is now focused just on politics). Quite reliably, when a guest says something interesting that I’d want to tug on more, or something questionable that I’d want to challenge, he’s there first, able to channel the conversation in the direction I’d like it to go. Maybe this is just another way of saying that I think Ezra is smart.

However, just as important to me as this in creating a good listening experience is that he’s empathetic. He’s empathetic to the listener, making sure to define terms and bring in context explicitly, even if he and the guest are both familiar with them. He’s also empathetic to the guest, clearly trying to feel out what they’re interested in talking about. As a rule of thumb, he almost never seems to object to the same thing more than once. Sometimes a guest will say something nonsensical that he pushes back on, and the guest will find themselves repeating their original position, or unable to respond properly. In these cases, rather than pressing the point to win the argument and expose them as inconsistent, Ezra just moves on, keeping the guest comfortable and allowing the audience to see that on their own. Although my monkey brain sometimes wants the confrontation, in retrospect I’m always glad to be able to spend more time on what the guest is thoughtful and has good points about rather than sticking in the areas where they are wrong and should be ignored.

Returning to Dwarkesh

Dwarkesh clearly also puts in the research time, talking in a recent episode about how he wishes he could be tested on the topics to cement his learning. However, it is in this second aspect where he sometimes falls short. He self-admits to often playing devil’s advocate, which can be a fine conversational device, but sometimes leads to the conversations getting stuck: where there is fundamental disagreement between him and the guest, or something he wants the guest to say more on or acknowledge, which they are unwilling to do. In the aforementioned Jensen interview, he spends nearly 40 minutes trying repeatedly to get Jensen to say that giving China more compute is dangerous. In these cases, it feels like I am denied the ability to explore the full space of the guest’s mind and ideas because we must devote so much time to this focus of Dwarkesh’s.

When people have tried to explain to me the appeal of Lex Fridman, they often say something quite close to this: that he acts as an unthreatening blank slate, in a way that is attractive to guests and allows them to get out their ideas without being obstructed. While I appreciate Dwarkesh’s ability to be an engaged host, and think this produces a better result than just a monologue, it’s possible there’s something to this. Maybe he too can eventually find a middle path that produces a better product for the audience even if it wins fewer debates decisively. The art of podcasting is largely about extracting from each guest the stories and knowledge only they can give, and a concession forced out of them by the host can’t be that.

Post-Penultimate Conditional Syntax

Sat, 04 Apr 2026 00:00:00 GMT

In the control flow of many programming languages, there exists a sort of divide between boolean if/else conditionals and pattern matching statements¹ which may bind values for future reference. In choosing syntax for my own language, I wanted to see if I could unify these two. Here lie my attempts at creating an ideal conditional syntax.

Prior Art

Existing languages have often noticed this distinction and made some effort to bridge the gap and allow one construction to better cover scenarios that might ordinarily require the other. Let’s start with my two primary inspirations: OCaml and Rust.

OCaml: Putting `if` in `match`

As an ML-family language, OCaml tends to treat match as the primary conditional.² To permit that, it provides match some of the flexibility of if by introduction of the when clause, which adds a conditional that must be met in order for a branch to be taken. This lets us write something like

let rec has_repeated_pair list =
  match list with
  | [] -> false
  | x :: y :: rest when x = y -> true
  | x :: rest -> has_repeated_pair rest

where we have a single expressive top-level conditional which lists out the possible cases. Meanwhile, if we had to use purely ordinary if and match we might be forced to instead write

let rec has_repeated_pair list =
  match list with
  | [] | [ _ ] -> false
  | x :: y :: rest ->
    if x = y then
      true
    else
      has_repeated_pair (y :: rest)

having to increase our indentation and nest the logic a bit. This isn’t so painful for such a small function, but you can imagine that the complexity felt compounds in real logic. These are the sorts of inconveniences we’ll try to avoid today.

However, this syntax has clear limitations. First, one can do no additional binding or pattern matching after the when, which means that we might still be required to nest for something as simple as this:

let pipelined x =
  match f1 x with
  | Error e1 ->
    ...
  | Ok y ->
    match f2 y with
    | Error e2 ->
       ...
    | Ok z ->
       ...

or in any equivalent case where further computation requires new bindings.³ Second, and more dangerously, these when clauses actually make the language unsound, such that this code will compile without any warnings, but then crash on ref false:

let impure_guard (x : bool ref) =
  match x with
  | { contents = true } -> (* compiler believes this covers the true case *) ()
  | _ when (x := true; false) -> (* mutates x *) ()
  | { contents = false } -> (* compiler believes this covers the false case *) ()
;;

A key feature of match statements is their ability to check exhaustiveness, ensuring that they cover all possible cases. Doing so is complicated when there might be arbitrary mutating functions in the middle. Clearly this is not yet a perfect solution, so let’s see how Rust, as a newer language, approached it with the benefit of hindsight.

Rust: Putting `match` in `if`

Rust is somewhat more imperative and systems-focused, so it approaches from the opposite direction, treating if/else as primary, and giving them some of the power of match by way of the if let statement. This allows let to be used not just as a way to deterministically bind to expressions, but also act as a conditional for whether a pattern can be bound:

fn if_let() {
    let x = deterministic();
    if let Some(y) = conditional(x) {
        ...
    }
}

This adds some complication to the language. Now, depending on the surrounding context, let may or may not be an expression of type bool. It also reads backwards relative to the dataflow, where you first compute a value and then inspect it. Nonetheless, it does neatly resolve the sort of pipelining we discussed earlier without nesting:

fn pipelined_1(x: T) {
    if let Ok(y) = f1(x)
    && let Ok(z) = f2(y) {
        ...
    } else {
        ...
    }
}

At least, it does so long as we are alright treating errors in f1 and f2 as equivalent, which may not always hold. We’ve been able to clean up the happy path, but haven’t really represented all branches well in our conditional. To achieve that, we might try yet another Rust feature, the let ... else:

fn pipelined_2(x: T) {
    let Ok(y) = f1(x) else {
        // must diverge
    }

    let Ok(z) = f2(y) else {
        // must diverge
    }

    ...
}

These represent a conditional where the happy path can be raised to the top level because the other branches must return early or otherwise can never resume the rest of the function. They let us handle the two kinds of errors differently, but still don’t actually let us inspect e1 or e2 in our failure case. We haven’t really accessed the full match-like power to destructure the Result<T, E> type and say “f1(x) is either Ok(_) or Err(_)”, let alone handle cases with more possible branches or without a single happy path.

Rust has identified some of the most common patterns and created syntactic sugar that works well for those specialized cases. However, with so many different syntactic structures punning the same keywords and not yet covering the general case, we haven’t yet found my desired simplicity. We’ll have to venture further to the world of niche languages.

Ultimate Conditional Syntax

So I wandered the blogosphere and came upon the Ultimate Conditional Syntax (UCS), which appeared to be about the state of the art in unifying these concerns into a simple syntax. It introduces two keywords to a toy language: is and and. In the spirit of these coming from a proper paper, let me try and give them proper definitions.

expression is pattern is a boolean expression. More specifically, it is the expression that evaluates to true if and only if pattern binds to expression. This means that in contexts where we learn it is true, we can use those bindings in our environment:⁴

if x is Some(y) {
    do_something x
}

We gain extra bindings inside the if, analogous to how we might gain some type unification when matching on a GADT. This functions in an equivalent manner to Rust’s if let ..., but I appreciate having a new keyword to distinguish it. and, meanwhile, is perhaps best understood by example.

if x is Some(y) and y is Some(z) {
  ...
}

can be viewed as syntactic sugar for the following:

if x is Some(y) {
  if y is Some(z) {
    expression3
  }
}

This is, of course, how boolean and or && operates under the hood in many languages that permit short-circuiting: skipping evaluation of the right hand side if the left turns out to be false. However, it is worth emphasizing that this is truly a kind of control flow that deserves a keyword, and nothing like other infix operators that evaluate both their operands before applying some function.⁵ Additionally, this means that it has special interactions with is expressions.

In order for us to even begin evaluating the right side, it must be the case that the left side was true. Meaning that we can use any of its bindings in evaluating the right side. Likewise, we can use both of their bindings inside the if, which makes sense since and gives the expression that is true if and only if both of its operands are true, and here our operands use is which binds when that occurs.⁶

To me, this felt like a pretty strong start towards the goal of giving if/else the power of match, tightening up Rust’s let-chains. Sure, it was still missing match’s exhaustiveness check and ability to combine branches, but we could build up to those. That made it all the more disappointing to me when the paper re-introduced a match-like construct for these:

if x is {
  Ok(ok)   => ...
  Err(err) => ...
}

Sure, they reused the keywords if and is to build it, but what I was searching for was not just keyword punning: I wanted to see if I could merge the language constructs properly. As it is here, we’ve introduced confusion about whether is should be followed by a pattern to conditionally bind to and evaluate to a boolean, or a list of cases to exhaustively enter one of, and the remainder of the paper is forced to tackle the complexity of disambiguating during compilation.

Post-Penultimate Conditional Syntax

I’d like to resume where UCS left off, which I suppose forces me to adopt a ridiculous name like Post-Penultimate Conditional Syntax.

OR Patterns

One simple thing I’d like to be able to recreate from match statements is the ability to merge branches that would create the same bindings:

match list with
| [ last ] | [ _ ; last ] | [ _ ; _ ; last ] -> f last
| _ :: _ :: _ :: _ :: _ -> failwith "more than 3 elements"

It’d be substantially more verbose if each |-separated pattern needed its own case:

if list is [ last ] {
    f last
} else if list is [ _, last ] {
    f last
} else if list is [ _, _, last ] {
    f last
} else {
    panic!("more than 3 elements")
}

To do the same in our world of boolean logic, we’d have to introduce an or operator⁷, which we could think of as syntactic sugar for the former. After all, a short-circuiting or would execute the second operand only if the first was false, just like an else:

if list is [ last ] or list is [ _, last ] or list is [ _, _, last ] {
    f last
} else {
    panic!("more than 3 elements")
}

Where and was the operator that, when true, gave the union of all bindings from its operands (since they must both be true), or would be the operator that, when true, gives the intersection of its operands’ bindings⁸, since at least one must be true, but we can’t assume that it’s any specific one.

Exhaustiveness

Now perhaps more intimidating, the ability of the compiler to check exhaustiveness of some conditional, ensuring that it will always enter some branch, is very important to match. In particular, it is what allows it to be an expression with a non-unit type, otherwise there’d always be a risk we didn’t enter any branch and didn’t know what value to use.

To rephrase that a little bit, we could say the thing an exhaustiveness checker needs to prove is that “conditional on not having entered any of the prior branches, we are guaranteed to enter the last branch”. And as it turns out, in curly-brace syntax there’s some unused space in the if/else construct where we could put just that information:

if x is Ok(ok) {
    ...
} else x is Err(err) {

}

Here, when an expression e comes after else, the exhaustiveness checker must be able to prove that, if we were to reach the else, then e must evaluate to true. This is identical to what we’d have to prove in a match, doing casework on the scrutinee(s), which are inferred from the expression behind the else rather than stated up-front. Now we can even combine to write things like

if query_result is Ok(info) or (retry_allowed and do_retry() is Ok(info)) {
    ...
} else query_result is Err(err) {
    ...
}

Putting It All Together

So we’ve now got

A judgement we can make about expressions, in which we say they produce some bindings when they are evaluated to true.
The is keyword, which serves as the basis for expressions which we can make such judgements about.
The and and or keywords, which compose these using union and intersection respectively.
The if and else keywords, which allow us to unpack and use those bindings and check exhaustiveness.

I’m pretty happy with unification and the way it recreates seemingly particular features in a single coherent system by grounding itself in an algebra. One could even imagine introducing a not keyword, which inverts whether expressions form bindings on true or false. Combined with analysis that a block must exit early (return, break, etc.) this would recover Rust’s let ... else guards, but feel like a natural extension rather than additional distinct syntax for newcomers to learn. Before we get too excited though, let’s think about a couple of concerns.

Concerns

Unsoundness

To start with something familiar, earlier I brought up how OCaml matches could be made unsound by using when clauses with functions that had the side effect of mutating the values being matched on. One could imagine a system like this in which exhaustivity checks are less clearly contained to lead to more common issues of this kind.

Indeed, I would not recommend this syntax to OCaml, which has historically been able to permit mutation without constraint due to its single-threaded runtime.⁹ Luckily, however, Rust-like languages already solve this by requiring that functions annotate whether they mutate their arguments. Any mutation then invalidates the compiler’s notion that it has already covered some cases, preventing the unsoundness.

Ergonomics

Probably the bigger thing you’ve been noticing though, is how this system can sometimes be more verbose than the kind of match statements you’re used to. It forces you to name intermediaries and then repeat their name in each is:

let result =
  big_computation(
    many,
    long,
    arguments);
if result is Ok(_) {
    ...
} else result is Err(_) {
    ...
}

whereas a standard match might have allowed you to write just

match
  big_computation
    many
    long
    arguments
with
| Ok _ ->
    ...
| Error _ ->
    ....

Indeed, for the case of a single computation which acts as the scrutinee in a conditional with many cases, we cannot be more concise than syntax specifically designed for that scenario. That is even a sufficiently common situation to perhaps warrant the retention of a match or similar statement. However, that is not all cases, and our familiarity with it as the standard may force the paradigm into cases where it doesn’t make sense. E.g., if we wrote in this new syntax

if result1 is Ok(val) or result2 is Ok(val) {
    ...
} else result1 is Err(e1) and result2 is Err(e2) {
    ...
}

to fit it into a match we might have previously written

match result1, result2 with
| Ok val, _ | _, Ok val ->
    ...
| Error e1, Error e2
    ...

This encodes the same idea, and may even be more ergonomic, but it suggests the wrong semantics. In OCaml, the creation of a tuple to use as a scrutinee should theoretically incur a heap allocation, as all values bigger than one word are boxed. Meanwhile in Rust, the creation of the tuple (assuming it is owned) should theoretically incur a move of the results into a new segment of stack memory. Neither of these costs should be necessary when we can just inspect the results directly. The clever compilers can probably optimize both of them away, but isn’t it better for clarity if our syntax represents the logic we expect directly?

I would even argue that the discipline of naming intermediaries can make the code easier to read, as you never need to scroll up from a case to see what was initially matched on. So I’m going to continue experimenting with unifying conditionals entirely and leaving match out.

Or switch for those coming from algebraically deficient languages ↩
Some, including me when writing OCaml, even believe in matching on bools to eschew any use of if/else in the language. ↩
Of course in this particular monadic case we just match on Or_error.(f1 x >>= f2), but that might not be friendlier to newcomers and doesn’t always apply. ↩
I’m using Rust-like syntax here in place of the ML-like syntax in the paper, but otherwise retaining the constructs. ↩
At least outside of lazy languages like Haskell where short-circuiting can be replicated within normal operators. ↩
If I were a proper theorist here’s where I’d start defining judgements for this notion of bindings conditional upon being true, but I don’t want to scare anyone away with symbols. ↩
I do not mean to claim this as entirely novel, and I’ve seen discussions of logical or e.g. in Rust if not in UCS. ↩
Conditional on unifying the types of each pair of intersected bindings. and likewise has complications when intersections exist between its bindings. ↩
This has changed in OCaml 5, but the safety story isn’t as developed as Rust, leading to offshoots like OxCaml. ↩

The "Billion Dollar Mistake" Lives On in Rust

Tue, 17 Mar 2026 00:00:00 GMT

Tony Hoare famously calls the invention of NULL pointers to serve as a kind of universal empty or invalid value his “billion dollar mistake.” This unfortunate choice has since been reflected on by many modern languages, which have introduced various kinds of optionals to their type systems. These annotate when values may be absent and encourage programmers to handle that case gracefully. Some compilers even provide niche optimizations to make these zero-cost!

So, problem solved, right? Well, not so fast. I’ll argue here that the same mindset that infected so many early programming languages lives on, even in communities as focused on type safety as the Rustaceans are. To do that, let’s first talk about what exactly made NULL so insidious.

What’s Wrong With `NULL`?

You see, it’s not just the fact that you could produce undefined behavior by dereferencing *NULL in C, or that you’d hit NullPointerException calling methods on it in Java: the ability for code to fail by requiring valid data is alive and well in Rust’s unwrap, which panics upon encountering None. No, NULL’s true problem is much more sinister.

See, the issue with NULL is that it corrupts the type system: it is a valid value for any pointer type, no matter what sort of data that type is supposed to represent. In doing so, it makes it impossible to express the idea of a value that is guaranteed not to be in this problematic exceptional state. A type theorist would say that a type is the set of possible values it can take, and NULL was required to be placed in every set. By granting it this universal power we forced ourselves to constantly worry “could that be NULL?”

But gosh was it convenient: for any type, no matter how big or small, we had a way to express an empty, invalid, or uninitialized state. That’s super common to want to reason about, and it’s convenient for that not to require a wrapper which changes the type. Who hasn’t reached a point in Rust code where they knew their value would be Some - and wouldn’t just being able to use the value be more concise and no less safe than unwrap? Why would we have the function if those cases weren’t common?

Introducing `Default`

Well, some folks seem to have found a way to have their cake and eat it too. Allow me to introduce you to the Default trait:

pub trait Default: Sized {
    fn default() -> Self;
}

Seemingly innocuous enough, this trait consists of a single function which gives a sane default value for your type. E.g., Vec::default() will give us an empty vector. Don’t want to deal with the possibility your key isn’t present? Try map.entry().or_default().¹ Bored when initializing your long struct? Try

let x = Large { field1: a, field2: b, ..Default::default() }

My coworkers are even in the habit of checks like if x == Default::default() (literally using it as a kind of NULL-check like they might have in other languages). Note how Default::default(), like NULL, is a sort of universal value that works as a placeholder on any type (that implements Default, as most types are encouraged to²).

Is `Default` Better?

Default seems to have recovered some of NULL’s utility as an empty value that we can change to something substantive later, but without our big pain points:

It always gives a proper value of its type, and so can generally be used without just propagating failure like NullPointerException.
That means it has not introduced an additional value to types which implement it, so the types retain their expected set of possible values and we need not always check for a special case.

But if not a special value that’s a member of every type, then what value, pray tell, will be the default? Well let’s start with the simple case of integers. Their default value is zero. Is that sensible?

Well it would depend on the use.³ Integers are commonly used as counters, or to sum values, and zero is the additive identity, so in those cases it probably works well. But if you’re instead multiplying numbers, you’d probably want one as your identity, and if you’re not doing math at all, but recording some other metric with interesting meaning, maybe neither would be safe to use in general? However, since traits are defined uniquely per type, Default can never be specific to its situation and must attempt to capture all possible uses.

Is `Default` Worse?

It cannot really do that of course, and so often the most you can say about a default value is that it is a legal member of the type, and you’ll be tasked with turning it into something meaningful on your own. This is all to say, that often Default can take the place of uninitialized data: that which the programmer is required to overwrite later with something meaningful.⁴ And now just like with NULL, we have escaped the type system, which cannot hope to tell us whether we appropriately overwrote our default value, or whether it may still be lurking as garbage in any of our values.

In fact, I’d almost say this can be more dangerous. While NULLs were prone to fail fast and loudly, uninitialized values guaranteed to be valid are much sneakier: they can hide out in your codebase and function mostly adequately, until one day you discover your application logic’s output is subtly wrong. This is explicitly counter to Rust’s usual philosophy, exposing errors in the compiler if possible, or otherwise at least tending to panic loudly rather than permit undefined behavior. While no longer in the same form, Default has reintroduced semantically meaningless values that the type system cannot protect us from.

Takeaways

Using Default in Rust can genuinely make your code more concise and easier to write, which I do not mean to belittle. This is of course, not unlike NULL pointers in other languages. Nonetheless, outside of quick prototypes, most code is read many more times than it is written, and so the reader should usually be prioritized.

As a reader, when I see Default::default(), the main takeaway I get is that the writer didn’t care about the value it produces. If it were meaningful to the writer that the integer were zero, or that the set was empty, let alone any other less common type, they should have told me what that value is: if only because I might not have memorized what its default was.

Furthermore, I would generally argue that having data you don’t care about is an anti-pattern. If it’s in your code, it should mean something! So next time you’re initializing: consider being explicit, tell me what is the right default for you in your particular use case.

I’ve got a separate gripe that it’s not sufficiently explicit that this is a mutating operation, which inserts the result of Default::default() into map. ↩
There’s even a standard linter rule against types having a new() without implementing Default! ↩
So despite all my grumbling about entry().or_default(), I think something like Python’s defaultdict where you define a specific default value within some dictionary where you know its use is totally fine. ↩
It would of course be wrong to say they’re truly uninitialized as in C: the initialization is deterministic, just not set meaningfully by the programmer. ↩

joel.place

Can Anthropic Write Software?

Lamentations

Why I’m Surprised

Root Causes

Footnotes

A Path Not Taken for OxCaml

Modes

Modes & References

Modes & Traits

Default Modes

Portabilization

Portability Interoperability

Migration

Bifurcation

Another Path

Portability

Functions

Beyond

Footnotes

Dwarkesh, Lex, & Ezra

Interview Podcasts

Conversation

The Platonic Ideal

The Ezra Klein Show

Returning to Dwarkesh

Post-Penultimate Conditional Syntax

Prior Art

OCaml: Putting if in match

Rust: Putting match in if

Ultimate Conditional Syntax

Post-Penultimate Conditional Syntax

OR Patterns

Exhaustiveness

Putting It All Together

Concerns

Unsoundness

Ergonomics

Footnotes

The "Billion Dollar Mistake" Lives On in Rust

What’s Wrong With NULL?

Introducing Default

Is Default Better?

Is Default Worse?

Takeaways

Footnotes

OCaml: Putting `if` in `match`

Rust: Putting `match` in `if`

What’s Wrong With `NULL`?

Introducing `Default`

Is `Default` Better?

Is `Default` Worse?