Was I Wrong About Rust? 

RUST MENTIONED

Rust story is about correctness, not coding speed. You move slowly, but the resulting code is far more reliable. Our team rewrote about 15k loc from python/numpy to rust. Code size grew by about 3k loc. Speed went through the roof (that was not the most important point though). Importantly, amount of strange results in the program output that we could not attribute to any particular location in code went to zero. So, as a nuclear option for fixing the truly obnoxious and untraceable bugs, rust works great. Also importantly, the "external" bits of the system are still in python, so we did not have to mess with api that we expose. By the way, we still have no idea where the bugs were exactly in the original code, we just know they did not survive the rewrite.

I find contributing to Rust projects much easier than contributing to JS projects. The strictness makes it easy to know whether what you're doing to this unknown codebase is right or not. It raises the confidence a lot.

the "once you opt-out of the borrow checker, you're just writing weird C" comment makes me think that you haven't written much rust at all

I still just don't buy that "sweeping changes" are that more difficult in Rust. In fact, I would be terrified to do a "sweeping change" in JS, because there are SO many opportunities to introduce subtle bugs when changing a lot of code obviously. In Rust, I basically start somewhere - remove something, change function signatures, replace a type with an enum, etc. etc. - and the compiler errors will show me where other code breaks and lead me naturally until everything works again. Edit: Sure, depending on the size of the change, it will take time until I can run my code again at all. But what's the point of running code that can easily be proven by the compiler to be incorrect?

WORDS MENTIONED

Gentlemen, we are listening to opinions on how easy it is to develop in Rust, from someone who has never written a line of Rust before

Really wish Theo would stop talking about how he imagines what programming in Rust is like based on memes and vibes when he's never written anything meaningful in rust. The idea that rust makes it hard to change code is completely wrong. It makes it easy and safe to do so.

"Long compile times": Rust has incremental builds. Has for a while now. Unless you're building within a Docker container, for-the-first-time, every time, as part of some CI pipeline, it's a non-issue. Writing rust on my local dev machine, not an issue.

You can just sense Prime's Twitch audience invading this comment section..

There is a huge difference between coding influencers and actual senior coders.

I made it about 10 mins in before I bailed. If you’re wondering if you should put in the effort to learn Rust, do it. It will be difficult for a few months and then you’ll gain momentum and realize the ROI for the gains far outweigh the time cost of learning.

Mentioning mentioned

Brazil mentioned

Have you gone through the webpack codebase?? It's been a mess especially in the early days. Just because it's in JS doesn't mean the barrier to entry for contributing is low

I think theo is overestimating how hard it is to write rust. Its not that bad, and in many ways its type system makes it VERY expressive

If they are maintaining it and we get it for free, they can write it however they like.

Maaan stop portraying Rust as this impossible to write language. It's not true, it's a systems programming language and that won't change, if you don't like those, fine but there's a lot of people that do

I noticed that when I return to my Rust pet-project six months later, I literally get into my code within an hour. There is no such thing in Python and C++.

Haskell is actually great at doing breaking changes to fix these kinds of things. It still takes years of course, but they're willing to change fundamental parts of the language, like adding applicative between functor and monad and moving fail out of monad and into monad fail

I heartly disagree about the comparison with gamers. We're not asking "why can't you add more maps?" We're asking: "You've designed and shipped a live game for which you require your users' time and money, why didn't you put in place the tools to better support said live game before you actually shipped it?"

Once you are used to Rust, the borrow checker doesn't really slow you down. I feel as if the strict type system is actually what tends to slow down development.

This man has not written go in his life

high respect for starting the video in this way

calling typescript typesafe pains me

Our experience was there is a threshold with a project where when it becomes big enough that you essentially have a dev (or two...) spending a lot of their time hunting dumb bugs like intermittent undefineds to keep development rolling. That's why we switched to Rust. We could not maintain our codebase and continue to add features that worked reliably in JS/TS with only a few devs. Similar to what the TurboRepo person said "The number of github issues decreased dramatically, and we had to check that people were still using our product" (paraphrasing).

I don't think discord moved away from Go. That blog post was about one of their performance critical services.

