We moved off Cursor and onto Codex + Claude Code. Cost went from multiple thousand per engineer per month to about $500
2,126 karma · joined June 16, 2012
I think my architecture can be faster than tsgo albeit a much more painful codebase to work on. But I'm not claiming any sort of achievement yet.
Ultimately users have to decide and I have to show a very strong case that someone should use a nonofficial rewrite over Microsoft's own code.
Will tsz be a success? I am not sure. Am I learning and having fun? for sure!
Give each Codex an AgentName and ask them to mark their PR/issue/comments with those. Have one or two "managers" that manage PRs and overall project direction. I write the project directions and make long lasting issues. Each Codex session has an almost unachievable `/goal` but they are asked to achieve the goal by landing changes in `main` via PRs
I am running about 14 Codex sessions on 4 machines right now for about two weeks since OpenAI 10x'ed my 20x account and I simply can not run out of tokens fast enough.
Side note: I have multiple Claude accounts too but the new Claude Code `/goal` command is seriously broken. It waits long pauses between iterations and sometimes prematurely stops.
Compared to Codex CLI, Claude Code is insanely slow.
$ time claude --version
2.1.143 (Claude Code)
________________________________________________________
Executed in 4.39 secs fish external
usr time 29.68 millis 0.26 millis 29.41 millis
sys time 71.30 millis 1.30 millis 70.00 millis
I'm guessing Claude Code also needs a rewrite in Rust. But from what I saw in the leaked TypeScript code, a line-to-line port will be pretty bad. It requires a new architecture that matches Rust idioms
My goal with tsz is to make it practical and useful. I know how difficult it is to convince a tsc user to try something not officially from Microsoft
- Test before code, Bun had lots of test so that's good but maybe they could start by asking Mythos to write like 20k additional tests that pass on Zig Bun first.
- Deterministic anti-slop features. LLMs love to solve the problem in the wrong abstraction layer or place. There are many ways to catch this with deterministic tests. I do this in tsz a lot
- Roadmap that constantly evolving by humans.
- Taking a pause and looking how the progress is going and undoing slop
- Fuzztest(https://github.com/google/fuzztest) style "trying to break things" with the powers of LLM
The bar for matching tsc's behavior is really _really_ high. see:
https://github.com/type-challenges/type-challenges
I'm not against using LLMs to write a lot of code. But verification should be 100x more robust now that we can output code at this rate.
I'm convinced the future of writing code is heavily LLM assisted
[0] https://tsz.dev
[0] https://tsz.dev
a performance-first TypeScript checker written in Rust. Started 5 months ago and it's been mostly AI-written code. 99.8% tsc conformance test pass rate today. Single file benchmarks are 3–5x faster than tsgo.
Now that most of the implementation is nearly completed, I'm building a lot of instrumentations to have better visibility into those things to have concrete answers to that sort of question. I'm experiencing huge RSS right now that could be exactly what you're pointing to.
There has been attempts in the past (https://hegel.js.org) but I think TypeScript has been successful because it is prioritizing DX and ergonomics.
In the age of LLMs, the compiler can be a lot more strict. JSON.parse should not return `any` just to make developer happy and keep moving. It should be `unknown` and force the developer (LLM really) to do the hard work of writing down the type of what that JSON _could_ return. This is the philosophy of the Sound Mode in tsz. You'll get closer to Hegel ideals without making it impossible to write code and/or promising absolute soundness that JavaScript simply can't support.
It's much faster in single file benchmarks (3 to 5x)
https://tsz.dev/benchmarks/micro
I have optimizations planned for large projects that I'm still flushing out.
Example of a Claude Code session after 2 hours of "Crunching" that came out without results https://github.com/mohsen1/tsz/pull/4868 (Edit I force pushed to PR to solve the problem, you can see the initial refuse message in the initial version of PR description)
Funny thing is, the last percent of the test have been so hard to work on that Opus 4.7 routinely bails and says "it's too involved or complicated" so I had to add prompts specifically asking it not to bail.
Rust is perfect for writing all of code using LLM. It's strict type system makes is less likely to make very dumb mistakes that other languages might allow.
Also want to note that writing the code using LLM doesn't remove the need to have a vision for the design and tradeoffs you make as you build a project. So Jarred and his team are the right kind of people to be able to leverage LLMs to write huge amounts of code.
This blog was super insightful for me to understand what are the root problems in the current implementation though.