@@andrzejstachlewski3662 have you use it on a large project? Did it scale? It seems like there is a defati structure for golang projects. Damn NodeJS is like hell on earth. Every projects i had, had their own different demons on their codebase. I want something stable
Nice video. The times I used Go, it was an fun. There are some... Strangely opinionated design decisions, in my opinion, but I understand that some of that is changing. I also like the way newer languages like Rust and Go are providing a standardized ecosystem of tooling around the language.
this is exactly how I feel. I don't love all the decisions, but there is decisions and standards that make it easy to pick up the language. TypeScript's ecosystem is 1000% better than c++, but its definitely way behind rust / go .
I love the standardized ecosystems in rust and go. It means we don't have asshats creating new build systems and "golden paths" every day like we do for TS/JS. go is also a nice, simple language that's reasonably fast and easy to pick up and use. rust is not as easy but once you get the hang of it it's quite nice. typescript's type system is unbeatable though. if rust had TS's type system i would just about shit my pants. rust comes close (fixed size arrays, tuples, sum types) but if it had all the other TS stuff like intersection types, mapped types, conditional types, etc. i would lose my entire shit thru the fabric of my pants
@harleyspeedthrust4013 I'm not experienced at coding, but couldn't you create a crate that has typescript types you like? A crate that's basically an interpreter or something? How could we get this to work? I'm currently getting into Go and Typescript as a noob, with the plan to graduate to Rust once I understand the basics of syntaxes etc. Everything on the internet is telling me not to learn Rust first..
I really enjoyed this, being primarily a JS/TS front-end dev with some Go experience in the last few months I fully expected Go to be more performant. I didn't expect the difference to be as big as it was though and I kinda wish you'd delved into why that might be. Hoping to see a part 2
I've tried to use golang but it's the most insufferably designed language I've used and typescript is just so much better. Nils can crash your program and there's 0 proper safeguard against them, much weaker type system, no union types, literally use public/private access modifiers by capitalizing functions, spent about 45 minutes getting imports to work because it has to be different and have the weirdest import system i've used to date (it's literally easier in rust which is even faster than go), its source repository is github, so you import the master branch of libraries which leads to random bugs/issues, and a lot of the standard libraries are also weirdly annoying like bubbletea which forces you into elm architecture to make things more convoluted. to this day idk why people like it The extra code you write in typescript is worth it because it lets you write enterprise, stable organized software that lasts and doesn't become spaghetti code down the line that's why most startups use it and why it was designed that way. That's why OOP, classes, types, interfaces, etc exist because it gives structure and organization to your code I think what really should be mention videos is that golang is just "typescript but better and faster", there's a massive tradeoff and that is code quality. If you're looking for something like typescript but is faster dotnet is a much better choice.
I do mean what I said at the end. The likes, comments, subscribes, and shares are a way in which I gauge how much the audience is interested in this topic. So if you like this, want more, etc etc, please help me by engaging. It sends the most clear signal. I also don't want to be that guy that tells you to like / subscribe at the beginning of every video, so this is my way of doing it, at the end, with very little prompting. IF YOU LIKE THIS, THEN TELL ME YOU LITTLE ALGO INDUCERS I also want to make it clear that this is a toy example and there is always incorrectnesses with toy examples. The reality lies somewhere between the lines. Its really hard to create two identical large scale servers.... almost impossible with a beautiful wife, 4 kids, and a full time job. But my goal is to continue to build this up into a series of fun experiments.
What do you mean it isnt a language? Just because its translated into another language doesnt mean its not a language. Javascript is not executed either. Its compiled into an intermediate language, which isnt executed either, but compiled further into machine instructions
@@garad123456true, TS can still be classified as a language but his statement wasn't entirely false either. It's not TS that's being executed it's the transpiled JS.
@@ichigo_kurosaaki Well, in the context that he replied to, it's correct that TS doesn't affect the performance, but to say it "isn't a language, it's a markup for a language" is just wrong. it's a language, being a superset of another language doesn't make it any less a language. Not being executed directly doesn't mean it's not a language either - JS is not executed either, it's compiled twice, first to an intermediate language then to machine code
every time i watch one of ThePrimeagen videos im like How the hell did it take me this long for find this guy? Quality superb, memes on point and most of all get some edu out of it xD
VERY INTERESTING! I would have assumed this outcome but wouldn't have guessed it was such a bloodbath. Thanks for doing this vid Prime, keen to see the other parts and maybe even more videos like it. Definitely makes me wonder if I should give Go a go for a cheeky rewrite of the work server to see if its viable before release 🤔
Great content Prime! You've inspired me to pick up Vim and continue learning coding. Last month I've got a job as a software developer in Amsterdam (without CS degree)! Thank you for everything!
I would have loved to have seen the results as you scale up on instance size. GO (in general) has a smaller memory footprint and overhead compared to Typescript. Considering the instance size was so low, I would not be surprised if the Typescript application quickly hit the point where it could no longer keep what it needed in memory and had to start allocating/deallocating it's resources, causing a cascading slowdown. I have worked in GO for years and I would 100 percent say it is my favorite language 90 percent of the time; however, GO's loose similarities with C and comparatively sparse built in functionality (what do you mean there is no built in contains?!) still cause it to be seen by some as arcane and unapproachable. This use case does scream in GO's favor as a language designed to underpin Google Cloud where optimizations for cases like these with heave socket traffic etc is high up on priority.
JS dev here. Thank you for making the video, it's an interesting way of comparing the performance of both runtimes. I noticed that in your JS server you're using a forEach function to iterate over the array of messages, this is generally considered a lot slower than loping over an array with a regular for loop. I don't think it would make Node outperform Go, but it would improve the performance of the Node quite a lot.
in my next one i will only use tight loops. I forget why I did a forEach. I usually find them cumbersome! But I genuinely appreciate how much time you put into something trying to give feedback.
do not forget that forEach is the current "recommended" way for doing loops (AFAIR in airbnb code style it's considered by default an error, or at least a warning in your code); of course writing easy reading code is something different than writing code which performs well (with the former preferred, because shit, the hardware is cheap nowadays), but that's another discussion
@@AlexCernat depends who's recommending - I've been writing both front & backend JS & TS for years and I always thought it was common knowledge that `forEach` was slow af!
@@hevans900 indeed, it's slower, but because the margin is relative small (they say) forEach() is preferred in terms of code readability; well, in a way it makes sense, because if we wanted maximum speed we should still use assembly :-P in fact any high level language, any framework, any ... anything :-P is about trading execution speed for development time
Now I have another reason to learn Go. But it would be interesting to do the comparison having written the Typescript server in the most efficient way vs the most efficient way in Go.
Just noticed you have some courses up on Frontend Masters. Congrats! That's awesome to see you still be your comedic self there and bring vim knowledge to these online learning websites. Icing on top was the use of a System76 laptop :D
@@ThePrimeagen oh that's cool, I only saw 2 up on FE masters. I'm guessing the 3rd one hasn't been released or is on a different platform? I watched the Vim fundies and the dev workflow courses.
It is a very useful comparison! With database async/await, it would get interesting because I really want to see if single threaded nature of Node js would use less memory and less time than Go or not!
awesome! I am excited to dive more into go. Its definitely my weakest language right now. Much better at rust (surprisingly) but go is already almost more productive than rust (despite 200 less hours spent in it).
Look, there is nothing to learn in go. Except channels it is pretty much nothing to it. Well it has a stupid concept of having resizable slizes, that aren't really resizable.
Go makes me want to cry. I largely prefer JS objects to structs or maps in go. To me it’s just more intuitive and with typescript you can type check your keys no problem.
I'm actually really excited to see where this goes. It be cool to see how other languages (maybe rust hm) works when compared to all the others. Could make it some kinda "drag race". I know @Dave's Garage did something similar but with Prime Numbers. Great video once again Prime :)
This was an amazing comparison! I love seeing good education on tools that should be used for their purposes. I use TS on the FE and Go on the BE and it will always be that way, because I use the right tool for the right job.
Please add another comparison. Go vs Java (in Spring/Micronaut or other ...). I'd also like to know the difference in memory footprint among them :-D Great work! Love benchmarks!
I am releasing a video tomorrow on just typescript. On how to improve its performance. I do talk about memory a touch. In fact quite a surprising result in playing with memory.
Would definitely be cool to see a video on RxJS next. Also, perhaps an example of what you replace RxJS with when you remove it from existing code. Thanks!
its pretty straight forward. There are a few gotchas coming from a single execution language like js (I don't say single threaded because v8 technically has tons of threads, just not exposed to you).
I thought that was a great video man. I think we all know the answer already for a Python vs Go speed comparison but I would love to hear your take on stats like that between the two plus the commentary of course 😎. A coworker mentioned a while back he would “check out Go” but I was already part of another project using Django and then Vue JS for the dynamic front end stuff. Cheers tho man. Excellent video
@@hello2ndchannel148 I didn't know that, but turns out it does. Even so, it's built with Rust and runs TS natively, instead of transpiling it into possibly more complex JS code.
it doesn't matter if deno was written in rust, v8 is built on top of C/C++, the operations V8 needs to do is far more than the operations your server will end up doing in golang. since JS doesn't have types, v8 needs very complex tricks to do JIT compilation, and it only kicks in after a function runs "hot", while in go because it has types, the bytecode it generates are very efficient. Which is not possible with anything JS. :)
This is a good video. Entertaining and a good comparison of the two languages and their environments. I also liked the minor usage of Rust and Python for incidental tasks. Experimentation should be fun and open. Good stuff. For the record I enjoy both Go and TS, but I'm using Go a lot more these days.
i have been using more and more rust for my simple scripts, and its really make me better at it. I can whip up a custom file parser doing something in about 10 minutes now, which feels nearish node pace. I am happy with that.
I would love to see a similar comparison for a lambda function(go vs node). I GO for it as I think this is the right way if u want to see an affordable check at the end of month from amz 😄
I discovered "the magical world of vim" thanks to you a few weeks ago and since then I can't stop watching your videos and learning more about it. Vim has become a drug. So... give us the master power, please. Give us pure speed and knowledge
Thank you for the comparison! I'd love to see a basic GraphQL server leveraging Prisma client. Both have TS/Go clients and are established in GraphQL. It would satisfy your connection to a database requirement for part 2.
I've not written anything in go or rust, so a comparison would be awesome, just like this is. Also, I'd love to hear your thoughts on what would make an ideal programming language for you, knowing what you know. thanks!
The toy example was to trivial to really get a good grip on it. But the basic usage of VmRSS was about 50 vs 80mb even in the smaller connections. Node definitely used more, but the servers were not doing much.
How about Go/Rust vs Erlang (Elixir+Phoenix+Ecto) on millions of concurrent connection per server, not pure calculation (which Erlang isn't good at). Erlang is good at low latency, concurrency, fault-tolerant, hot code swapping. I'm also interested on C# vs Go.
Yes these kind of comparisons are very interesting. I'm in wrong timezone for your twitch streaming, so summaries like this on RUclips are appreciated.
I've been binging your videos and I love the technical and performance stuff. I'm not about to rearchitect all of my software, but I love being aware of the trade offs I'm making by picking a language or coding style. Keep it up.
This was super sick! Would love an explanation by mr Prime (or anyone in the comments) as to why he was iffy on using Rust as a server backend. Rust has native threading options + socket support. Aren't those the only two components necessary for this test?
Rust is a really hard language. I feel bad telling people to use it because it promises speed, but it definitely comes a severe cost. To me, Rust has a place in companies that are large enough that a 10 - 50 person engineering team of experts doesn't largely affect their bottom line. That really limits it down to very few companies in comparison to something like go where a team of juniors could largely be successful.
@@ThePrimeagen OHHH ok - that makes sense. With the context of "pick up and play" in mind makes total sense why you'd go with.... go. Can't wait for part 2!
@@swagatochatterjee7104 Bro what? I wasn's saying Rust is easy to work with - I was just asking what his reasoning was for not including the language in his test. With that new context - I wholeheartedly agree with substituting rust for go. But to answer your question - yes.
@@swagatochatterjee7104 To give another serious answer to your question: Not in a loong time. I fight *alongside* the borrow checker these days. It is amazing how much you are able to do with Rust once you get over the initial stage of having no intuition about the borrow checker and other esoteric Rust features. I do agree with the point that Rust is hard, but I don't really I agree that it should be escewed in smaller companies. I lead a team that has some juniors, and we are currently setting up our second microservice with Rust. I am so excited about our results, that I am considering proposing to the team to transition our primary backend into Rust as well. I know this will be a pain for our juniors, but they are excited to learn, and I think the effort will pay for itself in the future by being easier to maintain and extend. If someone has worked for a year on production Rust code, and still complains about the borrow checker, they are definitely doing something wrong. It is the most amazing feature that rust has. (And no, I don't give one **** about runtime performance, I care about developer productivity.)
If anyone is surprised as the speed of Node, just remember that it uses V8 to execute javascript. The team behind V8 is the same one (mostly) that made the HotSpot VM for Java, so you know they really know what they're doing
Waiting for the next part... something involving databases and a real life load would be very cool although I'd like to mention even dealing with a shit ton of requests and knowing the capabilities in that aspect is a good use case to be at least aware about and go definitely wins in that one. Nice video!
Never used typescript nor go (embedded C++ and unfortunately also a lot of C), from the little I know about these languages I would expect go to win, nice to see my intuition was confirmed. Though I don't understand what happens with TS/Node that it blows up that much, I would be very interested to see a video explaining what happens in more detail. My guess is that it needs more than the memory available, (1GB of memory seems so much though for this benchmark, or maybe I didn't really understand it. In my world I've never used more than a few MB of memory, usually even less than 1MB of pre-allocated memory while processing a few GB of audio data per second) and deals with it by many unnecessary re-allocations? At least it seems it hits some barrier and then deals with that very poorly. Also I would expect you could write the TS code in a way that it could deal with the issue in a way it doesn't grow that badly.
That's something I want to know too. It would be great if the code could be written in another way that improves on performance. This seems pretty rough
@@dadestor So would you say it would almost never be worth it having a JS/TS program perform a highly CPU intensive task? I mean, for example, dealing with processing some sort of data for millions of users.
Ok, i was about to learn Node and then i came across your video. As someone who is coming back to programming for a better pay in the next year, i'm now officially confused where to go. haha! Nice video though. getting some doc vibes
Really nice video, I very much like to compare language performance with such a pragmatic approach. It would be nice to have a comparison between C++ and Go. I did myself a small experiment about that with several algorithms to sort arrays and Go outperformed C++. If that's the case, I wonder why anyone would use C++ at all for backend, considering its complexity. That goes assuming you don't need to access hardware directly of course.
C++ is more comparable to Rust and Go most certainly isn't faster than C++. I'd like to see your implementation though as it is easy to write inefficient C++ code even for trivial problems.
Hah! The never ending language comparisons. There is a fundamental problem even with my comparison is that it doesn't really represent a real world use case. I am curious to see what I can do to make it more "real world."
@@ItsMeDorian471 for the upcoming test, if you wish to do elixir I'd be happy. You will have to heavily comment sections for the uninitiated in elixir. Lastly, I'll have to heavily document exactly my expectation on outputs. Have you watched the latest RUclips video for typescript? That has the exact breakdown of the server I will be doing here soon.
I love Go because it is indeed blazingly fast. I did rewrite some of the most called APIs on our Java (not javascript) backend into Go and it gave us a big boost in performance. Now, sure, most of that performance gain was because the Java backend uses it's own complicated framework whereas the Go implementation is just Fiber, but it was very easy to port and fun experiment. No doubt that Go would be great as a Node replacement ... now would it be easy to write a tRPC Go version where it would generate an AppRouter type in TS for the frontend to use ... 🤔
I remember when i tried go there were dome things u could only do on linux, and i rly hated that u had to repeatedly check if function was null for error like in c, i also felt like i can make mistakes like in c. Rust is a total breath of fresh air the way u handle errors, u dont need to be afraid to get a seg fault if u dont use unsafe etc
Personally, while I do find something annoying the whole 'err != nil', I have to say it really helps with good error handling, after working with go for a while I started disliking try catch madness
been a node.js dev for years now and couldn't be less surprised. Before everyone else was doing non-blocking IO, node.js had an advantage....these days I don't see much reason to choose it. I feel like a a perf comparison with python/ruby/php would be more appropriate for node. And comparing golang with the like of java/dotnet
IDK, I've seen a *lot* of businesses still using node.js extensively on the backend, especially in BFF scenarios. So while those comparisons might be more fair in a sense, I think a lot of people reach for node because it's familiar when there are better options on the table.
Yeah. I'd be out of a job if it wasn't still used :-) If you have a BFF scenario and your web devs are js experts then ok. This is the situation where I am...but in the end the front end devs never took ownership and it was left to the backend devs anyway The other use case I guess is server side rendering of a web app
This doesn't seem to be TS problem based solely on the graphs: there seems to be a difference in the Big-O of the two implementations somewhere, as the TS graph starts increasing at a completely different pace based on the N. I couldn't get your code to build but maybe this is something worth looking into?
Trying to sell the idea of using other tools for the job, this video sure sold me on the subscribe button. Well done! Looking forward to a more elaborate example comparison!
From my experience Go is much easier to learn and write than TS/NodeJS, but I'd argue it's much harder to maintain due to duplication of code. It's very similar to React Native as it's incredibly easy to get started, but once you start doing slightly more complicated things it gets messy which is why I prefer languages which support DRY. If I needed to make a basic WS server I'd use Go, but if I wanted to make a larger WS server I'd reach for Rust. Just my opinion though.
@@jorisjansen2892 Go is faster by at least 100x we rewrote some cpu bound api's in go and so crazy performace gains. Though the key was cpu bound. We did the same for server that acted as middleware for our postgres db. Saw effectively no improvements
that is my next plan. a basic "real time" game server. no, we wont be using srtp or something, just meat and potatoes web sockets. Check out the repo if you are interested in the goals.
Being a JS Lover. I still loved this video a lot. Helps me make better informed decision about my backend stack and convincing my managers to use Go as my backend language.
I didn't forget to mention, this test just didn't really show much of a small foot print difference. Sure 60% more memory, but that was 50mb to 80mb. Still fairly small either direction. Next test should be better.
javascript is not a slow language, comparing a JIT compiled language to a AOT compiled language doesn't match very well, and you can call native C++ code from nodejs
Another fun, interesting video for sure, I love these kind of videos as exploring different programming languages always feel fun. I agree with you on Go being an extremely good choice where simplicity & performance are important factors. Have you given any thought on Elixir? It should perform closer to Go than javascript but working with it feels way more fun*/rewarding (which is subjective, I know). One caveat is that its a dynamic language and types can only be specified through typespecs (so it only helps finding bugs/inconsistencies, no compile time optimizations) Even then I'd love to know your opinion about it or to watch a future video comparing it to other languages. * Pattern match everything baby.
The big argument for using typescript over is not about performance, its about the ability to have front and back end in one language where they get to share resources. So often the requirements of a front-end are so similar to the back-end and with two different languages you're basically writing things twice all the time. Got a bug, fix it twice, or fix something that you don't realize needs to be fixed somewhere else. It's wild!
I'm a JS/TS and Go dev. I'm not surprised by the results at all. It's half the reason I also dev in Go, other half is it's the best for writing tiny docker images.
Waiting for the next part. Have been working on Node.js from quite a some time on low scale projects. This comparison just smashes Node.js on the ground. Diving the GO rabbit hole now. edit: typo
Love it! Please test Django vs NodeJS! Thats like apples with apples. Scale/Kotlin vs Django/NodeJS to show the performance loss for using a scripting language.
Great video! please do more of these! Elixir next (with Phoenix Channels)? Should be able to squeeze millions of connections on it easily due to the actor concurrency model
Go being designed by the guys that Built C/Unix, but with hindsight after decades, C++, Java, JS, etc is a huge win for the language IMO and we find a lot of benefits. Imagine the new langs that will come with hindsight of Go, rust, zig. Etc.
As a Go dev (but also JS/TS guy) it just makes me smile. Waiting for next part.
Awesome :)
True man
bru how do you use Go? i am fullstack JS
i want to dive on go but aside from restapi or graphql
i dont know how it is used?
@@pyakz6474 it is just much better at rest apis than JS. Much cheaper when you run it on AWS. Less RAM usage = low AWS bill.
@@andrzejstachlewski3662 have you use it on a large project? Did it scale? It seems like there is a defati structure for golang projects.
Damn NodeJS is like hell on earth.
Every projects i had, had their own different demons on their codebase.
I want something stable
Nice video. The times I used Go, it was an fun. There are some... Strangely opinionated design decisions, in my opinion, but I understand that some of that is changing. I also like the way newer languages like Rust and Go are providing a standardized ecosystem of tooling around the language.
this is exactly how I feel. I don't love all the decisions, but there is decisions and standards that make it easy to pick up the language. TypeScript's ecosystem is 1000% better than c++, but its definitely way behind rust / go .
@@ThePrimeagen as a TS dev, I'm curious, what ways it's behind rust/go?
I love the standardized ecosystems in rust and go. It means we don't have asshats creating new build systems and "golden paths" every day like we do for TS/JS. go is also a nice, simple language that's reasonably fast and easy to pick up and use. rust is not as easy but once you get the hang of it it's quite nice. typescript's type system is unbeatable though. if rust had TS's type system i would just about shit my pants. rust comes close (fixed size arrays, tuples, sum types) but if it had all the other TS stuff like intersection types, mapped types, conditional types, etc. i would lose my entire shit thru the fabric of my pants
Cool
@harleyspeedthrust4013 I'm not experienced at coding, but couldn't you create a crate that has typescript types you like? A crate that's basically an interpreter or something? How could we get this to work?
I'm currently getting into Go and Typescript as a noob, with the plan to graduate to Rust once I understand the basics of syntaxes etc. Everything on the internet is telling me not to learn Rust first..
I really enjoyed this, being primarily a JS/TS front-end dev with some Go experience in the last few months I fully expected Go to be more performant. I didn't expect the difference to be as big as it was though and I kinda wish you'd delved into why that might be. Hoping to see a part 2
My next video will be definitely much more comprehensive, and I think that will be more telling of the difference between go and typescript.
I've tried to use golang but it's the most insufferably designed language I've used and typescript is just so much better. Nils can crash your program and there's 0 proper safeguard against them, much weaker type system, no union types, literally use public/private access modifiers by capitalizing functions, spent about 45 minutes getting imports to work because it has to be different and have the weirdest import system i've used to date (it's literally easier in rust which is even faster than go), its source repository is github, so you import the master branch of libraries which leads to random bugs/issues, and a lot of the standard libraries are also weirdly annoying like bubbletea which forces you into elm architecture to make things more convoluted. to this day idk why people like it
The extra code you write in typescript is worth it because it lets you write enterprise, stable organized software that lasts and doesn't become spaghetti code down the line that's why most startups use it and why it was designed that way. That's why OOP, classes, types, interfaces, etc exist because it gives structure and organization to your code
I think what really should be mention videos is that golang is just "typescript but better and faster", there's a massive tradeoff and that is code quality. If you're looking for something like typescript but is faster dotnet is a much better choice.
I do mean what I said at the end. The likes, comments, subscribes, and shares are a way in which I gauge how much the audience is interested in this topic. So if you like this, want more, etc etc, please help me by engaging. It sends the most clear signal. I also don't want to be that guy that tells you to like / subscribe at the beginning of every video, so this is my way of doing it, at the end, with very little prompting. IF YOU LIKE THIS, THEN TELL ME YOU LITTLE ALGO INDUCERS
I also want to make it clear that this is a toy example and there is always incorrectnesses with toy examples. The reality lies somewhere between the lines. Its really hard to create two identical large scale servers.... almost impossible with a beautiful wife, 4 kids, and a full time job. But my goal is to continue to build this up into a series of fun experiments.
Where’s pt2?
Always love Go content! More comparisons and especially Go performance analysis is always great to see.
yeah, I want to play more with it.
Being DISGUSTED by TS performance is a wonderful start to the work week.
You are welcome :)
Well, TS wasn't what was executed, it's not a language, it's markup for a language.
What do you mean it isnt a language? Just because its translated into another language doesnt mean its not a language. Javascript is not executed either. Its compiled into an intermediate language, which isnt executed either, but compiled further into machine instructions
@@garad123456true, TS can still be classified as a language but his statement wasn't entirely false either. It's not TS that's being executed it's the transpiled JS.
@@ichigo_kurosaaki Well, in the context that he replied to, it's correct that TS doesn't affect the performance, but to say it "isn't a language, it's a markup for a language" is just wrong. it's a language, being a superset of another language doesn't make it any less a language. Not being executed directly doesn't mean it's not a language either - JS is not executed either, it's compiled twice, first to an intermediate language then to machine code
every time i watch one of ThePrimeagen videos im like How the hell did it take me this long for find this guy? Quality superb, memes on point and most of all get some edu out of it xD
that is the goal.
As a self proclaimed TS fan boy, I'll admit that you've convinced me to take a look at Go this weekend.
VERY INTERESTING! I would have assumed this outcome but wouldn't have guessed it was such a bloodbath. Thanks for doing this vid Prime, keen to see the other parts and maybe even more videos like it. Definitely makes me wonder if I should give Go a go for a cheeky rewrite of the work server to see if its viable before release 🤔
I thought it was pretty absurd the difference
Great content Prime! You've inspired me to pick up Vim and continue learning coding. Last month I've got a job as a software developer in Amsterdam (without CS degree)! Thank you for everything!
I would have loved to have seen the results as you scale up on instance size. GO (in general) has a smaller memory footprint and overhead compared to Typescript. Considering the instance size was so low, I would not be surprised if the Typescript application quickly hit the point where it could no longer keep what it needed in memory and had to start allocating/deallocating it's resources, causing a cascading slowdown.
I have worked in GO for years and I would 100 percent say it is my favorite language 90 percent of the time; however, GO's loose similarities with C and comparatively sparse built in functionality (what do you mean there is no built in contains?!) still cause it to be seen by some as arcane and unapproachable. This use case does scream in GO's favor as a language designed to underpin Google Cloud where optimizations for cases like these with heave socket traffic etc is high up on priority.
Great comparison! Thanks for taking the time and testing it. Please make the video about database async handling.
That's on the docket
JS dev here. Thank you for making the video, it's an interesting way of comparing the performance of both runtimes.
I noticed that in your JS server you're using a forEach function to iterate over the array of messages, this is generally considered a lot slower than loping over an array with a regular for loop. I don't think it would make Node outperform Go, but it would improve the performance of the Node quite a lot.
in my next one i will only use tight loops. I forget why I did a forEach. I usually find them cumbersome! But I genuinely appreciate how much time you put into something trying to give feedback.
do not forget that forEach is the current "recommended" way for doing loops (AFAIR in airbnb code style it's considered by default an error, or at least a warning in your code); of course writing easy reading code is something different than writing code which performs well (with the former preferred, because shit, the hardware is cheap nowadays), but that's another discussion
@@AlexCernat depends who's recommending - I've been writing both front & backend JS & TS for years and I always thought it was common knowledge that `forEach` was slow af!
@@hevans900 indeed, it's slower, but because the margin is relative small (they say) forEach() is preferred in terms of code readability; well, in a way it makes sense, because if we wanted maximum speed we should still use assembly :-P in fact any high level language, any framework, any ... anything :-P is about trading execution speed for development time
What makes a foreach with a callback more readable than the enhanced for ?!! It's the other way around
Great video, I definitely wanna see more like this. Go vs python would be cool!
I want to do more comparison stuffs. I have an idea for the next.
go would destroy python in backend, i think even node wud be faster than python
Why would you compare python and go.... python was never built for speed in mind ... you are comparing an SUV to a truck
Now I have another reason to learn Go. But it would be interesting to do the comparison having written the Typescript server in the most efficient way vs the most efficient way in Go.
100% agreed. This is also a fairly niche case and not the general case for building a backend web app
Tell you the truth, in real world, companies doesn't use TS/JS with Node.js. The most used languages are Java/C# and Go at the backend.
@@klarnorbertnodejs is on par with go for backend in terms of popularity
Just noticed you have some courses up on Frontend Masters. Congrats! That's awesome to see you still be your comedic self there and bring vim knowledge to these online learning websites. Icing on top was the use of a System76 laptop :D
yayayayaya! It was great. I actually have 3 courses
@@ThePrimeagen oh that's cool, I only saw 2 up on FE masters. I'm guessing the 3rd one hasn't been released or is on a different platform? I watched the Vim fundies and the dev workflow courses.
It is a very useful comparison! With database async/await, it would get interesting because I really want to see if single threaded nature of Node js would use less memory and less time than Go or not!
nodejs sucks at that because of single thread serialization/deserialization
Holy moly dude.This is my first video here.And I'm never gonna go away from this channel xD
yayaya! I have updated this video a couple times too! My performance list has 4 videos in it and about to have a 5th
As a full-on JS dev I loved this video. Got me really hyped to learn Go
awesome! I am excited to dive more into go. Its definitely my weakest language right now. Much better at rust (surprisingly) but go is already almost more productive than rust (despite 200 less hours spent in it).
no you are misguided.. go is trash.. better use c# instead..
C++ make you surprised
Look, there is nothing to learn in go. Except channels it is pretty much nothing to it. Well it has a stupid concept of having resizable slizes, that aren't really resizable.
Go makes me want to cry. I largely prefer JS objects to structs or maps in go. To me it’s just more intuitive and with typescript you can type check your keys no problem.
Part 2 needs to be database and I/O bound. That said, both Typescript and Go are both great languages.
Typescript isn't a language dammit
@@forbiddenera What is it then?
@@behnamesmaili9916 a dialect
@@bchdev 😂😂
I'm actually really excited to see where this goes. It be cool to see how other languages (maybe rust hm) works when compared to all the others. Could make it some kinda "drag race". I know @Dave's Garage did something similar but with Prime Numbers. Great video once again Prime :)
This is my new sales pitch for Golang (which I desperately needed). Excellent content, keep it up!
This was an amazing comparison! I love seeing good education on tools that should be used for their purposes. I use TS on the FE and Go on the BE and it will always be that way, because I use the right tool for the right job.
Excited for the next parts! Subscribed! But please also update the description of this video with links to the newer parts.
they are in the perf play list.
@@ThePrimeagen got it thanks!
This was really nice to watch. Thank you and keep doing a great job with these videos. Love them 😀
No problem :)
Prime, what a banger, again.
As a junior js/ts dev, this comparison is amazing!
I just planned a golang binge learn weekend, thanks for that
I think going is amazing. I'm doing a more complex server right now on twitch. I think that it will be a significantly better comparison.
Please add another comparison. Go vs Java (in Spring/Micronaut or other ...). I'd also like to know the difference in memory footprint among them :-D Great work! Love benchmarks!
I am releasing a video tomorrow on just typescript. On how to improve its performance. I do talk about memory a touch. In fact quite a surprising result in playing with memory.
Would definitely be cool to see a video on RxJS next. Also, perhaps an example of what you replace RxJS with when you remove it from existing code. Thanks!
RxJS has a high chance of making it in the next video.
Enjoyed the video. Curious to see what the results going to be for part 2. Not a fan of go as of yet, but could be cool to try 🤭
This was very good! I am waiting for Rust (or other common languages) to kick in. Can't wait for part 2!
almost done with it. I have the data, now its recording time!
I am a javascript developer and I have never written go. But I am intrigued to learn go after watching this
its pretty straight forward. There are a few gotchas coming from a single execution language like js (I don't say single threaded because v8 technically has tons of threads, just not exposed to you).
I thought that was a great video man. I think we all know the answer already for a Python vs Go speed comparison but I would love to hear your take on stats like that between the two plus the commentary of course 😎. A coworker mentioned a while back he would “check out Go” but I was already part of another project using Django and then Vue JS for the dynamic front end stuff. Cheers tho man. Excellent video
Rather than making the scenario more complex, I'd like to see if a deno server fares any better. 🤔
@@hello2ndchannel148 I didn't know that, but turns out it does. Even so, it's built with Rust and runs TS natively, instead of transpiling it into possibly more complex JS code.
I'd also be super keen to see this!
Yes please! I'm interested in Deno performance comparison as well! Thanks! Great video, very fun to watch! Thanks for doing it!
@@rachit-sharma No deno does not run TS natively, it runs on v8, v8 does not run typescript. Rust transpiles your TS to JS and then hands it to v8.
it doesn't matter if deno was written in rust, v8 is built on top of C/C++, the operations V8 needs to do is far more than the operations your server will end up doing in golang.
since JS doesn't have types, v8 needs very complex tricks to do JIT compilation, and it only kicks in after a function runs "hot", while in go because it has types, the bytecode it generates are very efficient. Which is not possible with anything JS. :)
This is a good video. Entertaining and a good comparison of the two languages and their environments. I also liked the minor usage of Rust and Python for incidental tasks. Experimentation should be fun and open. Good stuff. For the record I enjoy both Go and TS, but I'm using Go a lot more these days.
i have been using more and more rust for my simple scripts, and its really make me better at it. I can whip up a custom file parser doing something in about 10 minutes now, which feels nearish node pace.
I am happy with that.
@@ThePrimeagen Bold! I can spend 10 mins just cursing the borrow-checker!
I would love to see a similar comparison for a lambda function(go vs node). I GO for it as I think this is the right way if u want to see an affordable check at the end of month from amz 😄
that seems neet. I have some ideas for the next set of comparisons.
@@ThePrimeagen this☝🏻
I've recently discovered this channel and I must say, his passion for programming gives me Goosebumps every single time I watch his videos :D
hio! its exciting to make things
Always great content from this guy!
Thank you Frank. You comment quite frequently and I appreciate that :)
I discovered "the magical world of vim" thanks to you a few weeks ago and since then I can't stop watching your videos and learning more about it. Vim has become a drug. So... give us the master power, please. Give us pure speed and knowledge
Thank you for the comparison! I'd love to see a basic GraphQL server leveraging Prisma client. Both have TS/Go clients and are established in GraphQL. It would satisfy your connection to a database requirement for part 2.
Great content Prime! Can't wait for the follow up. I'd also be interested to see some Haskell in some videos of this kind
! Haskell?? THe language of the lord? I don't know about this!
@@ThePrimeagen you got to have some faith brother! XD
I've not written anything in go or rust, so a comparison would be awesome, just like this is. Also, I'd love to hear your thoughts on what would make an ideal programming language for you, knowing what you know. thanks!
As a front-end developer, I LOVE JS/TS. but as a back-end developer?! SUPER NAAAH!
reasonable stance
loved the content
The toy example was to trivial to really get a good grip on it. But the basic usage of VmRSS was about 50 vs 80mb even in the smaller connections. Node definitely used more, but the servers were not doing much.
Awesome! You just convinced me that in 2022 I should learn Go. Definitely, I want more from you such stuff!
Hello sir
How about Go/Rust vs Erlang (Elixir+Phoenix+Ecto) on millions of concurrent connection per server, not pure calculation (which Erlang isn't good at). Erlang is good at low latency, concurrency, fault-tolerant, hot code swapping. I'm also interested on C# vs Go.
Yes these kind of comparisons are very interesting. I'm in wrong timezone for your twitch streaming, so summaries like this on RUclips are appreciated.
I'll continue to do this! for you babe.
Now this is some killer content. Well done. Loved it.
Thank you ! It was tons of fun to build :)
I've been binging your videos and I love the technical and performance stuff. I'm not about to rearchitect all of my software, but I love being aware of the trade offs I'm making by picking a language or coding style. Keep it up.
Might have to try out making a GraphQL API with go, I would love to try out other languages than what I get paid for
I think GraphQL is implemented in several languages.
GraphQL and Rust works pretty well (yes syntactically).
This was my favorite video by far! I loved the slow Walk of Shame that TypeScript was taking. Keep it up! This format was awesome! 🤘
This was super sick! Would love an explanation by mr Prime (or anyone in the comments) as to why he was iffy on using Rust as a server backend. Rust has native threading options + socket support. Aren't those the only two components necessary for this test?
Rust is a really hard language. I feel bad telling people to use it because it promises speed, but it definitely comes a severe cost.
To me, Rust has a place in companies that are large enough that a 10 - 50 person engineering team of experts doesn't largely affect their bottom line. That really limits it down to very few companies in comparison to something like go where a team of juniors could largely be successful.
@@ThePrimeagen OHHH ok - that makes sense. With the context of "pick up and play" in mind makes total sense why you'd go with.... go. Can't wait for part 2!
Have you fought the borrow checker under a deadline?
@@swagatochatterjee7104 Bro what? I wasn's saying Rust is easy to work with - I was just asking what his reasoning was for not including the language in his test. With that new context - I wholeheartedly agree with substituting rust for go.
But to answer your question - yes.
@@swagatochatterjee7104 To give another serious answer to your question: Not in a loong time. I fight *alongside* the borrow checker these days. It is amazing how much you are able to do with Rust once you get over the initial stage of having no intuition about the borrow checker and other esoteric Rust features.
I do agree with the point that Rust is hard, but I don't really I agree that it should be escewed in smaller companies. I lead a team that has some juniors, and we are currently setting up our second microservice with Rust. I am so excited about our results, that I am considering proposing to the team to transition our primary backend into Rust as well. I know this will be a pain for our juniors, but they are excited to learn, and I think the effort will pay for itself in the future by being easier to maintain and extend.
If someone has worked for a year on production Rust code, and still complains about the borrow checker, they are definitely doing something wrong. It is the most amazing feature that rust has. (And no, I don't give one **** about runtime performance, I care about developer productivity.)
If anyone is surprised as the speed of Node, just remember that it uses V8 to execute javascript. The team behind V8 is the same one (mostly) that made the HotSpot VM for Java, so you know they really know what they're doing
its impressively fast for what it does, but its depressingly slow when compared with things that are fast
Would be interesting to see how kotlin + ktor fared in this comparison. Most likely slower than go, but hopefully better than typescript.
Yeah man +1
Waiting for the next part... something involving databases and a real life load would be very cool although I'd like to mention even dealing with a shit ton of requests and knowing the capabilities in that aspect is a good use case to be at least aware about and go definitely wins in that one. Nice video!
Never used typescript nor go (embedded C++ and unfortunately also a lot of C), from the little I know about these languages I would expect go to win, nice to see my intuition was confirmed.
Though I don't understand what happens with TS/Node that it blows up that much, I would be very interested to see a video explaining what happens in more detail.
My guess is that it needs more than the memory available, (1GB of memory seems so much though for this benchmark, or maybe I didn't really understand it. In my world I've never used more than a few MB of memory, usually even less than 1MB of pre-allocated memory while processing a few GB of audio data per second) and deals with it by many unnecessary re-allocations? At least it seems it hits some barrier and then deals with that very poorly.
Also I would expect you could write the TS code in a way that it could deal with the issue in a way it doesn't grow that badly.
That's something I want to know too. It would be great if the code could be written in another way that improves on performance. This seems pretty rough
It's not memory. JS is not very CPU efficient and is single threaded
@@dadestor So would you say it would almost never be worth it having a JS/TS program perform a highly CPU intensive task? I mean, for example, dealing with processing some sort of data for millions of users.
Ok, i was about to learn Node and then i came across your video. As someone who is coming back to programming for a better pay in the next year, i'm now officially confused where to go. haha! Nice video though. getting some doc vibes
Really nice video, I very much like to compare language performance with such a pragmatic approach. It would be nice to have a comparison between C++ and Go. I did myself a small experiment about that with several algorithms to sort arrays and Go outperformed C++. If that's the case, I wonder why anyone would use C++ at all for backend, considering its complexity. That goes assuming you don't need to access hardware directly of course.
C++ is more comparable to Rust and Go most certainly isn't faster than C++. I'd like to see your implementation though as it is easy to write inefficient C++ code even for trivial problems.
This was very fun to watch! Thank you, Prime! Waiting for part 2 💫
yayayayaya! I think RxJS and a more complete server is up next.
Now that you put yourself in the quicksand that is language comparisons, it's time to do PHP 8.1 vs GO
Hah! The never ending language comparisons.
There is a fundamental problem even with my comparison is that it doesn't really represent a real world use case. I am curious to see what I can do to make it more "real world."
@@ThePrimeagen you could attach a database and include some calls to that
Thank you for the great video
Would love to see rust vs go server performance in multiple scenario like single thread, multi thread server performance
Its just _really_ hard to do this well. I am going to try though. I am going to do something that I can spread across multiple nodes.
Really curious where a BEAM language (e.g. Erlang, Elixir, Gleam) would land on those charts.
That would require me to learn :)
@@ThePrimeagen Elixir at least is not difficult to learn. Give it a shot. Or not x)
Or yesssss you won't regret that
@theprimeagen if you are open to contributions i am happy to translate the implementation to Elixir
@@ItsMeDorian471 for the upcoming test, if you wish to do elixir I'd be happy.
You will have to heavily comment sections for the uninitiated in elixir.
Lastly, I'll have to heavily document exactly my expectation on outputs.
Have you watched the latest RUclips video for typescript? That has the exact breakdown of the server I will be doing here soon.
I love Go because it is indeed blazingly fast. I did rewrite some of the most called APIs on our Java (not javascript) backend into Go and it gave us a big boost in performance.
Now, sure, most of that performance gain was because the Java backend uses it's own complicated framework whereas the Go implementation is just Fiber, but it was very easy to port and fun experiment.
No doubt that Go would be great as a Node replacement ... now would it be easy to write a tRPC Go version where it would generate an AppRouter type in TS for the frontend to use ... 🤔
I remember when i tried go there were dome things u could only do on linux, and i rly hated that u had to repeatedly check if function was null for error like in c, i also felt like i can make mistakes like in c. Rust is a total breath of fresh air the way u handle errors, u dont need to be afraid to get a seg fault if u dont use unsafe etc
yeah, rust is nice, but its more challenging than I venture most companies are willing to bet on.
Personally, while I do find something annoying the whole 'err != nil', I have to say it really helps with good error handling, after working with go for a while I started disliking try catch madness
need this content streamed directly to my brain
been a node.js dev for years now and couldn't be less surprised. Before everyone else was doing non-blocking IO, node.js had an advantage....these days I don't see much reason to choose it.
I feel like a a perf comparison with python/ruby/php would be more appropriate for node. And comparing golang with the like of java/dotnet
IDK, I've seen a *lot* of businesses still using node.js extensively on the backend, especially in BFF scenarios. So while those comparisons might be more fair in a sense, I think a lot of people reach for node because it's familiar when there are better options on the table.
Yeah. I'd be out of a job if it wasn't still used :-)
If you have a BFF scenario and your web devs are js experts then ok. This is the situation where I am...but in the end the front end devs never took ownership and it was left to the backend devs anyway
The other use case I guess is server side rendering of a web app
@@MrSkinbad yeah, we have node for React SSR which is the space I'm in for my current gig. But the backend-backend is in Go and Java/Kotlin
Very well, I'm convinced. Will give Go a try. Thanks for the amazing content!
This doesn't seem to be TS problem based solely on the graphs: there seems to be a difference in the Big-O of the two implementations somewhere, as the TS graph starts increasing at a completely different pace based on the N. I couldn't get your code to build but maybe this is something worth looking into?
Trying to sell the idea of using other tools for the job, this video sure sold me on the subscribe button. Well done! Looking forward to a more elaborate example comparison!
From my experience Go is much easier to learn and write than TS/NodeJS, but I'd argue it's much harder to maintain due to duplication of code. It's very similar to React Native as it's incredibly easy to get started, but once you start doing slightly more complicated things it gets messy which is why I prefer languages which support DRY. If I needed to make a basic WS server I'd use Go, but if I wanted to make a larger WS server I'd reach for Rust. Just my opinion though.
Yeah Go is very simple, but it’s sometimes *too* simple
Nice and agree, JS/TS has really great Reactive tool implementation (RxJS), hopefully can make another episode for that to compare "scale from small".
i am working on the rxjs one right now. I have made decent progress.
This is insane, didn't expect that the differences where so huge! How about TS vs Python?
as a Python/TS dev Ill say Python will loose
@@kirillgimranov4943 that what I guess as well!
I use python in production, but it is slow af. We just throw more servers at the problem :D
@@deidyomega That's what we do aswell, but I'm really thinking about rewriting some stuff in Go if that makes a huge difference!
@@jorisjansen2892 Go is faster by at least 100x we rewrote some cpu bound api's in go and so crazy performace gains.
Though the key was cpu bound. We did the same for server that acted as middleware for our postgres db. Saw effectively no improvements
Not surprised by the outcome but loved the video 👍 I can only imagine the disparity gets worse as the benchmark complexity goes up
that is my next plan. a basic "real time" game server.
no, we wont be using srtp or something, just meat and potatoes web sockets. Check out the repo if you are interested in the goals.
Go will always win, ITS THE BEST
Rust seems fun, but man its such a pain in the iron.
@@ThePrimeagen I tried Rust out the moment I was trying out Go for creating a simple rest API and man it think its so convoluted
Thank you. It's nice to have something fun but objective to point people to. I am dealing with some teams pushing Node and . . . well, thanks.
well, there is going to be more comparisons coming in shortly.
I do wonder how much impact async/await has.
My guess its non trivial. But!!! I want to try it out. I also want to try rxjs.
would love to see that impact as well!
Loved the vídeo and Stream, I also love the rxjs idea even I when I don't know anything about functional programming :)
Rxjs is neet :kappa:
Being a JS Lover. I still loved this video a lot. Helps me make better informed decision about my backend stack and convincing my managers to use Go as my backend language.
well. Hopefully there is another one :)
@@ThePrimeagen I don't mix my work and feelings
This is great, I'm switching my backends to golang. Not only for speed, but also for it's small footprint, which you forgot to mention.
I didn't forget to mention, this test just didn't really show much of a small foot print difference. Sure 60% more memory, but that was 50mb to 80mb. Still fairly small either direction.
Next test should be better.
Dude... your energy is awesome. Please keep these types of videos and style of videos coming.
This is one of your absolute best videos in my opinion. I love all your videos but this one is my favorite.
Your RUclips videos are dope AF, I need to come and follow, haven't done it in a while.
well thank you
What a great video, thanks and please keep it up prime!
Just out of curiosity: why does Netflix use so much Node, if Go is much faster?
javascript is not a slow language, comparing a JIT compiled language to a AOT compiled language doesn't match very well, and you can call native C++ code from nodejs
Looks great! Learning backend with node and want to have a look on go.
Learning backend with Node is a _great_ way to learn. I think node has a lot of benefits.
Yeah. Finished my first app. Now I'm gonna train the concepts and move to next language.
@@ThePrimeagen this video made me think of learning go again. It looks pretty simple. What I am also interested in is how fast ruby is
Another fun, interesting video for sure, I love these kind of videos as exploring different programming languages always feel fun. I agree with you on Go being an extremely good choice where simplicity & performance are important factors.
Have you given any thought on Elixir? It should perform closer to Go than javascript but working with it feels way more fun*/rewarding (which is subjective, I know). One caveat is that its a dynamic language and types can only be specified through typespecs (so it only helps finding bugs/inconsistencies, no compile time optimizations) Even then I'd love to know your opinion about it or to watch a future video comparing it to other languages.
* Pattern match everything baby.
one day I may explore it. Time is too limited to explore everything :(
@@ThePrimeagen An unfortunate truth for sure hahah.
Thanks for all the content anyway, I always tune in when our schedules match on twitch!
The big argument for using typescript over is not about performance, its about the ability to have front and back end in one language where they get to share resources. So often the requirements of a front-end are so similar to the back-end and with two different languages you're basically writing things twice all the time. Got a bug, fix it twice, or fix something that you don't realize needs to be fixed somewhere else. It's wild!
Hey, I am super excited and I want to see. Thanks for producing content! Cheers from Berlin.
I'm a JS/TS and Go dev. I'm not surprised by the results at all. It's half the reason I also dev in Go, other half is it's the best for writing tiny docker images.
yayaya! Agreed.
Waiting for the next part. Have been working on Node.js from quite a some time on low scale projects. This comparison just smashes Node.js on the ground. Diving the GO rabbit hole now.
edit: typo
Love it! Please test Django vs NodeJS! Thats like apples with apples. Scale/Kotlin vs Django/NodeJS to show the performance loss for using a scripting language.
I am unsure how far i will go with the comparisons if I will do that stuff.
yes PRIME - MORE MORE MORE!! lol
great job, bro. always luv yo content.
please continue with this bro this is amazing thank you
You are welcome
As a full stack dev, having the same language for the frontend / app and the backend is a blessing.
This is a different type of optimization.
@@ThePrimeagen *indeed*
Can't wait for the next part, preparing the coconut oil
This was fascinating, really challenges the dogma that EvERYthINg CaN BE doNE In JS! Please do one with DB operations
Great video! please do more of these! Elixir next (with Phoenix Channels)? Should be able to squeeze millions of connections on it easily due to the actor concurrency model
Backend Language comparisons are always helpful
I clicked at this thinking "of course Go is faster who would say otherwise", but I enjoyed the video and your humor nonetheless :)
Awesome. This Friday I should be releasing a video on Rust versus go.
Go being designed by the guys that Built C/Unix, but with hindsight after decades, C++, Java, JS, etc is a huge win for the language IMO and we find a lot of benefits. Imagine the new langs that will come with hindsight of Go, rust, zig. Etc.
Would love to watch you doing a series on programming lang comparisons
You never know!! It has a chance.
Awesome stuff man!
You just got a sub after 2 videos XP
most awesome