Theo, I cannot stress how joyful the rust compiler is for bug fixing or general guidance towards using correct types. I think you as a TypeScript dev will learn to love it and get pissed at how TS doesn't do more like rustc Edit: Theo, the reason discord moved from Go was the latency introduced by the Garbage Collector at specific intervals leading to an unpleasant audio experience. That is inherently a language choice problem.

My issue with this take is you say "if it's 3x longer to write in rust" ... it isn't though it really isn't lol for 99% of what you deal with in most of these projects it's no harder than writing to c# or typescript lol for the other 1% or even 5-10% its definitly a cliff more difficult but for the vast majority of features being "experimented with" won't ever touch that small slice.

even after a couple of decades of javascript experience, I found the on-ramp to rust much smoother than typescript.

I don't know why I keep coming here you guys I'm too stupid for this channel

I think one of the biggest benefits to working in rust is the ability to effectively orchestrate code development among many developers. If only one or a handful of people are writing for a particular project it isnt all that difficult to make sure things operate properly. Once you are working with dozens of programmers across multiple companies the guarantees and checks you get by using rust really start to show their value.

It's way easier to maintain large complex applications and libraries in rust than it is in javascript

You can't "opt-out from the borrow checker"

35:58 I don’t think the problem is rust, you mention that esbuild was crated in a couple of weeks and we don’t have anything similar but we have had SWC for a long time. I think the problem is that everyone is trying to create their own solutions and over engineered tooling before solving the most basic needs for 80% of the use cases

Interesting video. Cool that you're open to changing your mind on camera! I've worked with scala for the past years and am currently learning rust (for backend) and typescript with react for frontend stuff. Rust definitely has its quirks, but it often feels like they make a lot of sense. The adt modelling in rust is really great and the pattern matching makes it very usable. It's a real bummer that typescript doesn't have that. I also wish that typescript had typeclasses. e.g. requiring an Ord instance for sorting an array by the values or one of their properties. I expected to have more trouble learning rust, but I have more trouble learning all the intricacies of react.

Soydev changed his mind? episode 9001

for system level tools traidoffs very different. What would you do if node segfault's? Speed of iteration matters only then releases rock solid (for low level tools)

I think that maybe some people missed your overall point, which is a very valid point that applies no matter what language the project was written in or what language they want to move the project to. For my own perspective on this constant RIIR mentality, I've found nearly universally that when rewrites happen, features are lost. Even if the program runs faster, if it does less, as the user of that program I don't care if it's now viewed as a "safer" program. Of course, as anyone who knows more than one systems language can tell you, there's more than one way to skin a cat and Rust isn't any safer than other languages, even C. There are plenty of tools to do analysis of your code and keep your program error free that are far better than the Rust compiler and target languages like C. You can write high quality code in nearly any language, it's just a matter of skill. One could claim all they want that "Rust forces you to do things a certain way", but if you already write your code in that way then you shouldn't have problems with C, and if you don't already write your code that way then you were using C wrongly anyhow. If you didn't already know how to correctly write code, then you probably shouldn't have been a programmer in the first place, or you should just use JavaScript. As for the comments on async, I have always believed it's the wrong solution for the problem at hand. It's an attempt to merge the concept of a coroutine with threads and make them take less effort than threads, but it's still just threads with you having less control over what happens. True coroutines don't require separate threads, but the concept has been bastardized by everyone who keeps incorporating async garbage into languages. I look at them as being unnecessary work because it's better overall to just use the OOP method of saving state in memory somewhere, maybe even on the stack, and then just calling a function to update that state, which is more or less the generator concept. Consider that C already has that in its standard library with FILE's, where you can read some input or write some output and it's buffered. If you really want to read input in the background, then just use a separate thread, which even C has in its standard library now too. Although, I doubt anyone will read all of this, and it's most likely that someone will see this last line and comment that they read the whole post when they didn't.

This is how i do it. I always start with javascript. I then transition to go if either there is performance issues or if it can save me quite a bit on my cloud bill. I would only got to rust if it would save me a lot of money or if the performance difference made real significant performance impact (maybe on a hot path). If I end up needing rust i considering myself lucky because that mean whatever app i'm developing is being used a LOT.

"Was I Wrong About flutter?" next ?

I must say, I enjoy that you post videos like this when you get more accurate knowledge about something you were misinformed about and want to share it. The world would be a much better place if more people did this!

