In real world rust is never actually fast, all lies from the cult. Go just beats it easily with a much better user experience. Their flagship server Rocket gets crushed by Go fiber in every area, including speed.
@@SumoCumLoudly Rocker is not really 'flahship server', no idea why you'd want to misrepresent rust here :P Try comparing fiber to actix web. I have to admit tho, rust is super hard and performance gained from it (i've no doubt that it can outperform go any time) still might not be worth it for most people.
@@NoxyYT theoretically you can write rust code to match c++, in reality tho the code just doesn't exist because nobody can write it. Go pick up the popular rust library for whatever area you can think of and compare it to the c++ equivalent, its nowhere near as fast, chances are it won't even be as fast as the Go equivalent never mind c++. It's difficult to write slow code in c++, and it's difficult to write fast code in rust. Most c++ programmers handle memory as second nature, they don't need protection from themselves. I can see why companies would buy into the idea of enforced safety, but unless lives depend on your code, I wouldn't even give rust a second thought, the juice isn't worth the squeeze as they say.
The Rust code has a shared HashMap behind a mutex. That's most of the problem... You're completely removing any benefit of multithreading, because your other threads can't do any work when the HashMap is in use (which is all the time). You could try changing it for an RwLock, because most of the time, you seem to be only reading from it. Another option is to use a concurrent hashmap, like DashMap, which tries to be an easy replacement for RwLock. Other (less important) issues are: You're heap-allocating all of your futures from Listenable because of async_trait, and you're spawning two tasks instead of one per connection, increasing pressure on the task scheduler.
I'm more impressed with the tests you plan and write to make these comparisons than the actual results. I am baffled by the amount of time and work you just put into stuff like these. And the best part is, you do this because you're just crazy and love shit like this. Love your videos man, inspiring .❤️.
Hm, I'm actually not immensely surprised about the comparison between Rust and Go in the end with Go being actually fast with immensely lesser effort compared to Rust. There is a good chance that a highly optimised Rust version would perform even better, but at some point you gotta ask yourself how fast do you actually need it to be and is it worth it. Thank you for the video, prime!
In my previous job i got a little exposure to Go and i really liked. This kind of informative videos solidify my decision to get better at Go and have the right tool for the right job (because getting to work in Kotlin backend outside of android apps is going to be really hard)
I've been writing Go professionally for 9 years. It's really really good. Most of the time the right way to write the code is very straight forward and obvious... and then it performs really well with no optimization..... The only performance problems I've had were logic-based, not language-based. For example, this one API endpoint made 12 database calls, when it could have been consolidated into just a few. I've never been like "oh, this part of the code is doing too many loops and copying too much data... we should rewrite the logic so that it'll be faster" ... nope. 100% has not happened. *and* you can understand the code when you come back to it in 6 months or a year, or if you're new to the codebase.
@@quentonwong408 having worked extensively in both Go and Django, Go all the way. Django has a lot of footguns and things that'll slow down productivity to a crawl. Django's migrations take FOREVER compared to running similar migrations in Go or Elixir or Rust. For example, we had ~200 migrations that would take 4 minutes to run on a arm64 fully-specced macbook pro. We had to spend ~4 days of an engineers time to consolidate those migrations down to 50, and they still take ~1 minute to run. In my Go app with 100 migrations, it takes about 5 seconds. In my elixir app with ~400 migrations it takes about 20 seconds. That alone should dissuade you from using django. Then we get to just how slow python is in general and it starts to look less and less usable.
Would love to see if any highly experienced go/rust people would take the challenge to reimplement or refactor what you wrote while you do a video measuring the time, discussing what optimizations were made, and which language truly blazes and which one got caught up asking for feet pics on the internet.
Well go for me is easy as Ruby to learn, learning right now. It goes well though i'm warming up before going fully into 8hours routine daily. I think I can get there in a week from now
Well what stops me right now that some time I read, watch some content i need to learn till I finish, a little less coding, beside I participate in Rails hackathon and i wanna mąkę head space for that, do less for moment
This is actually the best case made I've heard for Go. Simpler to write, reasonable performance. I would go for it for my next project (even though I've already chosen rust for said project).
as a person who has written a lot of rust and go, I prefer go. its easier to teach people, easier to maintain, and easier to read IMO. you get like 80% performance of Rust without the large up front Rust knowledge cost and slower development speed and turn around (compilation is much slower and active development recompiles a lot).
Slick content my guy. Love it. I'm glad someone has (mostly) unbiasedly confirmed what I've seen in many years of engineering software. Go is just faster and easier to write a blazingly fast solution to a problem in. There's very few foot guns, very few things to learn, and it compiles and runs your tests BLAZINGLY fast. IMHO if a language can get you even 80% of the way to the _fastest_ solution in ~20% of the time, then that should probably be your daily driver for latency sensitive applications.
I now have a working version of Rust that is several times faster than go. But it took significantly longer. Now I'm not sure if that is just a requirement of getting good at a language, whereas go feels like most languages have already used.
I do love working with typescript but go has been looking interesting for a while. If it's as easy to write and gets you free performance it I thinki might look into it. Very impressive seeing it compete against organic home grown rust.
The biggest problem for me with NodeJs API's has been unavoidable blocking code. Yeah, even after we async all the things, some things that need an immediate response are going to block. With Go, you can stick every request in a goroutine and not have the spillover.
I think the abstractions for concurrency chosen in go have democratized multi-threaded programming. Before go getting threads running in parallel was an arcane art only tried in very rare circumstances by the top 1% of programmers. Then go came along and showed how normal programmers can also write fast, safe, multi-threaded code.
I am so glad I found this channel!! This is truly prime CONTENT right here, as well as it being helpful and educational is a nice benefit! TY TY for putting in the time and effort!
At this point it would not be any faster than go to be honest, and if there are any calculations (did not dive into the project to realise that) there is no point (elixir developer here).
@@freeo6242 Short answer: What do you define performance wise. Are you looking at something that is computationally heavy or something that is latency dependent. Go fits the former while Erlang (and Elixir, both of which run on the BEAM VM) fits better for the latter. Longer answer: Erlang/Elixir (and by extension the BEAM VM) and Go both offer similar concurrency models (userspace threading) but the latter is "better" if you are reliant upon heavy computation. Some exceptions exist here as you are able to hook in more performant code written in another language using Erlang's Natively Implemented Functions. Erlang/Elixir enforces preemption through reduction counting, which basically counts how many times a function is executed, whereas Go is still largely cooperatively scheduled. To my understanding Go requires the compiler to insert checkpoints in the code to yield execution of the userspace process back to the scheduler. There was a proposal for adding preemption features to the Go scheduler but I'm not quite sure what the status of that is. As a result of its preemptive-like scheduler, Erlang (and by extension Elixir and other languages on the BEAM VM) have been described as soft-realtime. This in simple terms means that Erlang is capable of low latency workloads but lacks the ability for throughput oriented workloads, Go is the opposite of this.
@@ThePrimeagen SIR, YES SIR! RUBBING THE COCONUT OIL ON MY GOPHER RIGHT NOW SIR!!!
2 года назад+4
Prime, you're the best! This type of content is really gold, as per usual. Thank you for doing this videos and being informative while also being completely mad (as a scientist)!!!
the one niche use Rust has is perhaps for writing device drivers. Go is a great middle-ware language - gives a lot of bang for the buck because it's not as complicated to learn as C++ or Rust.
Hey bro, that's awesome, please do a comparison with Bun I'm sure you're the only guy on whole RUclips (or even Universe) who could do it the right way!
your videos are the best, they have the perfect mix between incredible useful info and fun, more like this please! :-) looking forward for some Frontendmasters course for this Rust vs Go vs TS topic.
I haven't used Rust much, but I've used Go. One noticable thing that I've seen is that the compile time in Go is insanely fast, while Rust really takes its time (maybe because of the optimizations it's doing), but for a "normal" end user, I think Go is the clear winner at least in that deparatment. And I thiink Go's concurrency is famous for a reason (as you also mentioned), and it's REALLY built-in to the language and flows with it. Great and informative video BTW
Concurrency. Does it matter if concurrency abstractions are built into language or available as a library...I don't think it matters. Maybe in a more opinionated language, but Go is not very opinionated imho. It's just this C with lipstick on.
I can't say I agree. It's not just a matter of being built into the language but the ease of use it gives. As I said, I can't talk for Rust, but the code I've seen in videos to implement something like channels in Go, IMHO, is wayyy more complicated than Go
Great work. I think the advantage of Rust from a ease-of-programming perspective seems to be Cargo and the infrastructure for writing tests. It would be great to see a comparison between these three languages in terms of how packages are managed and how conducive writing tests would be. Also, generics. I always enjoy these more academic type videos. I’m looking forward to whatever you release next.
@@ThePrimeagen well, TS has the npm where you could find literally everything. Also, almost any 3rd party service has an integration/SDK with js/ts. I wouldn't say that it's an easy choice
maybe it's more about community than the ecosystem, but this thing really matters. I know a guy who tried to make a dapp/blockchain project on C#, he suffered a lot
Go's module (dependency management) system is really solid these days. Testing support is fantastic. Built in testing suite, performance testing, fuzzing, runnable examples, code coverage..... And it even has generics now.
You rock btw, I wish I knew you personally as a mentor that’s how much I value your videos. I think you are a truly awesome person, and engineer and you should be proud of that :)
Just on the TypeScript implementation. Not sure if you're measuring networking (id assume the gameloop would be the most pressing thing) but id expect massive performance degredation using astisian libraries like Rx observables over your sockets. Would be interested in comparing performance with and without Rx. Also, would be curious on a multi threaded implementation. Granted threaded Node requires a slightly different archtiecture....so appreciate you omitting it. Good video though (as much as I dislike Go as a language, it's channel / concurrency story is top tier) subscribed.
Go was so natural to me, after going through "go by example" for a couple of days I start rewriting my main server app in Go which now runs website with 600K daily page views, plus API for mobile apps etc. That was not the case with Rust. I tried it couple of times, but the learning curve was so steep, I was like "this is no worth it, Go is good enough". :) Glad to see I'm not the only one with the same opinion on complexity Go vs. Rust.
“Get outta here typescript. See ya on Monday buddy, we got a lotta work to do” That one hit especially close to home and I very loudly laughed. My family asked me what was wrong, I had to tell them… and they didn’t get it :(
This guy out here doing amazing work, I’m thinking by the end of the year he will be over 1million subs. I think to make this fair you should have the typescript server make calls to some compiled C code 😂 then it will be blazing fast!
I really wanted to make this a "Language" comparison video :) But this is an interesting idea. I could make a follow up with Is it worth it to make c++ modules in TS?
@@ThePrimeagen In that light I have always been curious how "easy" it is to call a different language from another language. Can we call Rust from typescript to make it truly blazingly fast?
@@ThePrimeagen or using Rust packages in TS. I have never seen anyone actually benchmarks calling a FFI package (especially Rust) from TS. It would be really interesting...
You'll love Rust language when you hear about it. You'll love Go when you work with it. You'll love Haskell when you discover true safety it offers in silence and humility.
Blazingly fast comment!!! I really like this types of videos, and I would also like to see how the C language stands between them. It's the one I'm using for university and also the first which comes to my mind when I think of some projects, so that's why I would like to see it.
Great content. I remember reading an example of some data wrangling in python that was as fast as rust.... but using a lot more resources. So It's not just about speed. Or so I understand, I'm a beginner, so don't take my word for it. You sure got me thinking I should stop reading on rust and start with go.
It is remarkable that in the huge IT industry there is almost no such extensive and accessible comparison between programming languages. Great work! In my experience in the IT industry, it's mostly habit, fear of too much change, and the normative power of the factual that drives decisions to use a programming language for high level problems like the server in this video. This is a pity, human and therefore understandable.
great video! it would be interesting to know how elixir performs in this case, although it runs in a VM its concurrency model would probably handle it great
I knew it! Go actually has a really good scheduler built into the language which makes it extremely efficient at highly concurrent workloads. Rust on the other hand has to make due with whatever scheduler is provided by tokio (which undoubtedly is also really good!), but I can see that this may be a cause for the lesser performance. Additionally, Rust provides a lot of safety guarantees that I can imagine require a lot of memory to be copied. Perhaps this copying is also a potential slowdown that caused the dips in the graph. Curious how those graphs correlate to memory usage of both of the applications. Very nice video prime, extremely interesting to see a good benchmark of the two languages that doesn't just revolve around raw computational power.
this could very well be that. Now my skills are terrible in rust, i have only spent 400 hours creating things (which shuld say a ton right there). So I bet i could make it WAY faster, but its WAY harder to do so.
I actually think this is an interesting comment. I think the “blazingly fast” aspect of rust is only half the story. The “correctness” through the expressive type system feels more powerful in enterprise software than the speed. Having never deployed a go or rust server at work, I like the idea that rust makes it much harder/impossible for me to write a certain class of bugs.
To me ease of development and maintenance can’t be beaten. I want my projects up and running fast and the little performance gap it’s not cutting it for me. I think I am making up my mind towards Go. Rust is cool but is facing the obstacle of going against C++ which in the industries where it is used is a strong standard. System programming and mission critical would be great for it but those are the kind of areas where C++ is the hardest to replace. Let alone game development.
Go has been exceedingly impressive in every test I've seen. Coming from someone who writes a lot of PHP/Laravel and Node/TypeScript, I am getting more and more taken by Go every day. Perhaps it's time to pull these sheets back and invite Go into bed for a little while.
@@bradpreston9872 You'll be up and running in less than an hour. The language is extremely simple and basic. Everything just makes sense. And best of all, the simplicity never gets in your way of creating complex applications.
Through out my programming journey I learned that when choosing a language I should ask my self how much time I have to learn a new programming language and what applications I do need to implement. Let say I am interested in embedded systems (microcontrollers) and system programming. I would choose Rust because its fast and memory safe so I don't have to be super experienced to avoid mistakes the compiler will do the job for me. If I am interested in web development desktop development mobile development all together I will choose JavaScript or C# without hesitation. If I am interested in web development only I will learn JavaScript + PHP, If I am interested in fast web application I would go with GO+JS. If I want medium speed web applications I would go with Python + JS. So basically minimize the learning time and maximize the development time, less time in documentation more time in the text editor. this is the requirement.
I wonder how much the performance depends on the network stack. Tokio has one thread that does all the async io and stuff via epoll, I don't know about Go though Would definitely be cool to try out tokio-uring to reduce system call overhead. See how much that could speed up
exactly. The amount of investigation needed is high. I am positive that there are things I could do to make it better, but the fact that i can just go func() { ... } just shows the power of a system designed for async runtimes.
I remember reading years ago something like "all computers wait at the same speed". As long as the computer can outpace your ability to tap the keys, click the mouse, touch the screen, speak commands, or what ever other physical activity, then it is fast enough. But most of want more than just fast enough in our computers. We generally see the speed of a language as the speed of the computer it is running on. Just my two cents worth. 🙂
Go is my main language and I love it! I so so SO want to take my paycheck and rub it in my professors face who back in college said learning the language was a waste of time. I love your work, keep it up!
Looks like the Rust version creates a new thread for each incoming connection. I don't know much about Go, does it do the same, or does it use the lightweight Goroutines? Would be interesting to see how Rust performs with one of the green threads libraries or futures.
it seems the rust version is spawning two tasks: one for sending each socket to another task, which then spawns one task per connection. im sure he could improve it by directly using a while loop spawning one task per connection, instead of two tasks message-passing when they dont need to. edit: also, i noticed he seems to do as i suggested in his go version, i wonder if he is being (unintentionally) biased?
Golang doesn't have "threads" directly. When you use goroutine that is an "lightweight thread". Also, that goroutine can execute concurrently or in parallel or sequentially. So, multiple goroutine can execute on the same thread (by interrupting), or execute in multiple threads and also change between threads. The only way to lock each Goroutine into thread is using `runtime.LockOSThread()`, but that is never used (except in some edge cases, like: when you are talking with OpenGL or system APIs, such as Cocoa API, which expects all calls to come from a single thread). But, by default, create a goroutine and the runtime will manage it for you, simple as that. 🥳
As far as I can tell in the current version of the rust code, he doesn't create new threads for each connection, only async tasks with tokio::spawn not thread::spawn . I think that is much more like goroutines (but I don't know much about those) than full threads per connection. The tokio async runtime has a fixed number of worker threads that are used to run the spawned tasks
3:42 "Come on in, TypeScript." I was so sure he was going to say something "Yeah, take your time" 😂 I am very impressed with the results! Great video (:
@@mattbutler2344 @ThePrimeagen An Alien Go probed my open ring buffer, and now I fee like garbage. Not threat safe at all... No-one wants to be randomly Poked, having their Ring borrowed and not checked... KY Jelly just makes the Proctologist whip in and out faster, doesn´t make it Safe...
why don't you select a topic within a language and built something around it, like a exploration . love the usability idea, would love to see it. great content man.
Would you want to do another take on this a few months down the line when you get even more familiar with both Rust and Go? Do you think the code you write then and the results from it would be any different?
@@ThePrimeagen I love rust but the frontend ecosystem is really not mature and ergonomic enough yet. Especially considering that WASM has no performance improvement (actually worse performance) over JS for DOM manipulation. Backend devel is also still a bit unergonomic but it's mostly fine imho if you are familiar with rust (async traits are still horrible)
@FichDich InDemArsch Yes, "a bit" if you can program. No so much if you can barely write javascript and waste your time molesting people in comments instead of learning to code
its not another language, its literally v8. deno transpiles it and uses rust to go from socket -> v8. It would be a very minimal change with a very minimal result difference. BUT... everyone wont stfu about deno, so i'll try.
@@ThePrimeagen I thought Deno compiles down to Rust just like how python bolis down to C. Also if V8 understands only JavaScript then all Deno does is transpile it's code to javascript and uses Rust to hook Into the V8?
@@krombopuloslincler4849 that's exactly how it works. Deno is meant to be an improvement in things like security, package management, and std library. The underlying runtime/problem being solved is still the same
@@DavisTibbz java would be faster than go and proper rust code is much faster than both. The dude straight up wrote bad rust code because he isn't skilled with it.
@@DavisTibbz For this particular case no, but there's benchmarks for other algorithms and it's a tossup between go and java while rust is much faster. I guess if you choose a handpicked algorithm and implement it really badly for rust you can get go to be faster than rust :)
I've a theory, I made a similar experiment with the A* algorithm (lots and lots of nodes), in Rust this where behind an Rc, and the other implementation was made with Kotlin. Kotlin was 'blazingly faster', and I could not understand how, why, what did I made wrong. Well, it appears that the JVM is smart enough to keep the already reserved memory and use it for new instances of objects, while Rust is super orthodox about memory "oh, the counter is zero, delete". This makes the program stop a lot and makes a global freeze for asking the OS for new memory, while the JVM just deferred calling the GC. Since I think you call the games at batch, Rust after it finishes, clean (as it should) the memory. Yes, I do have now an existential crisis about Rust. GC collecting is smarter, I can't understand this world any more, we are living in a simulation. PD. I think you can use a different allocator in Rust, but at this point.. I'm thinking on Rust for replacing single threaded C code, and use different languages for "trucks of work" systems. Maybe, make GO call a Rust function to work on the data.
I’ve been learning Rust, mostly to teach me more about programming. I keep running into this though, that Go is easier to write and competitive with, if not often better than, Rust at performance related tests.
Man, your content is so good! I'm addicted to it! Congrats. Oh by the way, if you put your twitch link on description and talk openly about it on the video youtube lower your delivery (you should call it the other purple site or something like that)
It is linked? I pretty sure its in the description (i'll fix if not). And second, i put it at the VERY end because that is the proper place to put it :) I don't want to early promote it, feelsweirdman
@@ThePrimeagen Yes, it's in the description, but youtube slows down the delivery of your videos if you say "twitch" in the video or if you have the link to twitch anywhere in the description.
Very interesting video! I saw the struggle to write correct rust code (spoiler, it is hard!)! Do you have the numbers when the amount of simultaneous games are increased in a single thread (e.g. 3200)?? It might be better to see the difference between Go and Rust (single thread). Because a 0,8% to 0,2% bad frames reduction seems large!
I'd really love it if you'd add Python ( FastAPI ) into the mix for these server performance comparisons :^] It would be interesting to say at the least to see how it fairs up against the big guys. * of course writing python is like writing English so not gonna be surprised if you write up the server in like 15 minutes
+1 for this. And on techempower's benchmarks(very comprehensive look it up), fast api held up against golang. The difference is so small that it just isn't worth ditching all the nicities of fast api for go. But for django/flask the difference is really huge, like massive.
I'm currently learning rust for fun and this video is really surprising to me! based on this video alone is it right to assume that go is just good enough for almost every task and sometimes its just not worth the time and effort to do it in rust?
that is the proper outlook. Most of us will never do proper systems programming. Most of us will never have servers absolutely maxed out (which mine wasn't technically, the CPU wasn't there, ~40-60% utilized). Most of us don't have memory security issues, just shitty programming issues :) ALL OF THAT SAID. Rust is my favorite language
I disagree. The selling point of rust is not only the performance potential and memory safety but also the type system and compiler error messages, ecosysrem, cargo clippy, docs.rs, etc. I tend to use rust even for little applications where performance doesn't matter at all, just because it makes it so much easier to build something that works reliably and correctly does what I want it to do.
let me tell you go has been the cause of at least one security issues which rust could not have allowed, but the devs probably had the same thoughts as you.
When handling multiple connections, you wouldn't use multiprocessing but multithreading, because threads are more lightweight and not blocked by the GIL during IO operations
Rust is slower for smaller projects but as the project become larger the compiler checker will guide you and you'll get that initial time investment back and more. You won't have to know what some code you wrote 6 months ago does, just be told what's wrong with it.
super interesting. more usability tests would be great! dont think ive seen something similar before, and those results seem super useful for decision making.
I think the main takeaway I have is that go is just super fast for how easy it is. I am positive I can make a rust implementation eventually that is much faster than go. But it's very hard to get there
Rust has amazing performance when you get it right (which is hard). Go has good performance and you don’t even have to try that hard for it
great way to say it
In real world rust is never actually fast, all lies from the cult. Go just beats it easily with a much better user experience. Their flagship server Rocket gets crushed by Go fiber in every area, including speed.
@@SumoCumLoudly Rocker is not really 'flahship server', no idea why you'd want to misrepresent rust here :P Try comparing fiber to actix web. I have to admit tho, rust is super hard and performance gained from it (i've no doubt that it can outperform go any time) still might not be worth it for most people.
@@NoxyYT theoretically you can write rust code to match c++, in reality tho the code just doesn't exist because nobody can write it. Go pick up the popular rust library for whatever area you can think of and compare it to the c++ equivalent, its nowhere near as fast, chances are it won't even be as fast as the Go equivalent never mind c++. It's difficult to write slow code in c++, and it's difficult to write fast code in rust. Most c++ programmers handle memory as second nature, they don't need protection from themselves. I can see why companies would buy into the idea of enforced safety, but unless lives depend on your code, I wouldn't even give rust a second thought, the juice isn't worth the squeeze as they say.
@@SumoCumLoudly false
The Rust code has a shared HashMap behind a mutex. That's most of the problem... You're completely removing any benefit of multithreading, because your other threads can't do any work when the HashMap is in use (which is all the time). You could try changing it for an RwLock, because most of the time, you seem to be only reading from it. Another option is to use a concurrent hashmap, like DashMap, which tries to be an easy replacement for RwLock.
Other (less important) issues are: You're heap-allocating all of your futures from Listenable because of async_trait, and you're spawning two tasks instead of one per connection, increasing pressure on the task scheduler.
I guess there's only one way to find out. Fork and benchmark?
You are totally right. I suggested in a comment to replace the implementation with actix websocket.
Are you one of those gods who helps on stackoverflow ?
@@LinuxUser123 He sure does sound like one✨
HashMaps in general are just a perfomance sink
I'm more impressed with the tests you plan and write to make these comparisons than the actual results. I am baffled by the amount of time and work you just put into stuff like these. And the best part is, you do this because you're just crazy and love shit like this.
Love your videos man, inspiring .❤️.
Hm, I'm actually not immensely surprised about the comparison between Rust and Go in the end with Go being actually fast with immensely lesser effort compared to Rust. There is a good chance that a highly optimised Rust version would perform even better, but at some point you gotta ask yourself how fast do you actually need it to be and is it worth it.
Thank you for the video, prime!
THIS IS EXACTLY THE POINT! Love to see it got across. There just comes a reward payout that doesnt make sense for the 99.99% of software
So fun to watch and still very informative. Keep going!
yayaya, ty
big agree
go go go!
yeah! I subscribed!
In my previous job i got a little exposure to Go and i really liked. This kind of informative videos solidify my decision to get better at Go and have the right tool for the right job (because getting to work in Kotlin backend outside of android apps is going to be really hard)
go is almost always the right decision for the back end. I understand the JVM based arguments and nodejs, but I am al go
I've been writing Go professionally for 9 years. It's really really good. Most of the time the right way to write the code is very straight forward and obvious... and then it performs really well with no optimization.....
The only performance problems I've had were logic-based, not language-based. For example, this one API endpoint made 12 database calls, when it could have been consolidated into just a few.
I've never been like "oh, this part of the code is doing too many loops and copying too much data... we should rewrite the logic so that it'll be faster" ... nope. 100% has not happened.
*and* you can understand the code when you come back to it in 6 months or a year, or if you're new to the codebase.
@@NateFinch Can i get your take on Django?
@@quentonwong408 having worked extensively in both Go and Django, Go all the way. Django has a lot of footguns and things that'll slow down productivity to a crawl. Django's migrations take FOREVER compared to running similar migrations in Go or Elixir or Rust. For example, we had ~200 migrations that would take 4 minutes to run on a arm64 fully-specced macbook pro. We had to spend ~4 days of an engineers time to consolidate those migrations down to 50, and they still take ~1 minute to run. In my Go app with 100 migrations, it takes about 5 seconds. In my elixir app with ~400 migrations it takes about 20 seconds. That alone should dissuade you from using django. Then we get to just how slow python is in general and it starts to look less and less usable.
When a comedian chooses a path in programming and becomes blazingly good at it you get ThePrimeagen.
tytytytyttytyty, way too kind.
@@ThePrimeagen blazingly good your videos
comedians are generally good at everything, i live in a country which is run by comedian
@@makkusu3866 which one if I may ask
@@darkfoxwillie the invaded one
Would love to see if any highly experienced go/rust people would take the challenge to reimplement or refactor what you wrote while you do a video measuring the time, discussing what optimizations were made, and which language truly blazes and which one got caught up asking for feet pics on the internet.
I would like to see that!
Well go for me is easy as Ruby to learn, learning right now. It goes well though i'm warming up before going fully into 8hours routine daily. I think I can get there in a week from now
Well what stops me right now that some time I read, watch some content i need to learn till I finish, a little less coding, beside I participate in Rails hackathon and i wanna mąkę head space for that, do less for moment
I found your channel originally because of VIM but have to say that all your videos are both educational and fun to watch. Keep it up!
yayayaya, ty ty ty :)
This is actually the best case made I've heard for Go. Simpler to write, reasonable performance. I would go for it for my next project (even though I've already chosen rust for said project).
as a person who has written a lot of rust and go, I prefer go. its easier to teach people, easier to maintain, and easier to read IMO. you get like 80% performance of Rust without the large up front Rust knowledge cost and slower development speed and turn around (compilation is much slower and active development recompiles a lot).
How's the project? I aspired to learn rust for a long time but have come to see it as unrealistic
I would like to see more of this type of content please, thank you very much
you are welcome :)
people love to see others suffer.
Really appreciate the work you into this video! Thank you once again for making my day that much more BLAZINGLY FAST.
Slick content my guy. Love it. I'm glad someone has (mostly) unbiasedly confirmed what I've seen in many years of engineering software. Go is just faster and easier to write a blazingly fast solution to a problem in. There's very few foot guns, very few things to learn, and it compiles and runs your tests BLAZINGLY fast. IMHO if a language can get you even 80% of the way to the _fastest_ solution in ~20% of the time, then that should probably be your daily driver for latency sensitive applications.
I now have a working version of Rust that is several times faster than go.
But it took significantly longer. Now I'm not sure if that is just a requirement of getting good at a language, whereas go feels like most languages have already used.
This was great, honestly I just like to watch programming stuff in general. It is all very interesting, the whole space is so cool. Appreciate it!
Great work! Loving the humour and the Go vs Rust vs TypeScript comparison. Please give us more of this. We need moar..
moarVM? "Metamodel On A Runtime" . Rakudo
I do love working with typescript but go has been looking interesting for a while. If it's as easy to write and gets you free performance it I thinki might look into it. Very impressive seeing it compete against organic home grown rust.
rust is the _funnest_ language to write. You feel like a hacker without all the difficulty :)
But go is boring, but its SO easy to get right.
The biggest problem for me with NodeJs API's has been unavoidable blocking code. Yeah, even after we async all the things, some things that need an immediate response are going to block. With Go, you can stick every request in a goroutine and not have the spillover.
I think the abstractions for concurrency chosen in go have democratized multi-threaded programming. Before go getting threads running in parallel was an arcane art only tried in very rare circumstances by the top 1% of programmers. Then go came along and showed how normal programmers can also write fast, safe, multi-threaded code.
@@EdouardTavinor Great way to put it.
I am so glad I found this channel!! This is truly prime CONTENT right here, as well as it being helpful and educational is a nice benefit! TY TY for putting in the time and effort!
I would love to see Elixir added to the mix, specifically for concurrent connections
No
Discord has entered the chat
At this point it would not be any faster than go to be honest, and if there are any calculations (did not dive into the project to realise that) there is no point (elixir developer here).
@@Qizot Can you elaborate? Highly interested - is Go on par with Elixir/Erlang regarding its concurrency model performance wise?
@@freeo6242
Short answer: What do you define performance wise. Are you looking at something that is computationally heavy or something that is latency dependent. Go fits the former while Erlang (and Elixir, both of which run on the BEAM VM) fits better for the latter.
Longer answer:
Erlang/Elixir (and by extension the BEAM VM) and Go both offer similar concurrency models (userspace threading) but the latter is "better" if you are reliant upon heavy computation. Some exceptions exist here as you are able to hook in more performant code written in another language using Erlang's Natively Implemented Functions.
Erlang/Elixir enforces preemption through reduction counting, which basically counts how many times a function is executed, whereas Go is still largely cooperatively scheduled.
To my understanding Go requires the compiler to insert checkpoints in the code to yield execution of the userspace process back to the scheduler. There was a proposal for adding preemption features to the Go scheduler but I'm not quite sure what the status of that is.
As a result of its preemptive-like scheduler, Erlang (and by extension Elixir and other languages on the BEAM VM) have been described as soft-realtime. This in simple terms means that Erlang is capable of low latency workloads but lacks the ability for throughput oriented workloads, Go is the opposite of this.
This is really interesting! Thanks for all the research you put into this. Would definitely love to see more stuff like this
we trying!
I've waited for this video to come out blazing fast from its announcement! Strapping my seatbelts on 😁
GET THAT COCONUT OIL OUT BABE
@@ThePrimeagen SIR, YES SIR! RUBBING THE COCONUT OIL ON MY GOPHER RIGHT NOW SIR!!!
Prime, you're the best! This type of content is really gold, as per usual. Thank you for doing this videos and being informative while also being completely mad (as a scientist)!!!
These videos are so much fun yet educational. And fucking hilarious thumnails to boot
Thank you! It took 1.5 hours last night to make :)
the one niche use Rust has is perhaps for writing device drivers. Go is a great middle-ware language - gives a lot of bang for the buck because it's not as complicated to learn as C++ or Rust.
Hey bro, that's awesome, please do a comparison with Bun
I'm sure you're the only guy on whole RUclips (or even Universe) who could do it the right way!
Typescript, you are fired
Go you are balanced blessed
Rust, you are currently giving your best, high hopes for you
love this kind of content
yayaya!
your videos are the best, they have the perfect mix between incredible useful info and fun, more like this please! :-)
looking forward for some Frontendmasters course for this Rust vs Go vs TS topic.
I haven't used Rust much, but I've used Go. One noticable thing that I've seen is that the compile time in Go is insanely fast, while Rust really takes its time (maybe because of the optimizations it's doing), but for a "normal" end user, I think Go is the clear winner at least in that deparatment.
And I thiink Go's concurrency is famous for a reason (as you also mentioned), and it's REALLY built-in to the language and flows with it.
Great and informative video BTW
Concurrency. Does it matter if concurrency abstractions are built into language or available as a library...I don't think it matters. Maybe in a more opinionated language, but Go is not very opinionated imho. It's just this C with lipstick on.
I can't say I agree. It's not just a matter of being built into the language but the ease of use it gives. As I said, I can't talk for Rust, but the code I've seen in videos to implement something like channels in Go, IMHO, is wayyy more complicated than Go
Blazingly fast you got subscriber++
Amazing channel. Love your energy.
Let's go!!!
Great work.
I think the advantage of Rust from a ease-of-programming perspective seems to be Cargo and the infrastructure for writing tests. It would be great to see a comparison between these three languages in terms of how packages are managed and how conducive writing tests would be.
Also, generics.
I always enjoy these more academic type videos. I’m looking forward to whatever you release next.
yayaya!
effectively the answer is: TS sucks because ecosystem, go / rust are great, rust is best
@@ThePrimeagen well, TS has the npm where you could find literally everything. Also, almost any 3rd party service has an integration/SDK with js/ts. I wouldn't say that it's an easy choice
maybe it's more about community than the ecosystem, but this thing really matters. I know a guy who tried to make a dapp/blockchain project on C#, he suffered a lot
Go's module (dependency management) system is really solid these days. Testing support is fantastic. Built in testing suite, performance testing, fuzzing, runnable examples, code coverage..... And it even has generics now.
You rock btw, I wish I knew you personally as a mentor that’s how much I value your videos. I think you are a truly awesome person, and engineer and you should be proud of that :)
thanks scott :) those are very nice words
Just on the TypeScript implementation. Not sure if you're measuring networking (id assume the gameloop would be the most pressing thing) but id expect massive performance degredation using astisian libraries like Rx observables over your sockets. Would be interested in comparing performance with and without Rx. Also, would be curious on a multi threaded implementation. Granted threaded Node requires a slightly different archtiecture....so appreciate you omitting it. Good video though (as much as I dislike Go as a language, it's channel / concurrency story is top tier) subscribed.
This is why I'm particularly psyched about Ziglang. Its also very fast but more practical
Same. I hope Zig gets more killer products like Bun in the near future.
I've never written a line of code in my life but can't get enough of these Primeagen and Primereacts videos.
This was great!
But for real, how does the ungodly mutant in the thumbnail manages to be both cute and cursed at the same time ?!
it took me 1.5 hours to make. it is a beautiful creature of your nightmares.
Go was so natural to me, after going through "go by example" for a couple of days I start rewriting my main server app in Go which now runs website with 600K daily page views, plus API for mobile apps etc.
That was not the case with Rust. I tried it couple of times, but the learning curve was so steep, I was like "this is no worth it, Go is good enough". :) Glad to see I'm not the only one with the same opinion on complexity Go vs. Rust.
rust is amazing, but I have done SOOOO mucth effort with rust and still suck. Go is truly a magical language
@@ThePrimeagen Go is magical and also BLAZINGLY fast! 😆
Exactly, and if go is not good enough, then scale it horizontally. Case closed.
“Get outta here typescript. See ya on Monday buddy, we got a lotta work to do”
That one hit especially close to home and I very loudly laughed. My family asked me what was wrong, I had to tell them… and they didn’t get it :(
This guy out here doing amazing work, I’m thinking by the end of the year he will be over 1million subs.
I think to make this fair you should have the typescript server make calls to some compiled C code 😂 then it will be blazing fast!
I really wanted to make this a "Language" comparison video :)
But this is an interesting idea. I could make a follow up with Is it worth it to make c++ modules in TS?
@@ThePrimeagen In that light I have always been curious how "easy" it is to call a different language from another language. Can we call Rust from typescript to make it truly blazingly fast?
@@ThePrimeagen or using Rust packages in TS. I have never seen anyone actually benchmarks calling a FFI package (especially Rust) from TS. It would be really interesting...
You'll love Rust language when you hear about it.
You'll love Go when you work with it.
You'll love Haskell when you discover true safety it offers in silence and humility.
You'll *hate* go when you work with it
@@Anon.G why??
@@Anon.G git gud
Haskell does not have google hand picking the search results for it
Blazingly fast comment!!!
I really like this types of videos, and I would also like to see how the C language stands between them. It's the one I'm using for university and also the first which comes to my mind when I think of some projects, so that's why I would like to see it.
its SUPER hard to get c servers very correct.
Now I have one more reason to love Go ♥️
Thank you so much Prime 😄
yaya! Go is really great
@@ThePrimeagen that's funny cuz "yay" is written in golang
LOL, "get the hell out and I'll see you on Monday TS" :) great series Prime, keep em coming👌
yaya! thank you :)
Damn, would have loved to learn if Python's fastapi is really, well, a fast API.
That's some blazingly amazing insights! Appreciate your effort 🌸
4 minutes into watching the first video I've seen of yours and I've determined you're the DrDisrespect of software development. Loving it.
Great content.
I remember reading an example of some data wrangling in python that was as fast as rust.... but using a lot more resources. So It's not just about speed. Or so I understand, I'm a beginner, so don't take my word for it.
You sure got me thinking I should stop reading on rust and start with go.
hah. Rust is a FUN language, perhaps my fav.
but its hard. go is easy, boring, and makes you lots of money.
@@ThePrimeagen Best answer 😂
Why do you think rust is fun? I think I agree for what I’ve seen, just can’t quite answer this myself…
It is remarkable that in the huge IT industry there is almost no such extensive and accessible comparison between programming languages. Great work!
In my experience in the IT industry, it's mostly habit, fear of too much change, and the normative power of the factual that drives decisions to use a programming language for high level problems like the server in this video. This is a pity, human and therefore understandable.
love the technicals..feels good watching some geeked out video for once
great video!
it would be interesting to know how elixir performs in this case, although it runs in a VM its concurrency model would probably handle it great
@Kelvin Hu explained the difference between go and elixir in the Sebastian Henao comment, and it does not seem the case.
YAYAYA gimme a video comparing how each language felt like. I'd love to get those insights. Awesome content. Definitely learning go
I knew it! Go actually has a really good scheduler built into the language which makes it extremely efficient at highly concurrent workloads. Rust on the other hand has to make due with whatever scheduler is provided by tokio (which undoubtedly is also really good!), but I can see that this may be a cause for the lesser performance.
Additionally, Rust provides a lot of safety guarantees that I can imagine require a lot of memory to be copied. Perhaps this copying is also a potential slowdown that caused the dips in the graph. Curious how those graphs correlate to memory usage of both of the applications.
Very nice video prime, extremely interesting to see a good benchmark of the two languages that doesn't just revolve around raw computational power.
this could very well be that. Now my skills are terrible in rust, i have only spent 400 hours creating things (which shuld say a ton right there). So I bet i could make it WAY faster, but its WAY harder to do so.
I actually think this is an interesting comment. I think the “blazingly fast” aspect of rust is only half the story. The “correctness” through the expressive type system feels more powerful in enterprise software than the speed. Having never deployed a go or rust server at work, I like the idea that rust makes it much harder/impossible for me to write a certain class of bugs.
@@ThePrimeagen so thats why you wrote rust code without running `cargo fmt` before uploading...
This content is BLAZINGLY AWESOME! Keep'em coming!
Yeah! Thank you :)
To me ease of development and maintenance can’t be beaten. I want my projects up and running fast and the little performance gap it’s not cutting it for me. I think I am making up my mind towards Go. Rust is cool but is facing the obstacle of going against C++ which in the industries where it is used is a strong standard. System programming and mission critical would be great for it but those are the kind of areas where C++ is the hardest to replace. Let alone game development.
Amazing! Id love to see more videos like this and also about the usability of the languages :D
yaya! Its a lot of fun, but very hard to do. I'll try to get some more
Go has been exceedingly impressive in every test I've seen. Coming from someone who writes a lot of PHP/Laravel and Node/TypeScript, I am getting more and more taken by Go every day. Perhaps it's time to pull these sheets back and invite Go into bed for a little while.
i love go :)
@@ThePrimeagen I've been learning it off and on for a few weeks, but I think I'm going to actually commit to a deep dive of the language. It's great!
@@bradpreston9872 You'll be up and running in less than an hour. The language is extremely simple and basic. Everything just makes sense. And best of all, the simplicity never gets in your way of creating complex applications.
Through out my programming journey I learned that when choosing a language I should ask my self how much time I have to learn a new programming language and what applications I do need to implement.
Let say I am interested in embedded systems (microcontrollers) and system programming. I would choose Rust because its fast and memory safe so I don't have to be super experienced to avoid mistakes the compiler will do the job for me.
If I am interested in web development desktop development mobile development all together I will choose JavaScript or C# without hesitation. If I am interested in web development only I will learn JavaScript + PHP, If I am interested in fast web application I would go with GO+JS.
If I want medium speed web applications I would go with Python + JS.
So basically minimize the learning time and maximize the development time, less time in documentation more time in the text editor. this is the requirement.
I wonder how much the performance depends on the network stack. Tokio has one thread that does all the async io and stuff via epoll, I don't know about Go though
Would definitely be cool to try out tokio-uring to reduce system call overhead. See how much that could speed up
exactly. The amount of investigation needed is high. I am positive that there are things I could do to make it better, but the fact that i can just go func() { ... } just shows the power of a system designed for async runtimes.
@@ThePrimeagen the most equivalent thing to that in rust is tokio::spawn(async { ... }), right?
that does not seem to be much of a diff to me...
I remember reading years ago something like "all computers wait at the same speed". As long as the computer can outpace your ability to tap the keys, click the mouse, touch the screen, speak commands, or what ever other physical activity, then it is fast enough. But most of want more than just fast enough in our computers. We generally see the speed of a language as the speed of the computer it is running on. Just my two cents worth. 🙂
Go is my main language and I love it! I so so SO want to take my paycheck and rub it in my professors face who back in college said learning the language was a waste of time. I love your work, keep it up!
hah. professors are so out of date
@@ThePrimeagen I had to learn Cobol on college, and I'm not THAT old! :)
I just love your content, please bring more content like this :)
trying
Could you add Elixir and Haskell to the list , I think this two are better competitor of Go and Rust in server side, Very impormative video btw thanks
just don't think i have the patience for learning another language this year. ;)
Looks like the Rust version creates a new thread for each incoming connection. I don't know much about Go, does it do the same, or does it use the lightweight Goroutines? Would be interesting to see how Rust performs with one of the green threads libraries or futures.
it seems the rust version is spawning two tasks: one for sending each socket to another task, which then spawns one task per connection. im sure he could improve it by directly using a while loop spawning one task per connection, instead of two tasks message-passing when they dont need to.
edit: also, i noticed he seems to do as i suggested in his go version, i wonder if he is being (unintentionally) biased?
Golang doesn't have "threads" directly. When you use goroutine that is an "lightweight thread". Also, that goroutine can execute concurrently or in parallel or sequentially. So, multiple goroutine can execute on the same thread (by interrupting), or execute in multiple threads and also change between threads. The only way to lock each Goroutine into thread is using `runtime.LockOSThread()`, but that is never used (except in some edge cases, like: when you are talking with OpenGL or system APIs, such as Cocoa API, which expects all calls to come from a single thread). But, by default, create a goroutine and the runtime will manage it for you, simple as that. 🥳
As far as I can tell in the current version of the rust code, he doesn't create new threads for each connection, only async tasks with tokio::spawn not thread::spawn . I think that is much more like goroutines (but I don't know much about those) than full threads per connection. The tokio async runtime has a fixed number of worker threads that are used to run the spawned tasks
@@darkfire2703 you are correct, they are like goroutines (with some caveats)
@FichDich InDemArsch What?
I had to get out the extra large tub of coconut oil for this one. What a treat!
did you get to the ending though :)
More rust vs go please? :)
Dude, Ive been looking for this for so long as a noob, thank you!!!
3:42 "Come on in, TypeScript." I was so sure he was going to say something "Yeah, take your time" 😂
I am very impressed with the results! Great video (:
yayaya! I know, i made the joke once, I have to be original
@@ThePrimeagen sounds fair 😂
Love this content. Keep it up. Best tech youtuber out there hands down.
Oh snap! thank you
Go is underrated. Rust is currently a pain in the ass, and headed for the same syntax-morass as C++
yaya! c++ is ring 1 hell, but rust is like heaven ring 1. Great, better than anything on earth, but there is such better :)
@@ThePrimeagen lol, what do I know my friend, I'm still stuck here in io_uring? Who made these buffers circular: ;p
@@mattbutler2344 @ThePrimeagen An Alien Go probed my open ring buffer, and now I fee like garbage. Not threat safe at all... No-one wants to be randomly Poked, having their Ring borrowed and not checked... KY Jelly just makes the Proctologist whip in and out faster, doesn´t make it Safe...
Pun idea for the future: whichever performs worst you can call it "Blazingly Last"
why don't you select a topic within a language and built something around it, like a exploration . love the usability idea, would love to see it. great content man.
yaya! that is what i am doing on twitch.
I watched this video twice, you are blazingly funny, well done
Thank you for this blazingly nice comment
Would you want to do another take on this a few months down the line when you get even more familiar with both Rust and Go? Do you think the code you write then and the results from it would be any different?
Thanks for this, really helpful. Benchmarks always welcome !!
you are welcome and i appreciate the nice comment.
Go vs Haskell...for the next time? Because why not?
negative. No way i am learning an fpl
@@ThePrimeagen I guess we'll never get to see theprimeagen monad
For each hundred lines of Go code you get five lines of Haskell code
I’m looking forward to learn for about Go vs Rust comparison in major computation tasks
yeah, i am thinking about other things here soon.
I want to do yew.rs vs svelt / react to see how it feels to make front ends :)
@@ThePrimeagen I love rust but the frontend ecosystem is really not mature and ergonomic enough yet. Especially considering that WASM has no performance improvement (actually worse performance) over JS for DOM manipulation. Backend devel is also still a bit unergonomic but it's mostly fine imho if you are familiar with rust (async traits are still horrible)
@FichDich InDemArsch Yes, "a bit" if you can program. No so much if you can barely write javascript and waste your time molesting people in comments instead of learning to code
Continues to demonstrate why Go has such a high adoption rate relative to Rust! Awesome video, keep it up!
yaya! I love rust more, but i think go is just better
@@ThePrimeagen Why do you love it more?
Great video as always Prime, keep up the good work!
thank you :)
Run the same Typescript with Deno and see how it performs compared to Rust. It would take minimal effort and you have another language to compare.
its not another language, its literally v8. deno transpiles it and uses rust to go from socket -> v8. It would be a very minimal change with a very minimal result difference.
BUT... everyone wont stfu about deno, so i'll try.
@@ThePrimeagen I thought Deno compiles down to Rust just like how python bolis down to C.
Also if V8 understands only JavaScript then all Deno does is transpile it's code to javascript and uses Rust to hook Into the V8?
Awesome content
@@krombopuloslincler4849 that's exactly how it works. Deno is meant to be an improvement in things like security, package management, and std library. The underlying runtime/problem being solved is still the same
Broh, I like your content, it's BLAZINGLY fun.
I wonder how the big brother languages like Java (Spring) and C# would perform in these tests
Still Horrible, but better than tS; even after use Java’s aysnc and C# async as well
@@DavisTibbz java would be faster than go and proper rust code is much faster than both. The dude straight up wrote bad rust code because he isn't skilled with it.
@@SoSo7060 Java would be faster than Go??? You’re kidding right? Have you written any similar code in java and go then do benchmarks?
@@DavisTibbz For this particular case no, but there's benchmarks for other algorithms and it's a tossup between go and java while rust is much faster. I guess if you choose a handpicked algorithm and implement it really badly for rust you can get go to be faster than rust :)
I can always tell we’re going blazingly fast when he breaks out the coconut oil.
best way
I've a theory, I made a similar experiment with the A* algorithm (lots and lots of nodes), in Rust this where behind an Rc, and the other implementation was made with Kotlin. Kotlin was 'blazingly faster', and I could not understand how, why, what did I made wrong. Well, it appears that the JVM is smart enough to keep the already reserved memory and use it for new instances of objects, while Rust is super orthodox about memory "oh, the counter is zero, delete". This makes the program stop a lot and makes a global freeze for asking the OS for new memory, while the JVM just deferred calling the GC. Since I think you call the games at batch, Rust after it finishes, clean (as it should) the memory.
Yes, I do have now an existential crisis about Rust. GC collecting is smarter, I can't understand this world any more, we are living in a simulation.
PD. I think you can use a different allocator in Rust, but at this point.. I'm thinking on Rust for replacing single threaded C code, and use different languages for "trucks of work" systems. Maybe, make GO call a Rust function to work on the data.
Games would use arena allocation for the use case you've described i.e. one deallocation to release them all.
@@minciNashu would that be... blazingly fast?
@FichDich InDemArsch what?
@FichDich InDemArsch do you like the gazillion open source libraries made by random dudes online that makes possible to this comment to be seen?
@FichDich InDemArsch Sure buddy
PLEASE more of this, i like comparison between languages alot
Rust is so fun, but go is so good.
Too difficult to decide
agreed
rust is more fun
go is easier to get right
Thanks amazing, I was thinking about learning Rust but now I think that I'll probably go more into Go zone, mmm
go is just really easy to get right.
I’ve been learning Rust, mostly to teach me more about programming. I keep running into this though, that Go is easier to write and competitive with, if not often better than, Rust at performance related tests.
@@lilac1794 For me was more about learning some low level programming language similar to C but I also consider time of development so I don't know
Html is the fastest programming language 😢
Man, your content is so good! I'm addicted to it! Congrats.
Oh by the way, if you put your twitch link on description and talk openly about it on the video youtube lower your delivery (you should call it the other purple site or something like that)
It is linked? I pretty sure its in the description (i'll fix if not).
And second, i put it at the VERY end because that is the proper place to put it :) I don't want to early promote it, feelsweirdman
@@ThePrimeagen Yes, it's in the description, but youtube slows down the delivery of your videos if you say "twitch" in the video or if you have the link to twitch anywhere in the description.
Very interesting video! I saw the struggle to write correct rust code (spoiler, it is hard!)!
Do you have the numbers when the amount of simultaneous games are increased in a single thread (e.g. 3200)?? It might be better to see the difference between Go and Rust (single thread). Because a 0,8% to 0,2% bad frames reduction seems large!
it was large and i could try to see where the limit is on one cpu before explosions, but man, so many hours on this :)
Since when this channel is out there??!! Jeez I'm all in.
been around for a while
I'd really love it if you'd add Python ( FastAPI ) into the mix for these server performance comparisons :^]
It would be interesting to say at the least to see how it fairs up against the big guys.
* of course writing python is like writing English so not gonna be surprised if you write up the server in like 15 minutes
yea,h, i just have to learn python first, so i would probably write some shitty code to begin with.
@@ThePrimeagen haha I'm pretty sure you'd get the hang of it in the second hour it's literally THAT easy :]
+1 for this. And on techempower's benchmarks(very comprehensive look it up), fast api held up against golang. The difference is so small that it just isn't worth ditching all the nicities of fast api for go. But for django/flask the difference is really huge, like massive.
What a blaaaazingly great video! Keep up with the entertaining plus useful content!
yayaya!
I'm currently learning rust for fun and this video is really surprising to me! based on this video alone is it right to assume that go is just good enough for almost every task and sometimes its just not worth the time and effort to do it in rust?
that is the proper outlook.
Most of us will never do proper systems programming.
Most of us will never have servers absolutely maxed out (which mine wasn't technically, the CPU wasn't there, ~40-60% utilized).
Most of us don't have memory security issues, just shitty programming issues :)
ALL OF THAT SAID. Rust is my favorite language
I disagree. The selling point of rust is not only the performance potential and memory safety but also the type system and compiler error messages, ecosysrem, cargo clippy, docs.rs, etc.
I tend to use rust even for little applications where performance doesn't matter at all, just because it makes it so much easier to build something that works reliably and correctly does what I want it to do.
let me tell you go has been the cause of at least one security issues which rust could not have allowed, but the devs probably had the same thoughts as you.
@@ThePrimeagen nim/phix-lang/v-lang/zig saying hold our beers
I'm sure he shows affection with a slapping frenzy, but I can't confirm
I've heard bad things about Python multiprocessing.
Would be interesting to see a comparison :D
hah! be my guest :)
When handling multiple connections, you wouldn't use multiprocessing but multithreading, because threads are more lightweight and not blocked by the GIL during IO operations
I think this is the most fun and informative coding channel I've ever seen, good work man!
Rust is slower for smaller projects but as the project become larger the compiler checker will guide you and you'll get that initial time investment back and more. You won't have to know what some code you wrote 6 months ago does, just be told what's wrong with it.
super interesting. more usability tests would be great! dont think ive seen something similar before, and those results seem super useful for decision making.
I think the main takeaway I have is that go is just super fast for how easy it is. I am positive I can make a rust implementation eventually that is much faster than go. But it's very hard to get there
Yes sirrr!!
Yaya
ok bun.js is out, when will we see the comparison?!
Go vs Java!!
nope
@@ThePrimeagen would be very interesting though to add Java into the mix as both have GC capabilities
Usability: PHP, Golang, Rust, Typescript delivering image assets and some buttons controlled by js. Measure time to interactive and fullpage load