The Zed Programming Language

Programming languages are hard. Very hard. I have built several of them. It's a fun academic challenge, but it's so utterly hard to get these things both designed right and built right that it's not a good task for the human brain, if you care about optimizing your language for multiple constraints simultaneously: correctness, completeness, robustness, generality, composability, scalability, practicality, ergonomics... This is why there are so many bad languages out there, and languages than never became more than a toy. AI is going to deliver programming languages that are dramatically better than what we have now, on every metric.

Thank you! I actually had agents (Claude, Gemini, and ChatGPT) all doing critiques, meta-critiques, reconciliation, and improvement cycles for about a week, 24/7, to polish out the spec, to cross-check everything, to split it into the tiniest of concrete tasks, and to schedule the tasks until they produced a family of something like 120 languages that were in a strict subset hierarchy, like Russian nesting dolls, and then I broke that out further into a DAG of tasks that needed doing -- in other words, I did an enormous amount of work (or my agents did) -- probably billions of tokens, just working on the implementation plan, before I had them write even a single line of code. Yes, it's important to have a good plan!

Originally: I conceived of it those 20 years ago as a way to fix all the issues I saw with existing programming languages. In particular, I have always been big on parallel and distributed computing, and when the multicore revolution kicked off in 2002, I started to get frustrated that all languages used only one core unless you jumped through hoops. That is still true of almost all languages today, and we have a lot more cores, and different types of cores (CPU/GPU and even FPGAs). I discovered that all computation is fundamentally DAG-structured, and I found the minimum set of necessary and sufficient constraints that you have to place on a programming language's syntax to ensure that the origin of all values could be known at compile-time, allowing the compiler to determine that the data dependency graph of the program is DAG-structured. (I had a patent on this but didn't pay the renewal fees so it has expired.) With that, the DAG becomes the parallel execution plan, because it is a partial ordering. That means you can parallelize optimally for any target architecture, up to the limit of parallelizability of the program. Since I figured that out, most of my design work has been on ergonomics: how do I make this the most powerful and fun language ever created? There are other goals: this compiles to native code only, there is no virtual machine -- and no garbage collector either. The DAG structure allows toy to also create precisely optimal automatic memory management. The design is also based on category theory, which is a very deep and powerful field of mathematics that describes how collections of values map onto each other. All this and much more coming soon(ish)... Anyway those were my early goals -- and also creating a language that was great for math, like Julia. However my goals have now changed: Zed is now going to become the absolute best language for an LLM to write code for. I want this to become the language of AI. There's a lot riding on that, and it's too much to describe here. But that's the new goal.

I have some very arduous requirements in place for all code generation by agents. First I did a deep review cycle with all of Claude, ChatGPT, and Gemini in deep research mode, asking them to research how to prompt LLMs to write good, correct Rust code first time. I then had Opus summarize all three reports into a set of guidelines. Steal these... github.com/lukehutch/skills/… Then I have a lot of requirements for the generated code: all code that is not O(1) must be immediately unit tested, but also benchmarked for scalability, and cannot run in more than O(n log n) time, unless there is a quadratic or greater number of data items to look at. This is necessary because I found that a LOT of generated Rust code uses inefficient data structures or algorithms right out of the gate... Often one order of complexity greater than is needed to solve the problem. Already it has fixed many dozen of these issues and it's only partway through the implementation. Trying to find and fix all these after this is fully implemented would be a crazy hard task, because they would all compound upon each other (the language is being built bottom up from the simplest syntax and features). Finally if there's a really hard problem that Opus doesn't know how to solve, it has instructions to spin up a cross-review cycle consisting of GOT Sol 6.1, Gemini 4 Argon, and Opus 5.5. All are given the task of solving the same problem, then they critique each other's answers, then their critiques are meta-critiqued (all 3 answers by all 3 agents), then their answers are combined into an attempt at a solution. That is tested, and then if it doesn't solve the problem, more cycles of cross-review are run. Also,once the entire codebase is built, I plan to run many cycles of whole-codebase review and improvement by all 3 leading LLMs individually, until convergence. So basically with this level of rigor, no, I don't plan to read the Rust code 😁

I'm building a new programming language, Zed (once it's released I'll be posting about it at @ZedLang). I have been working on this language for over 20 years, but never got it built, because the scope of it is so ambitious. It's an entirely new type of language based on category theory, with core design objectives of precise automatic parallelization up to the Amdahl limit; automatic memory management, with no GC and no need for manual malloc/free; and pervasive use of partial evaluation to increase the power of the language, among other very unique features, such as units (`accel = 5 with units("m s^-2")`) as part of the type system. I gave Opus 200 pages of design notes that I have been compiling over the last 20 years, and the code I had already written, and asked Opus to compile everything I have created so far into a single cohesive and detailed plan. Then I went through many rounds of cross-review between Claude, ChatGPT and Gemini, having them all do critical reviews, then meta-critique each other's critiques, then collaborate on combining their critiques into an improvement plan, until convergence. I also had the agents cross-check every part of the spec with every other part of the spec (all-pairs comparison) to check for inconsistencies, gaps in the spec, etc. Then I had the agents turn the spec into a long series of tiny incremental steps (a topological ordering of what has to be built before what), as well as the DAG-structuring of dependencies underlying the topological ordering. I then had Opus build a visualizer that shows me all the tasks in the DAG as my coding agents are working on each task, with realtime update as tasks change status (in progress / completed), which I highly recommend when you ask Opus to do some mammoth complex task, because you can see exactly what it's doing and when. It is absolutely magic to see this coming together before my eyes, and to see how Opus is handling this massive DAG of complex tasks and their interdependencies. It is crazy to me that Opus is now simply building what I have dreamed of and wished would exist for over 20 years, but never had enough waking hours to implement! I now have an army working for me, completing what I couldn't due to the bandwidth limitations of having just one brain, and 24 hours in a day. What a day of miracles we live in.