25:30 i never heard someone bring up the argument for a language of "The good thing is, this stuff can be made so unmaintainable, that reusing old code is a breeze" For rewriting things, you do not have to use new types either in any typed language, it generally is a good idea to replace your broken code tho, which does apply for both typed and ducktyped languages

"Today Theo" explaining "Old/Young Theo" that he was wrong. I can't wait for a video where "Future Theo" will explain "Today Theo" using this video :P

It would be so funny if this video ended with: No, I was right the entire time and ya'll dont know what you are talking about

6:40 "Once you opt out of the borrow checker, you're writing a weird syntax for C" is over exaggerated. Even unsafe rust has more guardrails than C. I get your point that Rust is rigid and makes building flexible systems hard, but the value of using rust doesn't go away as soon as you need to use unsafe or use indexes as if they were pointers. You're still in a much safer environment than writing raw C.

I never used Rust. But the Theory behind it sounds good. Fast as C without so much memory issues. I would use it if it had the eco system of dotnet. A language is just as good as the framework around it.

I disagree that spot fixes are easier in go or C. Once you are “stable” those spot fixes take FOREVER to approve due to problems already mentioned in this video. This is project specific, yes. If you write internal tooling for Netflix and you breaking something isn’t going to make your biggest customer pissed off and walk away and shut down your startup, just fix it and ship, and let the users send bug reports. But if you are a platform tool targeting certain kind of enterprise devs, the nightly builds failing can be literal tens of millions or more down the drain for your large manufacturing tech customer, who will leave you. And then you will go bankrupt. Point isn’t that you can’t create stable in C or go. It’s just that doing so requires long iteration and test driven development or just slow development. Which is not ideal for a startup like this. Thus, think about the kind of customer you have. If you have regular people who when Netflix takes a little too long to load will just turn it off and watch RU-vid and come back later, and maybe after weeks or months of this will actually start canceling at a few %, just ship. But if you have 5 Major European enterprises and a small fraction of American tech startups as your customers, losing any of the big boys can literally kill your company and your job, you need to use the better tool. Rust or TDD or slow code is better here. And let’s be real unless you hire uncle Bob himself you are not getting 20 year olds writing test driven code in go or C. So now you have a million betas and release channels and golden tests and people having to manually try and QA things for each bug fix and release. Bug reports pile up in the repo but most Importantly your big time customers expect stability and features. So you focus all your time on delivering that bare minimum for them and nothing else. You become slow. Seen it with so many tools. Vs if you are writing some OS software to help out a smattering of fellow devs, or to serve to web clients who could be just as well down because their wires were literally chewed on by rats, it’s ok to just ship. Context matters.

its hilarious how your main reasoning is "js to rust is hard" meanwhile i moved from js to rust and feel for the first time like i can actually understand what im doing.

What browser are you using there?

your deduction about garbage-collectionlessness being less important for temporal operations like build tools is valid but the premise is incorrect if the build tool is daemonized (like Nx for example)

I'd be interested to see data to back serverless cold start in rust being slower than javascript (and a small google search finds the opposite)

Slow is smooth and smooth is fast.

There's a browser solution for breaking JavaScript language changes. In the script tag, it can specify the version the JS is.

That was a really interesting and enjoyable to watch video. Thanks Theo

9:45 if you are coming up with new (let's say) css-in-js solution you not only need to implement it in Rust, but also you need turbo pack to merge that in main, because you can't just easily include native compiled modules as you can import a JavaScript plugin

I like that Theo took it back, the guy is a prime example of humbleness

32:50 i use rust for lambda / serverless and honestly its been great. my cold starts have been ~5ms + the time it takes to create a db connection, on most functions. Compile with size optimisations and maybe use UPX (affects actual runtime perf but can improve coldstart due to package size), and its honestly been a pretty great experience. Can get away with pretty low memory usage too

Sometimes I think FE web devs should be required to develop in a "heavy" backend language like Java, Rust, C#, or any other so that they can experience what development on a large code base in a stable ecosystem is like. Most of the problems that JS developers are attempting to solve using JS for JS problems are either already solved in another language or are better solved in another language. One of your arguments against using Rust (or even Go) for this tool was because JS devs would have to learn another language. I audibly said, "Good." Learning JavaScript made me a better Java developer. Learning Clojure also made me a better Java developer. Learning Python taught me the value of rapid micro-iterations. Dabbling in C gave me an appreciation for simply having structs and functions. When you learn another language that puts a particular paradigm at the forefront, it teaches you the absolute best techniques and paradigms for a given situation. For example, Clojure taught me the importance of thinking in terms of composed expressions to get transparently get a value back. Now, I try to code as few statements as I feasibly can and try to consolidate an entire method body into a few manageable and significant expressions. This makes the code cleaner and the intent easier to understand. If more JS/TS devs ventured out of the JS ecosystem and spent a serious amount of time learning the value of backwards compatibility and stability, the web ecosystem would be in a much better place.

One thing that can make refactoring Rust code easier is using traits and impl parameters in your calls instead of concrete types. This can also make your API more flexible and capable.

Uganda mentioned

This was a really neat video with some interesting takes. 😊

I don't understand how a highly-verbose language with a very limited abstraction tools (Go) can be better for fast-prototyping than a languages that are less verbose and have better abstraction support (and I don't mean Rust. It's type system and verbosity don't allow fast-prototyping, I believe).

