I find the article to be compelling. The firm I work for is converting a large code base from C++ to Go. We are seeing a huge performance improvement. We don't have to use generics to solve language problems. We aren't coding defensively. And, the team is actually enjoying the process and look forward to when we are completely on Go.
@@danielchettiar5670 Opinion (I have switched to Go from C & C++ for many projects): C++ takes extra effort to coax the performance gains out of it. If you're doing things in parallel in C++ you have a lot to keep up with. One of the advantages of Golang here is that it's compiler will work out a stronger solution for concurrency than most C++ engineers can put together in a reasonable time. So, you get ~97% of the best possible performance with a few lines of code and move on. Your constraints will be I/O and Golang has good tooling for handling those kinds of problems compared to many legacy languages.
@@danielchettiar5670 C++ asynchrony is not a well defined story. I suspect that they have a lot of complexity in this arena that is addressed by the migration to Go.
From the post, they have a "content engineer" for their blog posts, so I guess when you have enough spare money to hire an extra job role to write blog posts then it's not a problem
I just want to say that i started learning GO then i discover RUST and i love it, but for me tooks a loooot of time to get one simple thing done with rust. For my work I make a few projects in go and was more easy once that i learn the rust basics. For me go is the tool while i learning rust and make the switch between this two great languages is more easy and i can get the job done. Thats is the thing that count. Be happy work happy.
Among the things they seemed to not have learned, is that doing all of this work for little to no benefit is a waste of time. Go is fine, and that roadmap could have probably been done in the tine it took to do this.
If you wanted to build it in such a way that it could be run on multiple platforms and be installed via npm then you could build from rust to the wasm32-wasi target then run it via something like wasitime, the only downside with that approach is that it's not 64bit
That would require an additional dependency; wasmtime. They pointed out that they didn't even want to release with a dependency on glibc (which is pretty standard), because it wasn't available in all Linux distros, especially those used for CI, where Turbo is going to be utilized for the most part.
1:04 - I ported a library from Go to Rust that used fairly heavy syscalls, and surprisingly saw substantial improvement in overall performance. Unfortunately, I didn’t dive back into the Go side to actually compare, but I assume that there’s a some strange system level locking that has to occur with Go’s runtime scheduler (runtime.LockOSThread()). Total speculation concerning CPU performance.
coming up: why we are porting back to go and then: how we are porting back to go seriously, all this article is, is them complaining how everything sucks when you try to write your program in 2+ languages at a time. they should have stayed with go, go it's more than fast enough for a build system.
The test part: I understood it to mean that didn't have tests and advice having test before you start PORTING. Similar to how you would when "refactoring".
Other developers spend all their time managing and load balancing their fleet of VMs. Rust, C++ and Go developers just run everything on a single cpu core.
For all of the shenanigans they go through during the article, I still don't understand the reason why they move from go to rust. What makes it "more maintainable" and "allows them to handle new features better" exactly?
I worked in a team who attempted a full rewrite, from a site written in php and prolog and perl to a site written in java. It was a mess, the java team was chasing the moving target all the time, and us in the ETL team were also chasing the moving target and the mess of old database they had.
Instead of doing Full Rewrites its better to move to a Micro Modules First approach while doing Death By Attrition on all of the existing systems. This means you try to move more code/logic into custom code modules, focus on thin presentation layers, and slowly do attrition of what's already in place until you can simply just shut it down & nobody notices.
This sounded like such a hassle to do. How much performance is boosted? 2x? 3x? Also, didn't they have a junior dev constantly telling them to use Rust in the first place?
I've been that dev so many times. "Hey guys, we should do this." "No! I mean, we agree, but we can't, so no." *a few years later* "So we did the thing you wa- oh, right you left a year ago..."
Its not just performance, Go error handling is tedious and error-prone. If you've used other cli tools written in Go (such as kubectl) you would've seen how the standard error handling is lacking. Turborepo has had problems that stem from it. Its not impossible to use a completely different paradigm for error handling and reporting in Go. One example is Terraform, which have switched over their error reporting mechanism several times, starting with returning more complex diagnostics objects, then and switching to full blown request/response objects (you report errors by using imperative api such as `response.Diagnostics.Append(...)` and then at the end you use `if resp.Diagnostics.HasError() { return }` In Rust its possible to build abstractions for errors that lead to clean tracebacks pretty easily (e.g. anyhow) and traits such as `From` can make the entire process much more pleasant - and more importantly, impossible to mess up. (Its so easy to forget to add diagnostics correctly with a mutable API and end up with "success" thats super hard to debug, which has happened before in turborepo)
The real irony is that Go builds far faster than Rust. Also I found this ironic quote on their blog: "At the heart of Turborepo is a very simple idea: never do the same work twice."
Continuous Licensing in itself is cancer. Once the license holder pulls the plug, any product using something with the licenses will be dead in the water. Look no further than the games industry. How many good games are simply not available anymore, just because some artist somewhere said "Nope you are not allowed to use my song anymore", despite said song only being maybe 1 or 2 % of the end product? To make it clear. I have no problem with people wanting recognition or even compensation (Like a one-time fee) for their work. Where I have a problem with it, is when the License requires continuous payment or Rules on how you can market your product. Because now the license holder gets a significant amount of control over your project, without adding further value to it. So over time, what you get becomes less and less in comparison, to what you pay.
It is licensed under LGPL (Lesser General Public License, not Library). LGPL allows glibc be _dynamically linked_ into software that may or may not be (L)GPL licensed. However, they didn't want to have the extra dependency, snd rather would need to statically link the library, meaning copying the interfaces and library binary _into_ their software for re-distribution, which is not allowed under LGPL, unless you also release your software under (L)GPL. if glibc had used MPLv2 (Mozilla Public License) then they would have been allowed to.
You should stick with Go and build something. I can write Rust code but if you already started with Go, just stick with that. I only switched to Rust for my specific use case. I'd use Go in place of Java, Node, Python, for server side stuff if I'm doing web stuff. Systems programming, reverse engineering, etc, I'd use Rust.
1 year into rust rewrite: Why we are switching to Zig from Rust.
1 year into Zig rewrite: why we are switching to JDSL from Zig.
@@rj7250a1 year into JDSL rewrite: Why we are switching to Carbon from JDSL
@@logantcooper6 that is impossible, JDSL is the greatest programming language of all time, only a genius like Tom could create such language.
@@rj7250a That's until someone created JDSX(adding dynamic features to jdsl).
Can anybody explain this meme about JDSL and Tom?
"the segfault comes from the go rt itself"
At this point I would give up programing and start selling art on a beach
We have inside joke at work where we say “I should’ve been a gardener” whenever faced with a complex problem. Selling art on the beach is brilliant 🤣
como falar que é Brasileiro sem falar que vc é brasileiro.
I find the article to be compelling. The firm I work for is converting a large code base from C++ to Go. We are seeing a huge performance improvement. We don't have to use generics to solve language problems. We aren't coding defensively. And, the team is actually enjoying the process and look forward to when we are completely on Go.
Performance improvements in Go over Cpp? Is the Cpp code written badly?
@@danielchettiar5670 either that or they've managed to heavily parallelize the program due to Go's goroutines and native concurrency primitives
@@danielchettiar5670 Opinion (I have switched to Go from C & C++ for many projects): C++ takes extra effort to coax the performance gains out of it. If you're doing things in parallel in C++ you have a lot to keep up with. One of the advantages of Golang here is that it's compiler will work out a stronger solution for concurrency than most C++ engineers can put together in a reasonable time. So, you get ~97% of the best possible performance with a few lines of code and move on. Your constraints will be I/O and Golang has good tooling for handling those kinds of problems compared to many legacy languages.
It is quite common, when your team is made by Java developers.
@@danielchettiar5670 C++ asynchrony is not a well defined story. I suspect that they have a lot of complexity in this arena that is addressed by the migration to Go.
“Have you finished the upgrade yet?”
“Nope”
“Why not?!”
“Working on the blog post”
From the post, they have a "content engineer" for their blog posts, so I guess when you have enough spare money to hire an extra job role to write blog posts then it's not a problem
they rewrote in rust because they wanted to do it in rust, there is no other reason
For the meme.
Yep
Even if one exclude the low-level aspect of Rust, the remaining features would still be desirable and hard to find in other (popular) languages.
Yes. It would be good if they said that though.
why you blowoff the secret lil bro
While i personally think Rust > Go: Why did they rewrite in the first place? Dont see any valid reason to do this... too much free time?
They rewrote their codebase to rust to justify writing this article
They have an entire prior article explaining why they'd like to use Rust instead of Go. Mostly: Not using CGO & they'd be happy using Rust
@@ViníciusMiguel-q1gcgo is not that bad.
I just want to say that i started learning GO then i discover RUST and i love it, but for me tooks a loooot of time to get one simple thing done with rust. For my work I make a few projects in go and was more easy once that i learn the rust basics. For me go is the tool while i learning rust and make the switch between this two great languages is more easy and i can get the job done. Thats is the thing that count. Be happy work happy.
9AM (BR Timezone) and we're already here.
Among the things they seemed to not have learned, is that doing all of this work for little to no benefit is a waste of time. Go is fine, and that roadmap could have probably been done in the tine it took to do this.
If you wanted to build it in such a way that it could be run on multiple platforms and be installed via npm
then you could build from rust to the wasm32-wasi target then run it via something like wasitime, the only downside with that approach is that it's not 64bit
That would require an additional dependency; wasmtime. They pointed out that they didn't even want to release with a dependency on glibc (which is pretty standard), because it wasn't available in all Linux distros, especially those used for CI, where Turbo is going to be utilized for the most part.
1:04 - I ported a library from Go to Rust that used fairly heavy syscalls, and surprisingly saw substantial improvement in overall performance. Unfortunately, I didn’t dive back into the Go side to actually compare, but I assume that there’s a some strange system level locking that has to occur with Go’s runtime scheduler (runtime.LockOSThread()). Total speculation concerning CPU performance.
Full re wriret sounds like: "Bulldoze the city this time it will be a better place to live in. "
LOL. They seriously wrote an article on how to parse command argument, serialize a json and spin up a child process in Rust.
coming up: why we are porting back to go
and then: how we are porting back to go
seriously, all this article is, is them complaining how everything sucks when you try to write your program in 2+ languages at a time.
they should have stayed with go, go it's more than fast enough for a build system.
The test part: I understood it to mean that didn't have tests and advice having test before you start PORTING. Similar to how you would when "refactoring".
Rust, C++, Go developers, spend all their time rewriting projects and measuring performance 😂.
Other developers scale horizontally.
Once you Rust, you don't Go back. C++ what I did there?
Other developers spend all their time managing and load balancing their fleet of VMs. Rust, C++ and Go developers just run everything on a single cpu core.
@@Mortyst c++, go, rust developers are underpaid.
For all of the shenanigans they go through during the article, I still don't understand the reason why they move from go to rust.
What makes it "more maintainable" and "allows them to handle new features better" exactly?
Would you drink toilet water?
@@mckrack I assume Rust is the toiler water (because metal pipe is where rust meant to be)
Then why would they want to drink toilet water??!
@@muhwyndham You assume wrong. It is a reference to movie Idiocracy. th-cam.com/video/kAqIJZeeXEc/w-d-xo.html
Feels like a huge flex without a good reason to me. I dont see the problem with Golang tbh.
I worked in a team who attempted a full rewrite, from a site written in php and prolog and perl to a site written in java. It was a mess, the java team was chasing the moving target all the time, and us in the ETL team were also chasing the moving target and the mess of old database they had.
Rewrite a website in Java in 2023 seems weird to me
Instead of doing Full Rewrites its better to move to a Micro Modules First approach while doing Death By Attrition on all of the existing systems. This means you try to move more code/logic into custom code modules, focus on thin presentation layers, and slowly do attrition of what's already in place until you can simply just shut it down & nobody notices.
This sounded like such a hassle to do. How much performance is boosted? 2x? 3x? Also, didn't they have a junior dev constantly telling them to use Rust in the first place?
😅
They lose performance in the first execution and gain performance in updates, it will probably not be more than 20%
So dumb move
I've been that dev so many times.
"Hey guys, we should do this."
"No! I mean, we agree, but we can't, so no."
*a few years later*
"So we did the thing you wa- oh, right you left a year ago..."
Its not just performance, Go error handling is tedious and error-prone. If you've used other cli tools written in Go (such as kubectl) you would've seen how the standard error handling is lacking. Turborepo has had problems that stem from it.
Its not impossible to use a completely different paradigm for error handling and reporting in Go. One example is Terraform, which have switched over their error reporting mechanism several times, starting with returning more complex diagnostics objects, then and switching to full blown request/response objects (you report errors by using imperative api such as `response.Diagnostics.Append(...)` and then at the end you use `if resp.Diagnostics.HasError() { return }`
In Rust its possible to build abstractions for errors that lead to clean tracebacks pretty easily (e.g. anyhow) and traits such as `From` can make the entire process much more pleasant - and more importantly, impossible to mess up. (Its so easy to forget to add diagnostics correctly with a mutable API and end up with "success" thats super hard to debug, which has happened before in turborepo)
that junior dev 😂, aka primeagen fanboy, aka me
youtube makes all my prime videos at 360p :(, the name is.... pixelagen
I think on the testing for port is still good, but making sure you are testing E2E and Integration, not new tests inside the Rust stuff.
@14:30 See Erlang for many years of understanding that...
15:20 and this my friends is a sheep
How do they know when people interviewed with the NSA?
The IRONY of having a Go/Rust "fast" build system for JAVASCRIPT/TYPESCRIPT (implying they do JavaScript/TypeScript stuff) 😂
The real irony is that Go builds far faster than Rust.
Also I found this ironic quote on their blog: "At the heart of Turborepo is a very simple idea: never do the same work twice."
@@michaelslattery3050 bruh 😂
@@michaelslattery3050Loooooooool ☠️
TurboRepo purpose is to make development performance better? It seems they not even know what they are working with
They should have migrated to HTMX instead.
28:30 the FEDiverse banning FEDs...
Love your content and thanks for uploading on TH-cam
Continuous Licensing in itself is cancer. Once the license holder pulls the plug, any product using something with the licenses will be dead in the water. Look no further than the games industry. How many good games are simply not available anymore, just because some artist somewhere said "Nope you are not allowed to use my song anymore", despite said song only being maybe 1 or 2 % of the end product?
To make it clear. I have no problem with people wanting recognition or even compensation (Like a one-time fee) for their work.
Where I have a problem with it, is when the License requires continuous payment or Rules on how you can market your product.
Because now the license holder gets a significant amount of control over your project, without adding further value to it.
So over time, what you get becomes less and less in comparison, to what you pay.
Is glibc not LGPL (Library GPL) but raw GPL? Surprising.
It is licensed under LGPL (Lesser General Public License, not Library).
LGPL allows glibc be _dynamically linked_ into software that may or may not be (L)GPL licensed. However, they didn't want to have the extra dependency, snd rather would need to statically link the library, meaning copying the interfaces and library binary _into_ their software for re-distribution, which is not allowed under LGPL, unless you also release your software under (L)GPL.
if glibc had used MPLv2 (Mozilla Public License) then they would have been allowed to.
Why is it that you do not link to the original articles?
He did. It's in description.
Great article show how to move to other language with successful !
best elocution in the game. 💯
The only way to get good at anything, is keeping at it.
I've never heard the term "Roman writing" before. What is that?
From Rust To Zig
Mr Primeagen, do you now or have you ever worked for...THE EN-ES-AY?
I want to C Rust Go
7:42 are you actually surprised? :P
Windows copping whose Ws right there
my JS framework is better than your JS framework
Where are the stories from. C# or Java to CPP?
I think that make the process of programming slower is no funny to the developers.
9:01 dont support windows? Prime!!!! Omg man LoL
Hello World
Honestly after doing Go I take it back. Go is pretty good because it's so boring.
i thought you were cool primagen
12:06 is a huge L for Prime
I think he was referencing Ballmer
Should've been clearer, GPL is the GOAT
RIIR.
I love that TH-cam suggest that I can click a button and translate this to English.
RIIR is translated to RIRR. The old Rewrite it Rust Rust.
Rewrite It In Rust, for anyone who wasn't helped by the translate feature...
rewrite GO in RUST :)7
TBF, NSA is pretty cringe, what with trying to backdoor public key cryptography and all.
Go ➡️ Rust
then
Rust ➡️ Zig
then
wtf 😒
no one is moving from rust to zig
soon they will be
@@abanoubhawhy?
There will be a shiny new thing to try
When you say "Something like Protobuf" what else can it be if not Protobuf.
FlatBuffers, bincode, Thrift?
@@ViníciusMiguel-q1g ...and Cap'n Proto, designed by one of the creators of Protobuf.
Also msgpack, postcard, CBOR, ... and numerous others. Depending on what "like" means.
wow wa ve va
Damn it, I just switched from Learning GO to RUST.
You should stick with Go and build something. I can write Rust code but if you already started with Go, just stick with that. I only switched to Rust for my specific use case. I'd use Go in place of Java, Node, Python, for server side stuff if I'm doing web stuff. Systems programming, reverse engineering, etc, I'd use Rust.
What will you use Go/Rust for? Rust has fewer jobs than Go in the web space anyways for now, if that matters for you
rust for algo trading!!
lol triggered go shills. not sure which 1 is worse, the go community or the rust community.
Go is die before it born 🤣🤣🤣🤣 C# is better than Go