Was Porting To Rust A Mistake?
Vložit
- čas přidán 19. 03. 2024
- I'm not the biggest fan of Go, but I'm also not the biggest fan of unnecessary rewrites. Turborepo is one of the most important parts of my toolchain lately, so I have lots of reason to be skeptical.
Follow up coming soon!
SOURCE
vercel.com/blog/finishing-tur...
Keywords RUST GO GOLANG TURBO TURBOREPO TURBOPACK NEXT COMPILER BUILD MONOREPO TOOLS
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏 - Věda a technologie
Rust is already doing incremental compilation. It only compiles what changed, but since your crate is an entire binary with all dependencies statically linked, it at least needs to recompile your crate and link it
There's a trick by wrapping big dependencies in a dynamic library so it doesn't need to relink or recompile your crate if the dependency changes.
this is something that rust needs to take from ocaml: module level compilation. because rust builds objects at the crate level, it means that you're more often going to get cache invalidations at the compile step, whereas with ocaml if you change one module within a library it's not going to force a recompilation for the whole library
@@jenreiss3107 yeah, it's the biggest limitation for compilation times right now, IMO. However, if your machine is powerful and only your crate is invalidated it's kinda quick, using the mold linker it takes some seconds in my case.
All we ask for as rust community member is a crumb of integrity , theo you should put more care and do some basic research like this is really bad and it could harm your brand.
Second point people can feel free to write dev tools in Go ,but constantly bashing rust devs trying to improve devs tools is really weird and you're basically doing the same things that some dumbasses that keep spamming rewrite in rust everywhere .
If you think that you can deliver better result in other language please go ahead we will support you but guess what (this is what linus realized too) you have to give people incentives to get them involved so there's that reality you have to reckon with too
You’d think he’d at least do some basic research.
Yea I think crate is the smallest compilation unit. Bigger projects tend to get divided into smaller crates so the incremental build can just be done on the crate that got changed. Although the initial build would still take a long time. I believe this is because of a lack of stable abi in rust and everything needs to be built from scratch (including the direct dependencies and the transitive dependencies). I am not too sure but I think most of these are cached? (with the exception of some libraries that have some special build logic that disqualifies them from caching).
Yes, we need a followup video.
Having used Rust and Go for a good amount of time, the reason I would always choose Rust for tools like this is not performance, but correctness. Rust is quite a pain to learn and even if you can code Rust "good enough" it always takes longer to get the job done. But the results are remarkably more stable and reliable than what you get from other not so strict languages.
this is incredibly valid. when I am writing a new feature at work, if the serialization/deserialization works and I've written unit tests for it, I can be 99% sure that the feature works in production--the only thing that could be missing is a business logic bug, which is soooooo much easier to debug than a race condition or a deadlock. don't get me wrong, rust has both, but in the course of every day dev my company has seen one deadlock in 10 months
One of the Turborepo devs said the amount of issues being filed in Github and dropped so drastically they momentarily were concerned that they had lost users (which was not the case). Being able to ship with confidence is an important factor when building low level tooling.
At my company different teams use different languages to build the products they’re responsible for. I’m lucky enough to be on a team that uses Rust for all of our projects except for when we MUST use another language (like writing a JDBC driver). I honestly don’t think rust slows us down at all. Maybe we sandbag on our objectives but we’re always ahead of where we say we’ll be and ship faster than other teams using Go, C++, etc…
Correctness is number 1, but also
Basically everything in Go sucks. Go is a terrible language that looked at 40 years of programming language advancement and said "nah, we wrote C, and that's good enough". The go creators actively said "we are smarter than everyone else who does PL, and to prove it we will create a language with no features except go routines". DRY is nearly impossible in Go. If I never have to type "if err != nil { return nil. err }" again, I will die happy. I agree that exceptions are bad, but they decided to create a system that is even worse than exceptions. Implicit interfaces are also stupid. They offer no advantages but make it impossible to have default functionality, another crucial aspect of DRY. Everyone has already whinged about generics enough that go decided to add them, using a design somehow even worse than Java's.
My only real complaint about rust is that async is a mess.
Serious question. What in Go makes it not as correct or harder to enforce correctness?
I understand the points Theo is trying to make and they are valid in their own right, _if_ their actual reasoning was the main point of their decision to port. But they already wrote back a post a year back with their rationale behind their strategy to port. And the first point was that the project had scaled so much that correctness was of crucial importance. Go's loose types and error handling made it hard for them to ensure they shipped correct software to users. This is especially a problem when you deal with I/O and async and ship software that are installed by people individually, rather than running them on servers.
Also I don't think comparing esbuild and Turborepo makes much sense. They are wildly different projects with different requirements. Esbuild is immensely powerful and fast for development builds, but does not surpass things bundlers like Rollup for shipping production-ready code-and it is not it's goal to as Evan has already stated. This is why Vite uses either of them, depending on the environment.
Turborepo on the other hand has to work beyond just individual projects; it has to work and scale for very large monorepos, with multiple apps, packages and dependencies-so the scope is much different from a build tool.
As much as I love your videos, I felt that the points raised in this video/stream were, while valid, exaggerated due to a personal bias against Rust or migrations to Rust specifically. As turbo users, yeah we didn't get much in a long time, but in speaking of this you unintentionally hide that the performance being significantly better isn't also a "feature" that us users benefit from? Yeah the time it took for that performance benefit and the cost of not having other features is what's being pointed at, but that's opinionated; it depends on what a user deems to be worth it and what the team does as well.
Definitely need a followup video; Rust wasn't done justice here.
It will probably never be done justice, he's got a hard on for making rage bait that panders to his Twitch and inner community, which include a lot of Go die-hards and Rust haters (not that that's unjustifiable, just an observation). That's what he (and other streamers) does. They can make up a bunch of bs about how they weren't finding Rust good to work in, but we both know that placebo is the strongest medicine and they are definitely smoking that ganja.
I am more concerned about just Theo's knowledge on the topic, I used esbuild in 2020 it had hardly enough features and support compared to turbo, it took over a year for esbuild to be usable in production for large projects.
Then there is also the huge performance and code quality changes that needed to be made during the process of 15 months, and lastly most people who start Rust projects don't really know Rust as well atleast not all of the team is on the same level, whereas in Go there are hardly any design decisions around architecture to be made, it's all just bad, you won't really gain performance because you spent 30 mins extra adding generics.
Eg, HMR for JS is still not supported in esbuild (out of scope apparently). Also Lazy bundling and incremental computation.
I mean I am not sure if Theo is uninformed or just disingenuous. Turbo has more features, and they have kept up to date with ecmascript changes in the last while and also improved docs and code quality overall substantially. Further they have kept the product working, shipping bug fixes and incrementally improving performance. 15 months for all this is pretty good even assuming there wasn't a language switch, I have seen teams spend 6 months or more on refactoring and such.
Either way as someone who has written millions of lines of Rust, Go and also less but still a huge amount of Typescript it's practically a nonsense video made to stroke ones ego about how they are correct by making their own interpretation of facts.
@SteinCodes - *Millions* of lines of code? 🤔
@@gearboxworks I have been coding for last 8 years, in college I wrote everything from databases to game engines and more. Then a few years professionally in multiple startups. From compilers & parsers to services and machine learning models and apps.
And same for Go but mostly after getting jobs stuff like k8s plugins, controller, or big micro-services(didn't feel micro after putting all the effort).
And lastly there are lots of tests, so many tests. Purely pain but worth it if it kept prod safe.
@@SteinCodes - Let's do the math. Assume one line every 30 seconds. 40 hours a week. No breaks. Nonstop for 8.33 years. That is what it would take to have written "millions of lines of code" (I noted your plural, so 2 million at least.)
And you have been coding for (only) 8 years?
You made some reasonable arguments, but then you leaned into an appeal-to-(your-own)-authority rather than let your arguments stand on your own and revealed your claims to be just another person's likely-biased opinions. I kinda hoped by commenting you would show some humility and say "Yeah, sorry for my hyperbole" but since you didn't I assume you don't recognize it as such.
BTW, I have been coding for over 30 years, most recently 5 years with Go, and I doubt I have yet to write 1 million lines of code. But if I had written 1 million+ lines of code that would mean I spent way too much time writing code and not enough time deciding what code should be written. 🤷♂️
The main reason in adopting rust is adding features without breaking existing stuff, it is the guarantees rust gives in producing correct code, it is not just about the strict system, it is also the immutability by default, the no sharing mutable state semantics, it is the match pattern, the amazing error handling, the need to usually write pure functions ... Your view of rust is too shortsighted.
It’s not short sighted, he’s oriented towards experimentation which has to be shorter time horizons. So to his point, backwards compatibility is less important than pace of experimentation and delivery of value. You’re right in that they’re different values, but wouldn’t you agree that the JS ecosystem values are vastly different from Rust ecosystem?
hes a JS dev give him a break. He doesnt realize the future of web is rust...
@@kamikaz1k Yes experimentation is different, but turborepo is not a product based on experimentation so I don't know why that should be the target.
@@perc-ai not gonna lie bro, you could've used a better argument than actual ad hominem
Rust freaks keep saying "correct code" like that is even a thing that exists. The language is the programming equivalent of a Communist utopia. It's not realistic or practical.
Quite frankly this entire piece is just a testament of how truly powerful Zig is
Just imagine when we get the Zig Zag update lmao
The whole JS/TS community needs to take a step back and objectively evaluate whats involved in building a web app.
None of this project made sense to me. As soon as you're "compiling javascript"... something has gone wrong.
What, are you telling me I should not be using all the 300 great packages only 40 of which are outdated?
the future is rust and JS developers keep doubting it.
@@perc-ai Isn't the whole thesis of the video that JS developers are TOO all into rust?
@@ehutch79 Too much business logic is written in JS and the language is too loose, theres no way to debate this. Rust is the future of software as of now.
Go has better developer experience, but for a bundler, we should push to the maximum. So Rust is the best choice. It's not like every frontend developer should master rust to create websites, so the people behind turborepo can spend a lot of time in it. We already have many bundler btw
I think Rust has better developer experience. Go is just easier to learn.
fight
Go is much better than Python, Java, or JavaScript but I’d say Rust is on top for me
@@kcable194 Depends on what you're doing, as always, right? :) JS is great for UI, Python for ML, AI, data science, etc., Imo, Rust is great for services, long-lived infra tools (like DBs, proxies, message brokers...). I don't like Go, but it's good for tools, where GC isn't an issue. Although, personally, I prefer Rust.
@@tinrab oh for sure, totally agree. I was thinking mostly about toolchains, correctness, refactoring large apps, and ease of deployment. Every language has its strengths and use cases!
Would love to see the followup video. Many thanks for great discussion and hearing from the Rust devs. (So interesting to see how zig is being used...)
It's super cool that they used zig as a build tool. Also, "rewrites are almost always wrong" is the opposite of a spicy take.
Comparing the initial write of a program to having to rewrite it while duplicating exactly various behaviors is not a good comparison though.
Follow ups are great.
Go is the single easiest language to learn and move fast in. Nothing else comes close. Not even TS/JS.
However, Rust does not rebuild everything all the time, like you said. Incremental compilation time are... fine but not good. It is orders of magnitude faster than TS/JS at runtime in real-world applications and produces much more sound code than Golang (or any scripting language like JS), but it is much slower to iterate in.
You may not always nail all the details, but your intuitions are almost always right. Good video!
and the fact that go recompiles so much every time, and it's STILL fast is insane. Really I haven't found a need to get a faster binary in production so far so the iteration of Go wins by far for me
@@milomaz1 I see Go as a Pascal dialect but with curly brackets. In the 80's, adverts for Pascal compilers always had numbers in them. 80000 lines per minute*
* = on a 6Mhz 8086 PC clone.
Niklaus Wirth, inventor of Pascal et al, was famous for not adding features to the compiler if it didn't make the compiler faster compiling itself. Look up Wirth's Law to see his thinking.
Go isn't bringing anything new to the table. What Pascal had back then works just fine, adding a GC makes it even easier to code in. Google could have left that out IMHO. But to me and many others, Go feels too simplistic and the error handling, well, better than exceptions I guess...
One could argue that Rust isn't really advancing anything either. It's like a low-level ML dialect, but without GC. But the mix of advanced old features is about "just right" for the time we live in.
"We came in thinking we could refactor while porting." Ooof... been there. Never, ever mix refactoring with moving/porting/decomposing code. Doing both at the same time isn't porting, it's rewriting from scratch, and it almost never goes well. It's super tempting because no one wants to bring unwanted behaviors from the old code base to the new, and no one wants to refactor old code in place first, but you, and your team, and your company, will all suffer if you jump the gun on this.
@Theo you can install rust / crate binaries and bypass the build, it exists, one such example is the crate cargo-binstall and cargo-quickinstall, pick best for you.
Rust *does* do incremental compilation and most of the compile time is spend in LLVM (the thing that produces the actual assemby) anyway. (And it can be switched with alternative compiler backends like cranelift, which are faster in terms of compile time.)
In terms of dependencies rust normally only caches on a per-project level, which means that new projects (like what you create in the background with cargo install) take a bit longer to compile.
But that can be fixed by using sccache.
Thanks for the video. I enjoyed the video and having another video to counter balance with a point of view on the people involved in the project will most likely be interesting as well IMO.
Rust does do the trick of not compiling things which hasn't changed, it is described as "Incremental Compilation". This doesn't solve the first build of a program, or the time a release build takes in CD, but when working on a Rust project, it isn't _as_ bad. A bigger "problem" is that Rust allows, and the community has embraced, monomorphized generics as the main kind of polymorphism: It is really good for performance, and really bad for compile times.
ci/cd builds still can use incremental compilation
tho it is complicated to setup
@@lame_lexemI have gotten that to work locally with cargo-chef and a multi-stage docker build, but sadly my company is on GCP where it doesn't work. We have also tried with their Kaniko cache, but haven't been able to get it to work.
Please if you have a solution, share it, takes 6 minutes from push to deploy, which is just short enough that you don't want to start something else while waiting, but long enough that it's painful 🥲
Love the video❣ Waiting for the follow up.
Should definitely do that follow up video. My experience with languages like Rust is that yes it'll take longer to develop things initially. However, you will always have more wins when it comes to maintaining and refactoring code into the future and the velocity and correctness starts to compound over time.
By “languages like Rust”, do you mean just Rust, or other compiled languages that don’t necessarily have all of Rust’s downsides ?
Not to be rude but I just don't believe you. Rust is one of the most difficult languages to refactor in. I genuinely believe most people have never actually attempted to build a real product grade product. Rusts entire point is study code. Study code is unchanging code. Unchanging code is borderline useless code.
Theres a bunch of things you can do for incremental compilation of rust and just generally speeding up compilation times. Not the least of which is compiling in debug if you're just checking program behaviour and not performance. Unfortunately with at least one of my projects i need to compile in performance due to that usually being what we optimise for, but you can usually disable LTO linking and such for a very small runtime hit.
would love to see the follow-up video, thanks for offering Theo
18:50 i’d be rly curious to see character count comparisons
go tends to rly tempt ppl to one-line things they shouldn’t
also rust has more “boilerplate” (that’s not actually boilerplate bc it’s the minimal amt of tokens to disambiguify the code sufficiently for the compiler to make as-efficient of a binary out of the code as it does)
but this “boilerplate” (amongst other things) saves devs hours in the long run by avoiding ambiguous code with complicated bugs even getting checked into git let alone pushed live
I am learning go. Loving it
I use TS, Go, and Rust. 💛
@@AdamFiregate me too, was about to respond with the same ☺
Great idea to learn Go, but don't be too fast ditching Node (Typescript of course) 😉...
I will say go has given me a paradigm shift and the learning process is extremely straightforward and fast.
@@AdamFiregate Can't escape TS. Sadly, I gotta use TS for my work.
But Go already does cross-compilation? So why was that even an argument to switch?
What a massive W take here. Very well structured and explained.
Definitely want to see this follow up
Rust, Rust, Rust, Rust 💪
OMG, all your 6th-grader classmates liked your comment, how cute!
@@lunakid12 a
I think blaming Rust for lack of movement is putting the horse behind the cart. I think they think turborepo is close to finished software and they want to tie it down to avoid sliding back in the future. I think they DECIDED to slow down and this decision opened the door to use Rust to effectively ensure stability for the long term.
I think you put it very well. The expectation that you are able to produce new features while rewriting is crazy.
Obviously the team saw it beneficial to move to rust from go, so I'm not sure if there's any problem here.
@@sp3ctum "The expectation that you are able to produce new features while rewriting is crazy."
But whose expectation was that? Definitely not of this video, if you meant that. Theo said new features _instead of_ rewriting (not "while").
oh we sure need a followup video on this
The reason they moved to Rust isn't because it's Rust. The author even said this. There are plenty of benefits to using Rust over Go.
Like...?
Theo is making a completely strawman argument here.
@@VachicorneOld He just doesn't like Rust, which is a shame. I'd be really cool if he learned it. The argument of shipping fast is fine, but not all software needs to be developed like that. And comparing turbopack with esbuild is fine, but esbuild already exists, so what's the problem? If you're gonna build a new transpiler/bunder make it better/faster than that.
No no you don't understand..
engineers needed to do work....
so they translated go to rust
Acme... Also in old cartoons.
Important to know the classics.
One of the reasons they needed to move off Go was in order to support Alpine Linux. It's deeply unfortunate that Go is only now (almost?) ready in this area with a significant bug fixed in the February 1.22 release while not even making the release notes!
Go language developers already showed that they don't care about correctness, language consistency, and support for what they deem "niche" platforms like Raspberry Pi (fucking lol). They'd rather write a 150 page blog about the pitfalls of the Go language.
Theo leaving us with cliffhangers?!? Aaaahhhh!
OFC we need ANOTHER video, we have to know what the Rusties have to say now! Can't leave us hanging like this 😄
I have written both Rust and Go extensively. I think Go is the most perfectly balanced language.
So Theo has negated the time Turborepo has saved? Gottem
More videos please. Im in the mist of choosing Rust, Go, or C#.
You can use rust with mingw as well, which is better because it's compiler is not propietary
Theo is a broken record at this point, for him how fast you ship something is more imoportant than everything else, fair enough, but I would prefer something that's reliable in this modern world for a change.
Reliable is a moving goal post and rust is resistant to change. Rust is just too slow to develop and refactor to be useful. Build any app larger than your to-do lists, and it falls on its face every single time. That is why rust isn't gaining popularity as people attempt to adopt it. It's a false bill of sale.
So just to get you straight you want a slow to change but stable tool for one of the most changing fields in CS/IT web development ( and especially JS/TS ). Well wish you and the people supporting this tool a lot of luck when the new hype comes around the block and they take 6 months to implement it only to find out the hype is already in it's dusk.
@@EmiNNsoNify Who says its going to be slow ? If it is, by how much ? Talking about Rust specifically, I haven't found it to be very slow to change or iterate over, it gives you a lot of confidence that things won't break under you, the same reason why people use TS over JS, would you advocate the usage of JS over TS because it lets you move faster ? Probably not. Its about balance, and Rust in my opinion is a better option for anything other than frontend dev, even over Go, but thats just my opinion on my experience, if you look through the other comments here you'll find a mixed bag of opinions going either way. Rust is fairly new so the jury's still out, I get where Theo is comming from but I don't really agree with his take, sometimes to move forward you need to step back a little and regroup.
@@jonnyso1rust isnt better than go for 99% of backend usages
@@martinpata2899As I said, that's my opinion, maybe I just put more weight into the benefits Rust overall design gives.
What about Nim language? I think it should be also considered besides Rust, Go and Zig for creating useful tools efficiently. It's like marrying simplicity of Python, strength of Ada, typing of OCaml, with sprinkle of crazy metaprogramming capabilities and interchange-able GCs. You can even drop one if you want.
Nim shouldn't be considered a competitor for Go or Zig. Go is a simpler and non-OOP competitor to Java and C#. Zig is a C replacement. Nim, like Rust, is a C++ replacement.
@@TJackson736 Not necessairly, since Nim is so flexible that you can compile it to C, C++, ObjC or JavaScript. Additionally, you can interchange GC. You can even use Go's one...
Nim is a different category than Rust, Zig or Go, because you can tune code to be between all of them at the same time. Plus metaprogramming capabilities in Nim are really powerful.
I really like Nim but am somewhat discouraged by the lack of developer adoption and momentum.
@@thepatzer That's chicken and egg problem. Without people test-driving language there won't be any usage and/or adoption. Simple as that. Try it :)
I definitely feel like NextJs is the odd framework out now avoiding Vite.
IMO Nuxt and Hono (as it expands with HonoX) have some of the nicer architectures. Basically a composition of vite plugins and WinterCG middleware 😅
Fun fact: I made my own compiler in Python that outputs bytecode for a custom VM also implemented in Python, and it can compile and run faster than Rust can compile. Hell, the test suite of ~200 tests runs faster than Rust can compile "hello world".
he built the project and ran a LoC tool on the repo--of course it's going to be higher, it's including all of the source from the libraries they used in the `target` folder
Yup, and he ignored the fact that they caught a number of undiscovered bugs in the Golang code.
I'm wating for Rust to Mojo migration
what would be the benefit?
@@cysia3683 It was a joke ;)
I don't see from the article why the moved over to Rust. It's the Enums? :D
Theo, I like you, but I think you are making a strawman argument here.
1 - Rust has incremental compilation, while it is slow compared to Go, if you don´t know that Rust has incremental comp, maybe you should learn your subject before.
2 - If you summarize their reasons to move from Go to Rust only because "they wanted to move to Rust", maybe you have not completely understood their position and reasons.
I think that your opinion here is quite biased, your mindset is gear toward fast moving and fast experimenting solutions, while Rust is more focused about correctness. The benefits of Rust go beyond speed (which in 99% of the cases will land marginal gains vs Go).
He has a personal vendetta against Rust, the fact that he resumed every point they made in the article to “ackshually they just wanted to write rust because it’s trendy” is shocking and mind boggling. Biggest L take I’ve seen so far Theo 🎉
The follow-up video with the corrections will be very important. 😄
I am interested in the followup
21:15 I think this type of assess could much better be discussed in an interactive interview with the Rust people from Vercel. Have you tried contacting them?
Definitely going to need that follow up
11:40 tar format with compression?
did anyone else notice the number of hours saved go up by 1 at 2:43?
"we're not moving forwards here" -- yes, crabs primarily move sideways.
Please do the follow up, because I as well don't think you had the right angle and flat wrong with certain items; However, the general critique was not unfair and a good question to ask.
Gotta watch out for a cache-hash mishmash mismatch !
When you dress up a code rewrite like this, then any migration never made sense. Rewriting code always takes time and you don't want to release more functionality then. Not to mention that you can only evaluate the rewrite itself when they start creating functionality without the baggage from the process itself.
Also, not every rewrite is to make the product faster or more functional, stability and scalability over time are also reasons for rewriting.
Should have been haskell, sorry not sorry.
Probably Go is more than enough for any JS dev tool. Rust is good when you need to squeeze the last bits of memory and cpu cycle.
Am currently at war with the mighty borrow checker! I hope I conquer it
banger
10:26 environment variables compiled in code???
aren't environment variables decided by program that executed program (look in execve man page for linux, don't know about windows)?
We wrote a compiler in rust in 1/4th the time it took to write in go. Depends one what you are writing. Also, every line of go I write makes me hate myself.
I'll just build my own JS tooling on PHP because F it at this point
Rust prevails 🦀🦀🦀🦀🦀🦀🦀🦀🦀🦀
100000... more like 25000 since 75% probable will be "if err!=nil{ log.Printf(err)}"
!=, but yea :D
To be fair rust will be 75% of ?, map, and_then, or_else, match and you'll like it !
Just write everything in C++
nice video thumbnail!
25:10 whoa ok that’d be rly cool
I don't find the comparison of the esbuild readiness because of go vs. a working project in go rewritten in rust while maintaining a working project in go. If you should comare this in a more fair manner, you should probably have compared it to swc, which was written in rust to begin with, the swc project has its own "unfairness" too it - as it aims to be a drop-in replacement for babel, so the API was "fixed" and not designed to be easy from a rust perspective.
Big Rust energy. But to be serious, this feels like a change because of technical reasons kind of move. Like knowing you missed the exit so you turn around immediately at the next rest stop. I doubt it is a golang problem because someone out there can make it happen. Whatever it is they need to focus on the goal not the implementation. As a programmer I focus on implementation but my higher ups care about goals.
Its hard to see a ROI of 2 years of a team of engineers thats shorter than the lifespan of turborepo. Specially playing catchup due to lack of progress during that rewrite.
Make follow up video
"Follow up coming soon!" like when?
Imagine just using Vite.
I kinda wish that sometimes when you do start a rant, just google first, just in case your knowledge is outdated already.
I'm definitely interested in the follow up. My take is there was a little bit of 'not invented here' and some naivety around opportunity cost.
Seen it many many times new team takes over a system project, code is critised and a rewrite is proposed sometimes its justified, sometimes the rationale can be shakey.
A consideration to think about is skillset of team vs market rate of engineers as they attrition out
Guy who ran away from using Go says everyone else should stick to it 😂
Imagine if they just use Vite and wait for Rolldown
nuxt mentioned
Personally, I don't think a fast development cycle is necessarily a good thing. I'd rather have features that take longer to ship if I can be sure they're stable and well thought out. I think the constant chase to "move fast and break things" is one of the biggest problems in the JavaScript ecosystem.
I regret that Zig isn't getting more hype.
@fried-chicken-448 I'm talking in general about the situation in tech, not Vercel.
Since I discovered F# I am more excited by not hyped language. If Zig is not getting more hype I need to look at it. Haskell and Ocaml seems interesting too. F# being very good I expect Ocaml and Haskell to be good too (ML family)
@@fsharplove FP languages aren't popular so this is nothing new.
At least it gets segfaults.
I am so glad that you focused on the ROI aspect in this video. It rarely gets mentioned in blog articles about such big shifts in technologies / frameworks. They are mostly only about the challenges and benefits of the "rewrite". I am looking forward to your reaction to the reaction video about the same topic, because I cannot imagine how burning ~1-2 M USD of engineering time will be worth it compared to the solution in Go.
On another note, I don't agree that this is not the responsibility of the engineers who think about such changes to know if its worth it. I believe it's one of the most important aspects of being an engineer to think about the tradeoffs, technical or financial. It _is_ part of your job to know when the business will realize the value that you will spend on the change, and if the answer is never: stay with Go.
I think the talk we should all be having is how impressive is Go with such a small footprint able to achieve so much.
controversy
I am moving from C++ to Rust. So the Error Handling is far suporior.
$> rustc --explain
Pretty need.
@2:37 so what you’re saying is devs will no longer have time to watch your videos
2:39 Sooo, your saying that you have nullified all the hours turbo has saved humanity.. 😉
The JS ecosystem values are vastly different from Rust ecosystem. Rust software is much closer to bulletproof software than application software. Go on the other hand is designed precisely for minimal complexity, which lends itself to experimentation well.
Not everything needs to be correct. But most things benefit from being faster (both to write, and to run).
I think you should invest some time to understand some fundamental. Your opinion is valid but it's an end users opinion always wanting more instead of wanting a better experience
But how many millions of hours were spent trying to set it up and then maintain?
Moving to rust could have made sense if there were performance bottlenecks, but it felt more like a rewrite the libraries in rust and call into from go, not fullrewrite right off the bat for no gain?
Say the hashing, that's offen a memoery thrashing operation casue of how much memory you need ot run too, moving that part to rust makes perfect sense to not have GC work, but does the rest matter? Who know?
What could have been interesting in typescript projects would be moving to assembly script and compiling /that/ to see how well the transition to native speeds go ?
18:00 bro doesn’t get it yet
(still very interesting stuff but clearly theo doesn’t understand how rust is different as a paradigm shift in programming not a flavor of the month)
Zig mention!
Over-engineering?
Totally agree Theo. Huge amount of effort spent delivering a total non-feature that *might* allow them to move more quickly.
With how slow iteration is in rust due to compile speeds and design intrusive types, I really doubt their dev speed will increase.
Hopefully I’m wrong.
It’s really telling that while porting the entire codebase no significant improvements were noted to call out.
based
tl;dr: we wasted a bunch of VC money lol
I think we can say at this point the turbo repo team is in way over their head 😂😂😂
Why are you all incapable of just keeping your repos to manageable sizes