PRIMEAGEN MENTIONED!!!!

We stopped using turborepo because of a broken caches, sometimes turbo is pushing broken files (like a half of a file, or some file is completely missed from tsc output). We tried to find a reproducible case, but it's a random but, which broke our production and stage envs multiple times. Also, it was really hard to debug, because you have correct local cache, but remote was broken.

I would argue garbage collection and memory management in general is actually critically important if you want fast build tools. Think about the number of times the code has to be copied in memory every time you’re doing one of those transpile operations… malloc isn’t free, and I need to point no further than Go’s now abandoned memory arena experiment, and the performance benefits that it enabled in specific use cases. TL;DR: if memory management wasn’t important, then Go wouldn’t be trying things like memory arenas.

Actually i love the Web ecosystem slowing down a bit. Stability is a value on its own. It makes it easier to research stuff. I hate when everything i find is already outdated.

The expressiveness of rust would be the greatest thing imo. Once you get used to rust, it just feel normal anyway. 😂

If you work for a company that's been in business for 10 years and looks basically the same *hint that's you*... You can afford to write in something that isn't a JS framework. I have no idea why the benchmark for what language to use is always "startup".

Hi Theo, I love ur channel , it is one of the best Fullstack resource to learn Ive ever seen. Do you have some open vacancies in your company? I would love to join

When you start to build libraries in Rust, you may not be able to simply do a major version bump

kudos for having the integrity to revisit the topic

I would recommend actually writing some Rust. There are drivers and even OSes that barely use Unsafe, I don't think many tools need it at all. Feature flexibility is not the same as memory safety. In fact, the memory safety aspect makes it easier to refactor since the compiler points out any problems that arise. Usually you have good takes, but this is just not a good one.

A lot of programming languages that started under unix emulate the POSIX API on Windows. By which I mean things like errno values, stat(), file permissions, unlink(), etc. which work quite different on Windows. Some languages that do that are e.g. Python, NodeJS, apparently Go. Can't remember if also Ruby. This emulation can lead to subtle bugs, especially around file permissions. Rust doesn't do that. Instead it gives you a general API for things that are the same under Windows and POSIX, plus platform specific traits for appropriate data types that give you the platform specific functionality. Meaning you have to make an explicit decision on how exactly your program should work under Windows. I don't use Windows, so I would be ok with it not being supported at all, but I think poorly emulating the POSIX API is the worst option.

Rust: make invalid states *_UNREPRESENTABLE_*

10:50 plugin systems! if a well defined plugin system is created, it would not be difficult to use wasm components to make extensions with pretty much any language, js included.

I would add even more nuance to the subtle effect of reduced innovation that you are talking about - are we sure there would be many people determined enough to write bindings and plugins, who at the same time would get immediately discouraged when seeing it's in another language? How many of the people who would get discouraged by the need to learn something more, would make a valuable contribution/innovation? I am not saying that you are bad developer if you really like to work only with one language and nothing else, but are you a great one with a broad perspective that tends to contribute to complex tools codebases?

