YT YouTube2Text

YouTube2Text → Transcripts → You can rewrite typescript in rust for $420k

You can rewrite typescript in rust for $420k — Transcript

by Theo - t3․gg · 9,890 words · 1,403 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Announcing TSC RS, aka TypeScript Rust,
0:03my complete rewrite of the TypeScript
0:05compiler, type checker, and LSP all in
0:09Rust. This is a project I've had agents
0:11working on for 5 months now. I burned
0:13$400,000 of Codex tokens and got
0:16nowhere. I burned $20,000 of Opus 5.5
0:19and I got there in 2 weeks. Important
0:21note,
0:23I have not read a single line of code.
0:26If you've been around for a bit, you
0:27probably know I've been using this
0:28TypeScript Rust rewrite as my favorite
0:30little playground for trying out new
0:31models and seeing where capabilities are
0:33going. I did that because I was looking
0:35for things that just seemed impossible
0:37for the models to do. The reason I first
0:38started the TypeScript Rust project was
0:40because I had a crazy amount of
0:42inference with the early access testing
0:43for GPT 5.6 Soul and it was crushing
0:46everything I threw at it. So, I decided
0:48to reach for something a bit bolder. Not
0:50a bit bolder, like just impossible. It
0:52didn't seem viable to just rewrite all
0:54of TypeScript in Rust. It seemed like a
0:56meme.
0:57And it was. The furthest I got using
0:59OpenAI models was roughly 84%
1:01compatibility. And while like impressive
1:04that it could get that far, didn't
1:06really seem like it was going to get
1:07much further because at that point the
1:09last 16% is way harder and as you get
1:11closer and closer the edges that are
1:13left get worse and worse. Which is why
1:15it feels extra insane that not only is
1:17TS Rust now out and available for people
1:19to use with a real package on NPM, more
1:22importantly, it's way faster. When
1:25compared to TypeScript V6, which was the
1:27last version written in TypeScript and
1:28JavaScript itself, it is 12.5 times
1:31faster. When compared to TS Go, which is
1:34TypeScript V7, the version that the
1:36official folks at Microsoft built, it's
1:38around two times faster. We're not the
1:40only ones who did this. Bun also dropped
1:42Bun Check, which is a rewrite of the
1:44TypeScript checker in Rust that is also
1:47way faster and I'll be real, is even
1:49faster than what we built with TS Rust.
1:52But there are catches to all of this.
1:54From how I built it to how I verified it
1:56to the secret reasons I actually wanted
1:58this to exist, which believe it or not
2:00aren't just RAM usage and how long it
2:03takes to run. I have one very
2:05interesting secret reason I wanted to
2:06build this. And I actually have a demo
2:08of it working now. This little vibe
2:10coding demo here is a lot cooler than it
2:13might seem initially. I want to talk
2:15about all of this, from how much it cost
2:17to how it worked to why I care so much
2:19about this project and most importantly,
2:22what does this mean for engineering
2:23going forward? But after burning
2:24$420,000
2:26of tokens, I hope you can forgive me for
2:28a real quick break for today's sponsor.
2:29How the heck did we get here? AI models
2:31are capable of rewriting pretty much any
2:33piece of software from scratch in
2:34whatever language you want, but trying
2:36to find the right three rows in your
2:37database using an agent is it nearly
2:39impossible. Once the data isn't
2:41perfectly structured and doesn't have
2:43the exact keyword the model's looking
2:44for, it's not going to find it. This is
2:46why good vector search and retrieval
2:47systems are so important. And today's
2:49sponsor Quadrant has it absolutely
2:51figured out. I'm going to quickly
2:52mention two things to make the haters go
2:53away. It's fully open source and also
2:56written in Rust. You can use the cloud
2:57if you want or you can self-host, both
2:59are incredible. My team's been using the
3:00cloud version a bunch and the things
3:01we've been building are genuinely super
3:03useful. For example, let's look for
3:05videos where I talk about my agent MD.
3:07When I do basic keyword search, I get 10
3:09results that aren't really good fits for
3:12what I was looking for.
3:13But on Quadrant, I'm getting ranked
3:15results based on how well my question
3:17actually matches the content. And
3:19obviously, the video on the right here
3:20is a much better fit than the one on the
3:22left. I can even get more vague and
3:23search for something like anti-clod. And
3:25what's funny here is the video that was
3:27recommended on the left is the same as
3:29before cuz this is basic keyword search
3:31like what your agency by default. On the
3:33right with the vector search, we get
3:35videos that are very much me being
3:37anti-entropic. I didn't plan this one
3:39ahead. I did not think this gap was
3:40going to be so big. That's hilarious.
3:42The more vague the query, the more
3:43valuable it is. For example, I can have
3:45it go through all of my issues and PRs
3:47on GitHub for T3 Code and ask something
3:49vague like T3 Code is making my whole
3:51Windows PC lag even when it's sitting
3:53idle. I fire this, I get no results from
3:55the keyword search, and I get eight
3:57relevant results from Quadrant. This
3:58makes deduplicating and finding similar
4:00issues so much easier. We're even using
4:02it now to index all the faces I use in
4:03my thumbnails. I can search for
4:05shrugging with both hands out and
4:07immediately get results that are good
4:09matches for that request. Or I can
4:11search something like angry and get all
4:13of the thumbnails where I looked kind of
4:14mad. There's a reason companies like
4:15Canva, Discord, and more have been
4:17moving to Quadrant. Give your agents
4:18search that feels magical at
4:20swiy.io/quadrant.
4:21I'm going to do everything in my power
4:23to not make this video 2 to 4 hours
4:26long, which is tough because I have so
4:28much to say about this. But, I think we
4:31should do a brief history lesson to
4:33explain what this is and why it exists.
4:35TypeScript is a language, kind of.
4:38The point of TypeScript is to build a
4:39system on top of JavaScript so that we
4:41can have more confidence about the
4:43behaviors of our JavaScript apps. The
4:45main thing that we're talking about
4:46today is TSC, the TypeScript compiler.
4:49The point of the TypeScript compiler is,
4:51of course, to turn the TypeScript that
4:53is in your editor into JavaScript that
4:55your browser can run because your
4:56browser doesn't know how to deal with
4:57TypeScript. If you have a function like
4:59function user name string,
5:03console.log
5:05user.name, wow, we're writing code. Such
5:08advanced stuff. Been a while, right,
5:09guys? Wait, there's even a code button
5:11there. Look at that. If you took this
5:13function and ran it in Chrome or Node or
5:16any other JavaScript runtime, it will
5:18immediately fail an error because the
5:21syntax for the type definition here,
5:22where I describe user as a parameter
5:25that is of type object with a name key
5:27that's a string, this is not valid
5:29JavaScript syntax. You can't just do
5:31this there. Also, the function needs a
5:33name, so log user. You get the idea
5:36though. This would not be valid
5:38JavaScript because of this guy here.
5:40Turning this into valid JavaScript is
5:42actually quite easy. You can go through
5:45and trim out all of the TypeScript-isms
5:48in the JavaScript code. And once you've
5:49done that, you can just run it and it
5:51works. So, the first important thing to
5:54understand here,
5:55turning TypeScript files into JS files
5:57is easy, borderline trivial. And there
6:00have been lots of cool tools doing this
6:02for a while now. In particular, one blew
6:05up a few years ago and kind of changed
6:06how we think about web dev, esbuild.
6:09esbuild was built by Evan W, who was the
6:12CTO of Figma, because he wanted to make
6:14it faster to get updates when you change
6:16files in your editor to see them in your
6:18UI. And running all of your code through
6:21JavaScript just to remove some things
6:22from it so you can put it in the browser
6:24was not efficient. So, esbuild was built
6:26to do a lot of those steps, not just the
6:28turning TypeScript to JavaScript, but
6:30also a lot of the other steps, like
6:33bundling in the CSS, creating the other
6:35assets needed, turning it all into one
6:37file the browser could actually receive
6:38instead of all of these files scattered
6:39around your code base. All the things
6:41you need to bundle the app to get it
6:43ready for your browser, written in Go so
6:46that it could be as efficient as
6:48possible, reasonably, without having to
6:50like reinvent the universe and manage
6:51all your memory yourself. And esbuild
6:53was incredible, but it was missing
6:55something. We're just talking about
6:56turning TypeScript into JavaScript.
6:58That's an easy part. The actual hard
7:00part is checking the TypeScript, making
7:02sure the types are valid and being used
7:05and honored correctly throughout your
7:06application. I'm going to be so real
7:08with y'all, doing the transpilation,
7:10turning TS into JS, was so easy that
7:13even just doing it in JS wasn't that big
7:15of a deal. Checking the TypeScript to
7:17make sure it's correct, way harder and
7:20also way slower. This ended up being
7:22where most of the time was spent. As a
7:24result of this, the maintainers of lots
7:26of big code bases split their
7:28transpilation and type checking
7:29compilation paths separately. I remember
7:32how bad the hot reloading was initially
7:33at Twitch. I would run the dev command,
7:35it would take 2 minutes to start up, and
7:37then I would go and edit a file, save,
7:38and it would take 30 seconds to a minute
7:40to appear in the browser. I was so hyped
7:42that we got it under 5 seconds by making
7:44it so the path that puts it in the
7:46browser is separate from the path that
7:48is type checking the code to make sure
7:50it's correct in its type definitions.
7:53Something like ESBuild that you go even
7:54further for those hot reloads from
7:56saving to seeing it in the browser, but
7:58it doesn't give you enough info to know
7:59something like did the types check
8:01correctly? And as you've probably seen
8:03if you've watched my old videos, the
8:04TypeScript type system is incredibly
8:06complex and flexible. It's a Turing
8:08complete system. Here's a fun throwback.
8:10One of my friends actually ported all of
8:13Doom into TypeScript's types. Not
8:15TypeScript the language, TypeScript the
8:17type system. Insane project. Highly
8:19recommend watching that video if you
8:21haven't seen it before. The point I try
8:22to make here is that TypeScript's type
8:24system is complex. And it's complex
8:27because it can represent all the things
8:28you do in JS. Therefore, rewriting the
8:31checker in a non-JavaScript language
8:33would inherently suck because of all the
8:36weird things that JavaScript does
8:38inherently. Like the way you can change
8:40what variables types are as you execute
8:42your code. The way that objects inherit
8:45traits and the way all of the
8:47prototyping systems work. And all the
8:49the weirdness of JavaScript that
8:51TypeScript faithfully encodes is a lot
8:53easier to encode when the language
8:55encoding it is the same language as the
8:57one you're encoding. A sillier way to
8:59explain this is that it's much easier to
9:01explain how English works in English
9:03than it would be to explain how English
9:04works in Spanish. Just imagine that
9:06complexity but like times a hundred.
9:08That's what makes this so hard is all
9:10the weirdness of JS has to be encoded
9:11faithfully in whatever thing you choose
9:13instead. But that was not enough to stop
9:16Microsoft. Which is why Microsoft
9:18decided to rewrite TSC. They wanted it
9:21to be native and super fast to make
9:23these compilation and type check times
9:25way better, which is why they picked Go.
9:27You might be confused. In fact, I'll
9:29switch over to chat and see how people
9:31feel about their choice for Go. What
9:33language do you guys think they they
9:35have chosen? Jai, C++, C#, C# is a funny
9:39one cuz the creator of TypeScript is
9:40also the creator of C#. I have the hot
9:42take
9:43that Go is the right language for this.
9:47I know everybody else has opinions, but
9:48let me explain why. I recently got
9:51dunked on for these tweets, and I think
9:53they're relevant here more than ever. I
9:54posted in February of 2024,
9:57"Go is probably the right language for
9:59most JavaScript build and dev tooling."
10:02I followed up with the following,
10:03"Tweeting this now for reference in 3
10:05years when we realize we up going
10:07all in on Rust." This take aged poorly,
10:10but not for the right reasons. I need to
10:13explain the Go one first because this
10:15almost directly contradicts with my
10:16other takes on Go. For example, here
10:19where I'm making fun of Melkey saying,
10:21"I suddenly understand why you think Go
10:22is a good language." I'm notoriously a
10:24Go hater. I just never liked the
10:27language much. I I get where it's
10:29benefits are. I just makes you feel like
10:31a monkey more than an engineer from
10:32being real. So, why did Go make sense
10:35here? Go's biggest strengths compared to
10:38something like Rust are its flexibility
10:41because it's not trying anywhere near as
10:42hard to be like super type-safe and
10:44memory-safe. It's type system's a
10:45meme. It's concurrency stuff
10:48built in is awesome. Like Go's
10:49concurrency model has its issues like
10:51channels are stupid, but the like core
10:53parts in Go routines, there's some
10:55really cool stuff in there. And
10:57concurrency is one of the big things
10:58that the team wanted with the TypeScript
11:00rewrite so that they could take more
11:01advantage of your cores. Its syntax was
11:03surprisingly similar to JS which made it
11:05easier to look at two functions from one
11:07in the other and understand what they're
11:09doing. But, I would argue the biggest
11:10piece, garbage collection.
11:13Garbage collection is one of the flaws
11:14in Go because it means that your memory
11:16isn't being managed by you, and at some
11:18point it has to be cleaned up, which
11:20means that the performance
11:21characteristics of your app are not
11:23reliable. Usually, it will respond to a
11:25request pretty fast, but sometimes if
11:27that request comes in when you happen to
11:29be out of memory and need to do garbage
11:30collection, then you'll have these
11:32random latency spikes that suck. The
11:34benefit is that you get crazy
11:35concurrency and you have to think about
11:37memory constantly at the cost of garbage
11:40collection causing your latency to
11:42spike. So, if you have a system that you
11:44care a lot about and like you want to
11:45make sure every request is resolved in
11:47under 25 milliseconds, Go might not be
11:49the right language because sometimes it
11:51will have to garbage collect and it will
11:53hold off on executing code until that
11:55garbage collection passes done. To be
11:56clear here, JavaScript and TypeScript,
11:59those are garbage collected as well. Go
12:01is an interesting language because it's
12:02both low-level and garbage collected.
12:05So, why would you ever want to use this
12:07for a compiler then? Isn't that going to
12:08be super slow? No. If you have 100,000
12:12requests that all come in at 25
12:13milliseconds, and then you have to do
12:15GC, and the 1,001st request comes in at
12:18300 milliseconds instead, that seems
12:21horrible because that one request is now
12:2410 plus times slower than all the other
12:26requests were. But if one out of a
12:27thousand requests is 10 times slower,
12:30the total time is like less than 1%
12:32slower. It's nothing. The impact of
12:34garbage collection on the scale of a
12:36long process with lots of things in it
12:38is much less than when you're timing
12:40each individual request. So, if you're
12:42doing work that you want to have resolve
12:44in milliseconds, a garbage collecting
12:46language will have flaws you should work
12:48around. But if your average request is
12:50going to take more than 100
12:51milliseconds, like I don't know,
12:54multiple seconds cuz you're compiling a
12:55giant app, I don't care if you garbage
12:57collect one, two, three, 10, 100 times
12:59during that request because the garbage
13:00collection is going to make up such a
13:01small percentage of the runtime, it
13:03barely matters. It washes out. So, if I
13:05was building a web service I wanted to
13:06have respond as quickly as possible, Go
13:08is not the right language. But if I'm
13:10trying to take something written in
13:11JavaScript that's really slow that takes
13:13minutes to run and shave the time down
13:15and get more concurrency, Go is one of
13:17the best languages to do this with. But
13:19it couldn't have been too hard to do the
13:21Rust thing, right? Cuz you had an agent
13:22do it in 2 weeks. Now, I would like to
13:25introduce TS Rust. Writing all of
13:27TypeScript from JS to Rust would not
13:30have been viable. I know this to be the
13:31case because of how much the other
13:33models I tried, like 5 6 Soul and Astra,
13:36struggled with this port. I think a lot
13:38of that was because going from
13:39JavaScript to Rust is not trivial with
13:41things as complex as TypeScript itself.
13:44And this is where things start to get
13:45interesting with my TS Rust port. We hop
13:47into the crates, a lot of things were
13:50done, many of which are uh I think
13:52questionable is a fair word for it.
13:54One of those things is this.
13:57Go STD. This is the standard library
13:59from Go
14:01ported to Rust. Because the way Opus
14:03chose to do this wasn't to rewrite
14:07things from Go to Rust. It was to go
14:10through this Go port line by
14:12line and faithfully port it over to the
14:15Rust language. And the result of this
14:18was actually quite a bit slower than the
14:19Go version because when you have to
14:21re-implement things like Go routines,
14:23which is in here somewhere, I have
14:25forgot which it's in. I think it's in
14:27the runtime RS, yeah. Runtime RS. This
14:29is Go routines ported to Rust.
14:34This happened because Go was a much
14:36better starting point for a Rust port
14:38than JavaScript is. The Microsoft team
14:41faithfully by hand went through every
14:43line of code in TypeScript, ported it to
14:45Go, and then started refining it to make
14:47it better and faster in Go. My agents
14:49did the same thing from the Go version
14:51to Rust, and they succeeded. I didn't
14:54even know that my agents had done this
14:55until somebody else pointed it out on
14:56Twitter. And as soon as I saw that I was
14:58like, "Oh, that's hilarious. That
14:59explains a lot." Because again, when TS
15:01Go RS was ready for its first run when
15:04Opus finished, it was two to three times
15:05slower than the Go version. So, I told
15:07it in a slash goal, "Your objective is
15:10to make it at least two times faster in
15:12every way." And then I let it run for 2
15:14weeks.
15:15More importantly,
15:16I let it run on my six Claude accounts.
15:19All of the work done in TS Rust with
15:21Opus 5 5, which effectively gave up on
15:23the old version and restarted, was
15:25roughly $24,000
15:27of inference if I had paid full API
15:29prices. But as you know, I didn't
15:31because I have subscriptions. So I also
15:33tried pricing it out using all my logs
15:35to see how much of my utilization went
15:37to this. The equivalent in your sub
15:40usage for all the work I did here was
15:42between 925% and 983% of one account's
15:45weekly limit, which means about 2 and
15:471/2 months of usage on a Claude sub.
15:50When you consider that we got a free
15:52reset, this ends up being about 500-ish
15:54dollars give or take of subscription
15:57usage. And at that price this is
15:59actually a good value to have built. I
16:01know it sounds insane, but $500 to have
16:04TypeScript in Rust, which is more memory
16:06efficient and faster, 2x faster than the
16:08Go version, is genuinely super useful.
16:10And I am To me, this is money well
16:12spent. I know that seems insane because
16:14the 20,000 or the $420,000 headline
16:17number sounds crazy, but with the
16:18subsidization from a subscription and
16:20the fact that only the 20K of Claude
16:21mattered, this being 10 weeklies of
16:24usage is just uh hilariously good value
16:26in my opinion. So if you were thinking,
16:27"Man, the Microsoft TypeScript team
16:29wasted so much money and time porting to
16:31Go, they could have just waited and let
16:33AI do it in Rust." No, I don't think the
16:35AI would have done this viably from
16:37JavaScript and TypeScript to Rust, but
16:39it was able to do it with Go relatively
16:41trivially. And the result is a pretty
16:44much 100% drop-in replacement for TS Go
16:48and TSC 7. I know that for a very silly
16:51reason, the issues. There were five,
16:53there are now four. I audited these
16:55issues. Well, my agent and I audited
16:57these issues. And of the six issues that
16:59have been opened total so far, one of
17:02them was specific to TS Rust. The other
17:05five issues were problems that exist in
17:08TSC 7, the specific version that we were
17:10targeting. So these aren't things that
17:11are wrong with the rewrite, these are
17:14bugs in TypeScript itself currently that
17:16were faithfully ported to my rust
17:18version. And I think that is hilarious
17:20that not only did I port the intentional
17:21things, I ported the bugs, too. Because
17:23this truly is a fully compatible drop-in
17:26replacement. I suppose now it would be a
17:28good time to talk about the resulting
17:30performance. Since I started this before
17:32Bun check was even a thought from Jared,
17:34I was initially running all my numbers
17:35against TypeScript 7. And for real-world
17:38projects like T3 Code, we saw a 2x
17:41improvement from TS7, which is TS Go,
17:43and as much as a 20x improvement on
17:45various things for TSC 6, which was the
17:47last TypeScript JavaScript-based TSC. I
17:49started with the T3 Code checks because
17:51I did something fun here. One of the
17:52things Affect TS does, and if you're not
17:54familiar, Affect is a popular library in
17:55TypeScript to make building reliable
17:58concurrent systems more viable and
18:00composable as well. Affect uses and
18:03abuses TypeScript so heavily that
18:04they've actually built their own fork of
18:07TypeScript effectively. It's a patch you
18:09apply to your TypeScript config and your
18:11TypeScript like package in your repo to
18:13get more diagnostic and features from
18:16Affect into the type checking. I built
18:18that directly into TS Rust because we
18:20rely on this a lot for things like T3
18:22Code. So, for our use case in T3 Code,
18:25not only are we way faster than TS7 with
18:29Affect's TS Go plugin, we're actually
18:31way faster, like four-ish times faster
18:34than Bun as well. Not because Bun check
18:36is slower, Bun check is super fast, but
18:37because we have to do the Affect check
18:40on top of it after. And as soon as
18:41you're doing both, it just ends up way
18:43slower end-to-end. But this is just
18:44checking in T3 Code. Let's check other
18:46projects, some real simple things like,
18:49I don't know, the entirety of tRPC
18:50server or Sentry's code base or
18:54Excalidraw. And funny enough, I was
18:56checking Affect as well. I actually
18:57think Bun couldn't pass on the Affect
18:59code base, if I recall. Bun also raised
19:02incorrect errors on Sentry and tRPC. So,
19:05the Bun checker, while incredibly
19:07impressive and faster in a lot of cases,
19:09does not have faithful enough checking
19:11for me to trust it in these types of big
19:13projects. I think Bun check fits well
19:15with like the other Bun tools in that
19:17like if you start a new project with Bun
19:19and you use it for everything, Bun check
19:20is a great solution. I actually honestly
19:22would recommend Bun check over TS Rust
19:24for almost everything simply because I
19:26have higher faith it'll be maintained,
19:27but TSCRS, my project TS Rust, is a way
19:30more faithful recreation and as a result
19:32it does not get weird errors in these
19:34projects. It works faithfully in
19:36projects like tRPC, in projects like T3
19:39code, in projects like the effect repo
19:41itself. And the improvements we see here
19:43for most of this stuff is 13x plus for
19:47going from TSC 6 to TSCRS. And it's
19:50usually a 2x improvement from the go
19:52version. But ready for the spicy take
19:54that's going to make all of this way
19:55more confusing?
19:57I didn't do this for performance. I did
19:59not make TypeScript Rust because I
20:00wanted something faster than TypeScript
20:02go. So why did I do this? There is the
20:05silly reason and then the potentially
20:07groundbreaking one, and I'm going to
20:09start with the silly one. The silly
20:10reason is because LLMs couldn't do it.
20:13Models were not able to make these types
20:14of ports. It had become a meme. I got in
20:16flame wars with people for claiming they
20:17would be able to port TypeScript to like
20:19C++ and things in a month, which just
20:22obviously you couldn't do, and I got in
20:24a flame war with somebody, ended up
20:25getting blocked by them. It was a hit
20:27show. This is like back like the old
20:282020s, like early days of TypeScript
20:32posting on Twitter before AI took
20:33over all of it. And I was getting in
20:35like heated fights about these things
20:36because it was obvious you couldn't just
20:38rewrite TypeScript in another language,
20:40which is why it was always my like reach
20:43goal, the impossible thing that like you
20:45could never actually have, the
20:46unobtainium to an extent in the web dev
20:48world. And as such, it was a fun thing
20:50to throw practically unlimited tokens
20:52at. I had never tried any Anthropic
20:54model on this task because they would
20:55burn my usage too fast, but with Opus
20:575.5, usage was burning so slowly and I
21:00had so much, I said it, let's see
21:01what happens. And it was able to do it
21:04way more effectively than I ever could
21:05have guessed. I did it because I didn't
21:07think models could and now that they
21:09can, I'm running out of things to throw
21:11the LLMs at. Like, I don't know what
21:13tasks an LLM would ever be able to do
21:16that are impossible for them now, but
21:18could be possible in the future. It's
21:19like hard for me to comprehend. Like, I
21:21am out of engineering ideas that are
21:23like too much for the model. This was my
21:25too much for the model and now it's done
21:27it. But, what's the real reason? What
21:29reason did I have to want a Rust-based
21:33version of TypeScript when we already
21:35had a super fast Go one? I got almost
21:37everything I wanted out of TS Go. Why
21:39did I want something else? There are
21:41small things like I wanted the effect
21:42stuff built in. I wanted it to be a
21:44little easier to extend and play around
21:46with. But, the main reason
21:48little thing called WASM. This goes back
21:51to the garbage collection bit we talked
21:52about before. Garbage collection is an
21:54incredible way to take a burden off of
21:57engineers to allow them to ship software
21:59faster that is still really fast. But,
22:01since garbage collection is a complex
22:04process that requires you to analyze
22:06memory and do a lot of memory management
22:08stuff, taking a Go app and bundling it
22:10into WebAssembly is not trivial because
22:12you can't just bundle the code the
22:14developer wrote. You also have to bundle
22:16all of the garbage collection. The end
22:19result here is that it's pretty
22:20difficult to write a Go app and then
22:23bundle it as WASM less than 10 megs and
22:26it's still going to have lots of weird
22:27performance issues because of that
22:29garbage collection aspect of it. This is
22:31why tools like ESBuild struggled to get
22:33WASM working for so long. This is also
22:35one of the things we lost with
22:37TypeScript Go. Previously, since
22:39TypeScript was all just JS in the end,
22:41you could throw it in the browser. You
22:42could throw it in a V8 isolate. You
22:44could run it in Node and it just worked.
22:46With TS Go, we kind of lost that. In
22:49fact, we lost a lot of the JavaScript
22:50APIs we used to interface with
22:52TypeScript compiler in the past. Why do
22:54I care that much though? We're all
22:55running a region on our computers or
22:56someone else's computer, right? What if
22:58we're not in the future? Intelligence is
23:00expensive. People like Lauren, aka
23:02potato at cursor and SpaceX, are
23:05spending allegedly $132 million a year.
23:07This number's and I'll
23:08explain why in that other video.
23:10Subscribe if you haven't, by the way.
23:11That red button helps us a ton. And
23:13you'll get to be around for
23:15this rant, which will be fun. Ignoring
23:17the fact that those numbers aren't real,
23:19the rate at which prices go down is
23:21real. Flashbang warning for artificial
23:23analysis. I need to port this particular
23:25bench over and I haven't yet. This is
23:27the cost efficiency over time chart from
23:30artificial analysis. This takes a given
23:32score that models could get. So, like
23:34DeepSeek-R1 getting a score above a 10
23:37on their index in January 2025. And it
23:40tracks how much the price for models of
23:43that level of intelligence goes up or
23:44down over time. Where things get really
23:46crazy is all the way over here on the
23:48right, where we see models that are
23:49super smart, like Opus 5, which broke
23:52into the 50-point range for the first
23:55time, costing $5.86 per task when they
23:57ran it. And now we have models like 61
24:00Soul that got the same score for 32
24:02cents. So, it's already decreased by 10x
24:05in cost for that level of intelligence
24:07in just like 4 months. At a given level
24:10of intelligence, cost goes down absurdly
24:13fast. Like, 10x a year is a conservative
24:16estimate here. If you take the 30-point
24:18range, which cost $2.50
24:21in February of this year and got down to
24:233 cents by December of this year, that
24:26is 8x per month decrease, averaging out
24:29to 1,000x a year annualized. The rate at
24:32which prices for intelligence goes down
24:34is insane. But, intelligence isn't the
24:36only thing we're paying for. When you're
24:38building apps with AI, you also have to
24:40pay to host it. You have to pay to store
24:42the data in the database. You have to
24:43pay for whatever like off systems and
24:45providers you're doing. You have to pay
24:46Apple to distribute the app. You have to
24:47pay for all these other things. But,
24:48there's one more thing you have to pay
24:50for that people don't think about a lot.
24:52You got to pay for the compute that your
24:53agent runs on.
24:54If you're one of those $5 VPS bros,
24:57now's your time to shine because we
24:58actually need to talk. One of the
25:00[snorts] cool things Cursor does right
25:02now is the Cursor Cloud. When you spin
25:04up a cloud thread in Cursor, it will run
25:06on a full VM with 32 gigs of RAM, I
25:09think. It might be 16. I'm pretty sure
25:10it's 32. In Cursor's Cloud with a real
25:13GUI, real processor, real everything it
25:15needs in Linux, so that it can spin up
25:17your app and test it with a real
25:18computer. Every thread gets its own
25:20computer. You spin up four threads,
25:22that's 128 gigs of RAM reserved to you
25:24for that day. And right now, Cursor
25:26doesn't charge for that. So, the problem
25:28now is that your inference is way more
25:30expensive than the VMs, to the point
25:32where the VMs are almost a rounding
25:34error, which is why giving you those
25:36free VMs is not really a big cost. But,
25:39remember what I just said?
25:40The cost of inference is going down, and
25:43it's going down rapidly. What about the
25:45cost of compute? What about the cost of
25:47VMs? See where I'm going here? The cost
25:50of renting a 16 or 32 gig box is going
25:54up steadily thanks to AI sweeping all
25:57the demand for RAM. The result is that
26:00VMs and compute that you want to run
26:01your agents on, not the compute running
26:03the models, the compute running the code
26:05that the model's editing. That compute
26:07has been slowly going up in price over
26:09time, but the inference compute is
26:11plummeting in price.
26:13So, one of these things goes up by 25 to
26:1630% every year, the other goes down by
26:1910 to 100x every year. We're going to
26:21quickly get to a point where inference
26:23is cheaper than the VM. With a model
26:25like GLM 53 Flash, running it for an
26:28hour straight is going to cost you a few
26:30dollars. The VM it's running on is
26:33likely more expensive than the model in
26:36the inference you're doing in that
26:37window. And as models of that price get
26:39smarter, and as models at that tier get
26:42cheaper, this will be hit quickly. At
26:44which point, compute will be a
26:46constraint for when we're building with
26:48agents. Right now, we're being given the
26:49VMs for free, but that is not going to
26:52last. Even Cloud Code isn't doing this
26:53anymore. Cloud Code now gives every
26:55subscriber a credit that they can use
26:58towards the cloud compute that they use
26:59if they use Cloud's cloud product.
27:01There's a lot of layers to why it works
27:03this way. The compute and the memory are
27:05expensive, so they have to like worry
27:07about that. The reason that they have to
27:08be reserved this way is because of how
27:10our agents work. Our agents expect to
27:13run on a real computer with a real
27:15terminal with real bash so that it can
27:17run commands, it can run rip grep, it
27:19can search through the code base and
27:21find things. It expects to have native
27:23tools for editing, for checking how much
27:24CPU is being used, for searching for
27:26files, for moving files, for running get
27:28commands, for all these things. Our
27:30agents expect and are trained on real
27:33Linux boxes or Mac or whatever else.
27:35They're trained for real systems that
27:38they can do things on. And surely you
27:40can sandbox them some amount, but all of
27:42those additional layers cost additional
27:44resources. Sandboxing harder is not
27:47going to make the compute cheaper, if
27:49anything it's going to make the compute
27:50and the memory more expensive. Which
27:52means we need a better abstraction
27:54layer. Ideally, in a future where agents
27:56are cheap and writing code is incredibly
27:59cheap because the models and inference
28:00have gotten so cheap, the thing that
28:01they write them on and to test them on
28:04should not be this expensive.
28:06Thankfully, this is a thing we have
28:07explored for a very, very long time in
28:09the industry. And this is a word you
28:11guys have heard from here.
28:13And we get to revisit an old war that we
28:15have not talked about in a while. We get
28:17to talk about big orange.
28:19Cloudflare. What is the word that y'all
28:23associate most with Cloudflare? Spam me
28:26chat. When you think Cloudflare, what do
28:28you think? Cost, cheap, free, cheap.
28:31There's like cloud and CDN. Most of them
28:34here are free, cheap, cost related. A
28:38lot of what people associate with
28:39Cloudflare is cheapness. The reason for
28:42that is how Cloudflare's platform works.
28:45When I write code for a back end and I
28:48host it on Cloudflare, I'm not wrapping
28:50it in a Docker image that they deploy on
28:52a server. In fact, when I put code on
28:54Cloudflare, it's not deployed. It's not
28:56running. It runs when a request comes
28:58in. The request triggers Cloudflare to
29:01spin up a worker. A worker is an
29:03isolated JS process inside of V8, the
29:06JavaScript engine powering Chrome and a
29:08lot of other things. And that isolate is
29:10in the kernel. It's not Linux. It's not
29:11an OS. It is a isolated execution layer
29:15where your browser or whatever else can
29:18execute JavaScript. This is really
29:20useful in browsers because you can have
29:22different tabs doing different things
29:24and not have access to each other's
29:25stuff. Or you can have one tab with four
29:27things running in it that are different
29:29that can communicate with each other but
29:30not interfere with each other. V8's
29:32isolation layer is incredibly powerful.
29:34It's not the most secure thing, but it's
29:36pretty secure. And what Cloudflare has
29:37done is taken those isolates, made them
29:39as secure as possible, so that when a
29:42user goes to a website you built and
29:44deployed on Cloudflare, it can grab that
29:46code from storage, throw it on this
29:49isolate that's just sitting there
29:50waiting, execute it, then kill it. So,
29:52on a platform like a Vercel or Heroku or
29:55Hetzner or any other traditional host,
29:57if you and I both host an app on that
29:59platform, we both have our own Linux
30:01instance effectively that is running
30:02with our code in it. On Cloudflare, your
30:05code and my code are executing in the
30:07same instance of Linux, just split
30:10higher up in the V8 layer instead of
30:12with VMs and Docker. Hopefully this all
30:14makes sense. If it doesn't, ask your
30:16agent. I'm not going to keep ranting
30:17about this. I've talked about this in a
30:18lot of my videos before. There are
30:20problems with this model, though. If
30:22we're running inside of a JavaScript
30:23isolate, we lose a lot of things. Like
30:26we can't read files from the file system
30:28because the file system isn't in the
30:29isolate, and that would allow us to
30:31escape and screw with other people's
30:32stuff. We can't run native code because
30:35native code escapes the isolate and
30:36needs to run in the actual like system,
30:39which we can't do here. Which means we
30:40can't run a lot of other languages in
30:42Cloudflare Workers. Means we can't do
30:44traditional persistent servers in
30:45Workers. There's a lot of these things,
30:47and Cloudflare has built lots of clever
30:49solutions to these problems, but the
30:51code that we're talking about, the
30:52JavaScript, is running in this virtual
30:55layer above V8 instead of running at the
30:58VM layer. This makes Cloudflare an
31:00incredibly cost-effective and memory
31:02usage-effective platform, and that's why
31:04it's so cheap. It's actually cheap to
31:06run. They're not just pricing things
31:07cheaper because they want to win.
31:09They're doing it because their platform
31:10allows them to and still have margin. In
31:12this sense, Vercel's not overpriced
31:14because they want to make more money
31:15than Cloudflare. They are charging
31:17probably similar margins, but it's a
31:18higher cost to them, too. But since
31:20Cloudflare is just running in this
31:22JavaScript layer, you can't really run
31:24an agent in that because you can't write
31:26and read files. You can't run a dev
31:28server. You certainly can't run
31:30TypeScript to go to turn your TypeScript
31:32into JavaScript and get feedback on
31:34what's wrong to your agent. Oh. Huh.
31:37Weird. It looks like I did exactly that.
31:40This is the demo I built in Astra, and
31:42it has some dumb decisions that are
31:43wasting a bunch of memory, so I'm going
31:45to switch to this version that Opus made
31:47cuz it's a better presentation of what I
31:48have in mind here. Before I can justify
31:50the chaos I'm about to show you, I need
31:52to show one last reference. There's a
31:54library called just-bash. Just-bash was
31:57created by Malte at Vercel and has
31:59become a pretty legit library. The point
32:01of just-bash is to provide agents a full
32:04fake bash environment in memory in
32:07JavaScript so that you can import this
32:09bash from just-bash and then execute
32:11most traditional bash commands with a
32:13fake file system, fake processes, fake
32:15everything, allowing for an agent to
32:18operate as though it is working within
32:20bash, even if it isn't. But in order for
32:23this to work, you also need to be able
32:24to compile and type check and do all the
32:26other things that you would do in a
32:26normal file system if you wanted to use
32:28this to build. If you set this up as a
32:29way for your agent to explore fake files
32:31to find content, awesome. But you're not
32:33going to build a real app with this. You
32:35need too many other things, including
32:37TypeScript Rust, well, TypeScript Go or
32:39TSC traditional, but now with TypeScript
32:42Rust, we can do really stupid things.
32:44Like here, where I had a GPT-61 Soul
32:47build a full app that is entirely
32:50functioning all in a V8 isolate. This
32:53one is running in Node on a server
32:55technically, but this could just be run
32:57on your browser. There are some
32:59limitations, but not as many as you
33:00think.
33:01And this all just ran and worked and did
33:03its thing. And the entirety of
33:06utilization for this, everything that
33:08was used here, from the agent to the
33:11computer it ran on, to the compute that
33:12the app itself is running on, to the
33:15type checking and compilation and
33:17everything else, just ran on my isolate
33:20and used under 216 megs of RAM and it
33:22peaked at like 4% CPU.
33:25Do you understand how cool this is? This
33:28will allow for you to have an agent
33:31build an app where both the agent and
33:33the computer it runs on, not the like
33:35compute for the inference, but the
33:37compute that it's running the code on
33:39and building on, all together for
33:41pennies. And doing this with Go would
33:43suck because TS Go wastes a ton of
33:46resources simply because porting that to
33:49JS is not viable Wasm, but you get the
33:51idea. WebAssembly is not a good fit for
33:54Go. It is an incredible fit for Rust.
33:56And just to emphasize my point here,
33:58when I had Astro build this, it chose to
34:00use ESBuild for the bundler. And just
34:02sitting here idle, it's using 2x the RAM
34:05of the other version. Because the
34:07inclusion of a Go-based package like
34:09ESBuild inherently just eats memory and
34:12resources and the data that has to be
34:14loaded in. Like we have to load way more
34:16in because of how much bigger the
34:18bundle is. I see people confused about
34:20how this would work on Cloudflare. Do
34:21you know what Cloudflare, Chrome, and
34:23Node all have in common? They're all
34:25using V8 isolates. The way these things
34:28work is that they are all using the same
34:30JavaScript engine, and when you load a
34:32Chrome extension or you load a new file
34:35or you have some process in WASM, those
34:39are all different isolate workers is the
34:41term for it, and they can communicate
34:42with each other if they're allowed, but
34:43they cannot interfere with each other.
34:45What I built here isn't impressive
34:46because I rebuilt Bolt but used TS Rust.
34:49What I built here is impressive because
34:51I could turn my file system on read only
34:54and it still works. Nothing here left
34:57RAM. Nothing here left V8. I'm not doing
35:00anything on the system. This all exists
35:02within V8. The whole dev loop exists in
35:06V8. There isn't anything comparable. I
35:08see people mentioning like random like
35:09database companies and stuff that let
35:11you execute code to them. No, no, you're
35:12you're not getting it. And if you guys
35:14aren't getting it and you're my stream
35:15audience, I am not excited to see how
35:16others deal with this. Let's talk about
35:18how computers work really quick. At the
35:20bottom, you have hardware, CPU, RAM,
35:23whatever else. Above that, you have
35:25drivers.
35:27Drivers are provided by the thing above,
35:29the kernel. The drivers are the method
35:31in which the kernel interfaces with
35:33hardware. Above this, we have the
35:34operating system. Above this, we have
35:37applications.
35:38I would argue actually we have file
35:40system, kind of. Then you have
35:41applications. So, let's figure out how
35:44something like Heroku, Hetzner, or any
35:47normal cloud works. If we wanted to
35:50deploy a Docker image on AWS, we are not
35:53deploying it here because these things
35:55have to exist on AWS's hardware so that
35:58they can put more systems above. So,
36:01what they'll do is in the application
36:03layer, they'll put something like
36:04Docker. And you know what you do after
36:06that? You copy-paste everything
36:09and do this.
36:11This is how hosting on normal VPS
36:14providers works. On top of the file
36:16system and operating system, you have an
36:18application, usually something like
36:19Docker, and it's not technically running
36:21a new kernel instance always. Usually
36:23it's doing a shim kernel. So, I could
36:26claim like for this layer here that this
36:28is all like the like Docker
36:31hypervisor I don't fully
36:32understand it, but like Docker shim to
36:35kernel, which makes the kernel stuff
36:37more efficient for sure. So, this shim
36:39is there to allow you to skip steps when
36:41it makes sense to. And then you're
36:42building an OS on top, which is why on
36:45something like AWS, you can have one box
36:49that AWS is providing that has one
36:51person running Ubuntu, one person
36:52running Windows Server, and one person
36:54running I don't know, Debian or
36:55something. That's all happening in the
36:57application layer of Docker on top of
36:59the operating system, which means every
37:01one of these things takes RAM.
37:04This is why every time you spin up a new
37:06Docker container on your computer, it's
37:07using a bunch of resources. It takes
37:09resources to run operating systems in
37:11your operating system. Let's compare
37:12this to how JavaScript works. So, we
37:15have our whole stack here, but let's say
37:17the application is Chrome.
37:20Inside of Chrome, you have V8,
37:23which is the JavaScript runtime. And in
37:25V8, you have all of these isolates. And
37:28all of these isolates can execute
37:30different JavaScript files and functions
37:32at the same time. This is way more
37:34efficient because now every file or
37:36application, if it fits in one of these
37:38isolates, it doesn't need to shim out to
37:41the kernel, run an operating system, and
37:43steal a bunch of resources. Like like
37:45let's be real here. What takes more
37:47resources on your computer? A new Docker
37:49instance of Postgres or a new tab in
37:52Chrome? Tabs in Chrome, as slow as y'all
37:55might think Chrome is, obviously uses
37:58way less resources. Absurdly, comically,
38:00obviously so. The reason why is the
38:03insane billions of dollars that Google
38:05has pissed into V8. They wanted to make
38:07this engine as efficient as possible so
38:09that the web could be a compelling
38:11platform so they could finally stop
38:12making shitty Windows apps. Google spent
38:14a billion dollars so that Chrome would
38:16be fast enough so they could stop making
38:18Windows versions of Google Earth and
38:20That was a lot of money and effort
38:23put in to V8. And this has benefited the
38:25whole ecosystem in ways that are hard to
38:27comprehend, including all of Cloudflare.
38:30Cloudflare's whole platform is built on
38:32the idea that virtualizing at the
38:34operating system level by putting an OS
38:36at the app layer is stupid. And V8 is a
38:40much better abstraction for putting
38:42applications that customers are hosting
38:43on top of. The catch is that these are
38:46just JavaScript. They don't have full
38:48system capabilities. You can't call the
38:50kernel cuz there's no kernel you have
38:52access to. You can't write files cuz
38:53there's no file system. It is just
38:55JavaScript. Anything that a Chrome tab
38:57can't do, a V8 isolate can't do. With
38:59the exception, of course, I don't even
39:01talk about CORS now. But remember, all
39:02the problems here are you don't have a
39:03file system. You don't have native code
39:05access. You can't do the things you need
39:07to build. Isolates are a good place to
39:09put the code once it's built. They are
39:11not a good place to build. On Vercel,
39:13for example, Vercel sandboxes are the
39:15same compute and primitives as hosting
39:17on Vercel is. On Cloudflare, Cloudflare
39:19sandboxes suck because Cloudflare does
39:22not know how to make things work well
39:24with Docker because that's not their
39:25focus. Their focus is this isolate
39:27layer. So Cloudflare sandboxes run on
39:29entirely different compute with entirely
39:31different platforms than Cloudflare's
39:33traditional like worker hosting. So the
39:35thing I did here, the thing I enabled,
39:38inspired by just bash cuz the thing that
39:40makes just bash special is it lies to
39:42agents living in this isolate layer so
39:44they think they have access to the file
39:46system and to these other things. And
39:48that is what we have built here. If I
39:49was to flip a switch on the file system
39:52for the server running this demo to be
39:54read-only, so I literally could not edit
39:57files on the computer, I could only do
39:59things in RAM in my V8 isolate and node.
40:02This will still run exactly the same.
40:04That is what makes this demo cool. It
40:05would be fully possible to run this
40:08entire demo in a Cloudflare worker. So
40:10instead of needing half a gig of RAM and
40:13a bunch of reserved CPU, I can throw it
40:15in here and it costs nothing. Another
40:18thing to think about here is how CPU
40:20allocation works. If you have a VM that
40:22has two CPUs and I have a VM that has
40:24two CPUs and both are idling, we're
40:27still wasting four VCPUs. There are some
40:29things that make it easier to like
40:30reallocate and have virtual like cores
40:32not be guaranteed the same way. But the
40:34way it's working on Cloudflare is with
40:35the built-in event loop where when your
40:37code isn't doing anything, it doesn't
40:39cost anything other than a bit of RAM.
40:41So when you're waiting for the next
40:42token from an inference provider, that's
40:44not costing you any compute because the
40:46CPU is doing nothing. So that CPU is
40:48being used by others. When suddenly data
40:50comes in, it will execute the next task
40:53because your app, my app, and another
40:55person's app are all sharing the same
40:57event loop. We're all sharing the same
40:59scheduler effectively. So it becomes way
41:01more efficient for us to run things
41:02here. And even a long-running task that
41:04takes hours probably spends most of its
41:06time idle. Now that only costs money for
41:08when a token comes in, not for the time
41:10between tokens. If inference continues
41:12to get cheaper, this type of building
41:15will become essential because this will
41:17enable us to build agentic developer
41:19experiences that are cheap on all sides
41:22where running the agent is cheap and
41:24giving the agent compute to execute on
41:26is also cheap. I see some people in chat
41:28catching on here asking, is this related
41:31to Lakebed? I won't say more yet. I need
41:33to give you guys something to be excited
41:35about because I just wanted to focus on
41:37this. The fact that TS Rust is one of
41:40the final pieces I need to take a full
41:43end-to-end TypeScript developer
41:44experience and do it in an isolate
41:46instead of doing it in a VM. For those
41:48who are curious and want to see the very
41:50complex prompts I used to build TS Rust,
41:52here you go. I told it to work in
41:55CodeSandbox TS Rust on this computer.
41:57Read the agents.md and the type check or
41:59accountability files first. Those files
42:02included auto notes from the 16-hour run
42:04and asked for some things. Make the
42:06cargo job count configurable, add script
42:09state and split, yada yada.
42:11And then update the agents.md D it could
42:12do more parallel work. To which I said,
42:14"Do it. Great work. I trust your
42:15judgment fully. Keep going and doing
42:17what you think is best to continue
42:18improving compatibility and performance.
42:19You can probably move to main soon as
42:21well." I did a follow-up at some point
42:22saying, "Get whatever the best current
42:23state of the work is and set it as the
42:25main branch ASAP. I don't care how. I
42:26trust your judgment." Then later I did a
42:28slash effort cuz I noticed I was on the
42:29wrong effort level. Actually, I was on
42:31ultra code and it kept bumping me down
42:32to medium when it crashed cuz it was
42:34running out of memory and crashing
42:36system D constantly. But once I like
42:38added some things at the OS level to fix
42:41this, I had to rerun slash effort to put
42:43it on ultra code again on XHI. And then
42:44the slash goal of complete the port, get
42:46as close as possible to 100%
42:47compatibility with TSGo, and then also
42:49improve performance. Do the efforts in
42:51parallel. Multiple workflows and
42:52sub-agents should be running at all
42:54times to maximize parallelism.
42:55Orchestrate how you need to keep them
42:57working independently all on this
42:58machine. And I noticed it was running
43:00out of compute all the time. So I took
43:02other machines I had in my fleet,
43:04configured them for SSH access, and told
43:06it, "You have SSH access to other
43:08machines now, like cup two and Alvin two
43:10of my uh VPS's." I noticed it kept
43:12stopping because it like got full compat
43:15and then like would make one performance
43:16room and be like, "Look, I fixed
43:17performance." So it needed a better end
43:20state. So I told it with a new goal,
43:22"Our target is minimum 2x faster than
43:24the go build. Continue iterating until
43:26we get there." And then it did for 2
43:28weeks.
43:30And now we are here. So as you see, I
43:32wrote some very complex prompts for all
43:34of this. Super super high IQ things I
43:37was doing here. I'm a mega prompter.
43:40Real talk though, the things I did here
43:42were not around the prompts. It was
43:44around the environment and setup to
43:46allow it to do this stuff. So I like I
43:48had other threads going where I was
43:50auditing constantly figuring out where
43:52the blockers were, what's taking a
43:53while, what failure modes are happening
43:55again and again, and then updating the
43:57environment to allow agents to operate
44:00more effectively in parallel without
44:01stepping on each other. And after a bit,
44:03we built systems that allowed that to
44:05work and ended up shipping much faster
44:06once we did, but my energy was honestly
44:09similar to how I work as a manager,
44:11where I wasn't spending my time in the
44:13trenches writing code. I was spending my
44:15time making sure that my team had
44:18everything they needed to be as
44:19effective as possible in finding where
44:21the slowdown was and helping them get
44:22around it so that the slowdown would
44:23stop happening. Ended up being really
44:25fun. And I know I was making a joke
44:27about being a mega prompter, but uh I
44:29have been politely requested to mention
44:31Mega Dev a bit more. I am finally doing
44:33a paid course for the first time ever.
44:35Feels weird and I want to be very clear
44:37about this. Any information that will
44:39help you get a job is not going in here,
44:41it's just going on my channel for free.
44:43The point of this is for employed
44:44developers that want to maximize how
44:46much they use and abuse AI to ship real
44:49software in the real world. I'm working
44:51with three other incredible instructors,
44:52people who have helped me learn how the
44:54web and technologies work for years now.
44:56I'll do the sidebar so you can see
44:57Angie, who I love to death, Kent, who
44:59taught me half of what I learned about
45:00React back in the day, and John
45:02Lindquist, the creator of Egghead. If
45:04you have to pay for this with your own
45:05money, I wouldn't recommend it, but if
45:07you can get your boss to sign off on
45:08using internal like expenses for
45:11educational stuff for it, it'll be fun.
45:13And I'm going to do a live workshop with
45:14it as well, which should be very fun.
45:15So, that's where I'll get to talk more
45:17about all of these chaotic strategies
45:18for maximizing what your agents are
45:20capable of, which should be fun stuff.
45:23What a journey this one was. I My AI
45:26psychosis was already pretty bad, but
45:28the fact that all of these truly crazy
45:31ideas I've been thinking about for years
45:33now are actually doable. Like I've
45:36always wanted to have a full stack
45:37developer experience that runs purely
45:39within V8. Back when Bolt was still
45:42StackBlitz and they first put out their
45:45full like JS runtime thing inside of
45:48WASM, so you could have a full VS Code
45:50like experience with apps bundling in
45:52the browser, I was blown away. I wanted
45:55to go further with that with Cloudflare,
45:56and I went as far as trying to reverse
45:58engineer StackBlitz and like decode the
46:01JS binary in their WASM to figure out
46:03how they were doing it because there
46:05there was so much cool stuff there.
46:05That's how I became friends with Eric
46:06back in the day and that stuff was so
46:08cool. I've always been a nerd about how
46:10the code we write actually runs and
46:12executes and how these systems compose
46:14and operate. It's such fun stuff. And
46:17now I get to try out my crazy ideas.
46:19Previously, the vast majority of this
46:21was just like imaginary. Like I was
46:23playing these games in my head and if
46:25any of those ideas went far enough, I
46:26could maybe talk about it with a smarter
46:28person and maybe inspire them to build
46:29something kind of like it in 5 years in
46:31the future. Now when I have one of these
46:32insane ideas, I tell Opus and then I see
46:35if it works or not. Even now, I wanted
46:37to see if this will actually run on
46:39Cloudflare. So I just told Opus, go do
46:41it. And it probably will. Absolutely
46:43insane. I On one hand, the engineering
46:46we know and love is dead and very very
46:48much so. These types of YOLO projects
46:50should not be viable at all. Like you
46:52shouldn't even be able to get it past
46:53the tests, much less actually work as a
46:55drop-in replacement for TypeScript. But
46:58yeah, if you still think AI dev isn't
47:01the future and isn't obviously where all
47:02of software dev is going, you deserve
47:04the lack of employment you'll have in 3
47:05months because this is insane. It's
47:08actually hard to fathom how capable
47:11these tools have gotten. I think this is
47:12everything I had to say on this one. I
47:14was up till 6:00 in the morning prepping
47:15all of these demos and I'm so proud of
47:17what Opus and I were able to cook. Not
47:19because I think everyone should use
47:20this, but because I can find out if
47:22these ideas work or not in ways that are
47:24just hard to fathom. I actually feel
47:27like we're peering into the future with
47:28some of this stuff and it's so cool to
47:30see. I cannot imagine where we will be
47:32next year. And I hope you guys are
47:33excited to go on this journey with me
47:35because it's only going to get more
47:36chaotic from here. And with that, until
47:37next time,
47:39peace, nerds.

About this transcript

This page contains the full transcript of You can rewrite typescript in rust for $420k by Theo - t3․gg, generated from the public captions YouTube serves with the video. The transcript has 9,890 words across 1,403 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to choose a caption track available on the video.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, caption language selection, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.