Jesus follower. Husband. Dad of 3 boys, 1 girl. Building Perry - TypeScript compiled to native binaries. No Electron. 🇩🇪
Breckerfeld, Germany
Joined January 2021
- Tweets6.7K
- Following1.8K
- Followers2.7K
- Likes18.3K
Pinned Tweet
Perry Update: I developed our own Regex engine. All alternatives did not work well with our GC and memory model.
Happy to announce Perex, now Perry's only regex engine:
• pauses at any step so our moving GC can run, then resumes
• never copies the string being searched
• no unsafe code, zero dependencies
• same results as V8 on all 47,658 Test262 pattern cases
cargo add perex
github.com/PerryTS/perex
New rule: every place an object is created is a “family” with a layout fixed at compile time. Objects are born with all their slots and never change shape.
Families that meet at the same access site agree on slot offsets.
So `o.x` is one load.
Honest scoreboard: 23 real programs (tsc, zod, effect, fastify, Next.js…), every one producing output identical to node.
tsc runs at 1.72× node instructions. fastify, qs, zod, and effect are still over 2×. Target: ≤2× everywhere.
2x target: Does this mean Perry is 2x slower than Nodejs? Nope! This is just the ceiling for EVERYTHING. So nothing Perry does will be slower than 2x, but in many many cases Perry is 10-100x as fast. So the 2x target is the target for the worst cases. Dynamic properties etc.
perryts.com
Is @TimSweeneyEpic vibe-coding now as well? 🤣
First Linus, now Tim ... the Anti-AI crowd should go crazy right now haha.
I started Perry after I was thinking exactly this.
Why bother with a neutral language and framework when agents do it all?
The reason is and stays: you still have to carry 2 codes. And agents don’t automatically make them any sync up.
Now you have to test both.
With a framework you outsource some of that trust.
Everyone is building a new TS compiler. But a TS compiler from TS to JS.
Without this recent hype it would have not even crossed my mind to make TSC a compile target / test target.
I want TS/JS to compile to binary and be freaking fast. Not a faster transpiler from TS to JS ....
For context, since a few people are suggesting projects: this is what I've been building with Perry. TS/JS→ native binary, no JS engine. perryts.com
Not to brag but Perry can actually do this quite well :)
New Perry version coming soon with details!
We’re likely going to do this because schema validation libraries are basically the worst case scenario for AOT performance without compiler integration
github.com/oven-sh/bun/issue…
Claude has a constant desire to "bisect" any problems or regressions.
I'm like: We have 100 moving parts here, please just find the problem "as is" and we'll just fix it.
10 minutes later we have a fix (as opposed to 2h later with "this and that commit did this")
amlug.eth retweeted
the coding agent haters are getting dunning-kruger'd so hard right now
do you really think that your engineering ability is better than the models at this point?
it is very very likely that fable is better than you in every branch of software
it has been trained on all the code of the internet, it knows almost every trick in the book, all the design patterns of every domain, every single low-level detail, every bit-twiddling hack, it's read every single blog post from every cracked engineer that ever existed
do you really think you can beat it? do you really think you can be more creative than it?
unless you are 99th percentile expert in some niche domain of software, it simply is not possible. sorry.
Low-latency somehow is my life's calling in tech lol.
A short backstory:
I first got into it in 2015 when I was hired to develop an "ultra-low-latency Wi-Fi sender/receiver". Written in pure C, at a driver level. This is way pre-AI, so this was freaking hard. But it was very good to learn about low latency and how computers actually work.
Then over the years, I got into finance and trading (blockchain). Again, low latency for first responses is key here.
The common theme from both above is: Every screw matters. You tighten one little screw, and it can change everything.
So then I started Perry, thinking, "oh nice, this does not require the same fine-tuning..." Haha, well, let me tell you: same thing again, every little screw matters.
Because the mission for Perry is not to simply compile JS/TS and have it work. It must compile and run it faster than everyone else across the board. Not just for each case, not just in benchmarks, but in actual programs.
Claude Code, OpenCode, Next.js, Zod etc., they all should work the best with Perry.
Unless AI gets really good at "guessing" changes without testing them, I don't see the assumption that clients _don't_ need everything not working out.
Unless of course, your repo contains a million other things that they don't need ... but that's a repo problem IMO.
For the last 12 months at least, I have had the majority of code written by AI. And AI has made great progress as well.
What I have noticed however, is that AI is not actually helping R&D as much as you'd think.
What I mean is this: AI will give you a perfectly fine opinion on something new. "Yes this will probably work" or "No, likely not."
To actually know whether or not it works, you will have to try it, though. And that's where you _still_ don't save that much time. The testing, acceptance, and development can be supported by AI in massive ways. But it still takes relatively long.
So, e.g., writing the code takes 1 - 2 h. But fine-tuning, testing and getting it actually there takes 1-2 weeks (still).
I want to know what this monorepo is for?
Or does Anthropic throw ALL their source code into one repo? If so, that sounds like a different problem to me.
New on our Engineering blog: Creating in-house source control.
In May, we merged around 2,500 code changes per day. In September, we merged more than 30,000 per day. As a result, we became bottlenecked by developer infrastructure built for human (rather than agent) scale.
Here, we share how we built a new version control system—and fully migrated our monorepo from git—in five months: anthropic.com/engineering/re…
Unpopular opinion: I don't think behavior with and around software will change all that much.
We, developers, will change _how_ we develop software. We already have. But the consumers will mostly stay the same and behave the same.
let me break down “software is dead” for you
the latest argument is “you just tell your agent what you want, and your agent will vibe code software on the fly to get that done, so no one will need real software any more”
sounds reasonable, until you realize it costs tokens, compute, and wall clock time to build those software on the fly
so instead of one-click launching an app, the bet is people will prefer to write a prompt, wait for 15 minutes, then get something that may or may not do what they want, and at the end of the month pay more $$$ for the token spend, higher than all their software combined
that’s literally the argument
and if we look at the world in aggregate, most people would just end up building the exact same “personal” software repeatedly
oh - your agent just spent 3 days and $500 of tokens vibe coding your terminal multiplexer? mine just did exactly the same! let’s celebrate how personal our terminal multiplexers are!
sorry - i just don’t see that as being a happy scenario for anyone, other than people who profit from telling others how to waste $ on tokens
to be constructive, here’s what i believe as the future state -
- high quality software that takes high cost to make will continue to thrive. just like good restaurants don’t compete with your air fryer and microwave
- most of those software will be offered headlessly for people to use via their agents, and they can continue to monetize such usage. this is already the case with products like jira, linear, stripe
- human-facing software will all offer dynamic UI that can be adjusted with natural language on the fly so they can be personalized easily, but their core doesn’t have to be rebuilt by every user repeatedly
instead of “software is dead”, i believe good software becomes “strong core, headless service, fluid interface”
which future do you think is more likely?