@6:54 - one of my ... "concerns?" ( poorly worded ) perhaps curiousities? - About rust vs C, this comes from a lack of rust experience, would be that C as a language and C++ for that matter, has made a number of concessions in the language to make code more succinct, improve performance etc. And I often wondered if that is ... not be pure logic - but ... similar to "the type of the thing your working with" - like if I have to explain constexpr to c++ then in order to get simlar gains in Rust I will have to get rust to know this about the lifecycle of that memory reference/variable (type system) - and if that feature is missing then the optimization can't be done. Hence the need for C? So will rust slowly but surely degrade into a poorer representation of itself in order to have the deep low level features of C/C++ over time? How is that mitigated? Obviously it takes time for a language to mature, and right now C/C++ is looking at rust like "your time will come child, be patient" lol. But I mean, it would seem that C/C++ still has SOME good advantages over rust, and rust has good use cases now. (I suppose that in some extreme cases, like embedded development, you'd want to have C/C++/Rust just to cover your bases, the day-to-day coding is done in rust, and perfomant interfaces may need to be written in C/C++) (Let me know if I missed the mark completely, I am an old dog learning new tricks.)

well, ive been working with Rust and I honestly have no reason or intention of not using it. it really is phenomenal

A comment on the friction for the community to build a new loader or plugin in turbopack. In your opinion would that friction be "solved" by providing a JS plugin interface, so innovators that don't know rust well enough or don't have the time to learn it for building a POC of a new thing. When the POC in JS is mature enough, and the solution to the problem is popular enough, the author or somebody else would then be able to write the more performant rust counter part?

17:57 because Typescript doesn't have proper enums, which are disjoint types (gadts).

I think the programming language has to work with the specific code style, project requirements, and people that will be working on the project. You can develop Javascript front-end libraries in C, it's just a mess and most people won't be able to deal with it. And you won't be iterating as fast, but if you plan ahead and your team/your self is coordinated enough, everything is possible.

Bun is not the biggest user of Zig. Uber is.

MENTIONS MENTIONED

I fankly can't understand why it was given the very mame "rust"..

"Rust is hard" :sigh: I made a channel specifically to address this rhetoric. To be fair, this idea, "Rust is hard", still exists within the community too, but, I'm sorry, I just don't think its true... anymore.

11:12 I strongly disagree that you can have confidence in typescript in terms of types. Especially in a medium to large code base you are not extremely familiar with. When done intentionally it is comically easy to violate typescripts typesystem. (*Without* the usage of any any-type.)

MELKY MENTIONED

From my perspective, the main thing I dont like about turbopack is that it's porting the trashpile that is webpack. Every single other bundler/build tool since the days of Grunt has been easier to configure than webpack

i took your advice last time to shift to go from rust for building internal CLI tools and have been more productive in building stuff and delivering outcomes than I would have been in trying and learning rust and trying to make something barely functional.

The DX argument for why you should use something is such a subjective thing that I don't believe it holds any weight in conversations about when you should or shouldn't do something. If you, as a developer, enjoy something that someone else doesn't, that doesn't mean that the thing you enjoy is objectively better or worse. Every developer values different things in their coding experience, so there is not objectively better DX.

Saying Rust is 3x the time of Go is absurd. Google's engineering director just did a talk about how their Rust projects are "about as productive" as their Go projects. ru-vid.com6mZRWFQRvmw?si=Yor3rbm2BN4zlmQy

Thank you for supporting your humble anime profile picture devs

Regarding Tailwind - I actually find Tailwind to be a bit more difficult to debug. It's harder to find the right component using the Devtools. I switched from Tailwind to CSS Modules with PostCSS. With the "go-to-definition" feature of the CSS Module plugin for VSCode it's especially easy to debug and work with CSS. To me it mainly comes down to Tailwind giving you a good style system to work with and not making you name things, while CSS Modules give more flexibility and easier debugging & code readability.

MENTIONED MENTIONED

"Why don't you load one stash instead of doing select * and loading stashes of everybody on the server?", why Blizz? Yes, gamedev is not easy but most hirings are DEI-based instead of skill based so most people at AAA-studios these days have no idea not only about gaming but also about performance driven programming.

I disagree with the "your just kinda fucked" a lot of that "type pain" is easily fixed by decent IDE features, type renaming, restructuring and function signature changes are a huge PITA unless you have a tool that will essentially do it for you

Just use ASM for everything, problem solved

PERFORMANCE AND SCALABILITY MENTIONED !

There are important rust libs that are archived... because they trust back compatibility that much.