Go vs Rust vs Bun vs Node | Prime Reacts

go versus rust versus bun versus Note a simple HTTP Benchmark okay let's start with let's start with the Y well it looks like there's actually a bunch of stuff before the Y the the table of contents is missing the the I guess the foreplay all right the pre-why recently button 1.0 was released which shows promise as a tool for serving many users without using too many resources to evaluate its performance a simple benchmark test was created to measure the number of HTTP calls the server could handle per second The Benchmark also Compares bun with go rust and node as these languages are frequently compared in other benchmarks using similar purposes okay the benchmark test by the way I have a very hot hot take but I refuse to give it right now but this take is going to be a scalding hot scalding okay so get ready for the scalder uh The Benchmark uh test was a run both locally and on the Node server I love okay good I love to see this I love the lenode server take uh with two dedicated CPU cores with four gigabytes of RAM running Debian 11 on lenode all four tests were compiled uh and run using the following commands all right run build Minify index out file Benchmark okay good and then run the Benchmark cargo build Target rust okay go build okay good good good good good good uh node Benchmark okay the test will run on the following runtime versions arrest uh 174 okay 121 1 and 2006. okay so the latest environments this is good because the difference between node 18 and node 20 there's actually quite a few performance improvements all right to Benchmark eat uh and it's it's to do with V8 more than anything else to benchmark test each runtime go uh rusco node and Bun were built for production usage and the same test was a run for each language the test was connected with 100 concurrent connections running for one minute and all of the runtime you utilized multi-threading okay so here's my real question did this person whoever wrote this uh Emil did you run it from your computer or a series of one or more computers in lenode that's my first question right away because if you're running it from your own machine even as the test client I mean it's not as good of a test if you aren't running from your own machine you know what I mean it's always better to run from your own machine I mean a run from not your own machine not not let's see the HP test we're running using this uh right here okay WG work all the languages use built-in HTTP servers except for rust which uses axum and Tokyo because rust doesn't come with the built-in HTTP server Fair it has a TCP server but not an HTTP server uh the let's see the source code for these can be found here okay why before I show you the results I'd like to explain why I conducted this test mainly out of curiosity I wanted to see if there is a JS runtime that can perform almost as fast as rust or go I'm not a huge fan of JS in general mainly because I don't enjoy writing the language that's perfectly valid but I also feel that there hasn't been a JS runtime that is good enough the JS World got Dino a while ago which seems a bit faster but still not good enough okay okay again by scalding hot take is boiling inside of me it's trying to come out I'm not letting it come out in the real world the bottlenecks in your system probably wouldn't uh probably not be the run time it would probably be something else such as your database or Ingress Etc uh we can we can see this if we look at the results of running the test in the cloud this type of test may not be the best but it still provides a good indication of buns performance compared to others with this we are now at the run time that we could have a good choice uh when building businesses okay there's probably a better way to conduct this type of test probably by running a websocket with numerous clients listening to the socket to determine which running performs the best however this is a test for another time I don't really get this end part but it's good that he recognizes that this isn't necessarily a great test and that in the real world your bottlenecks aren't usually what's being tested right now right Fair or in the test locally all right uh first rust okay latency this thing uh obviously this none of this really matters right here request a second okay we got 8.87 K requests a second we did this many requests in 30 seconds uh this much okay awesome awesome awesome then go go also looking pretty girth pretty girthy a little bit different though look at that a little bit different about the same amount less megabytes red requests per second not as good then bun not as good as go as you can see right here okay and then node node came in you know that meme you know the beam where it's like the I don't even want to say the name it's going to give me it's going to get me canceled okay you know no tried okay node tried dude you haven't seen URL parser does it have the Ada parser does it have the Ada parser in it because if it had the eight of parser it'd probably be 10 times faster honestly 10 times faster when running a test locally we see that Russ serves more requests per second compared to the other options okay yeah that's probably not too surprising I don't think anyone's necessarily surprised by this um yeah I mean the differences should be fairly minimal between these Frameworks I'm actually surprised it's this bad honestly I'm actually surprised it is this bad that the difference between fun and say rust or bun and go is that far off because like the reality is garbage collection happens in C plus plus HTTP processing and everything happens in C plus plus every part of this is C plus plus so why is it this much different I mean buns obviously Zig instead of C plus plus and go as go or whatever whatever do however they work and rust is I think rust rust writes rust itself but either way it just breaks down to you know a series of syscalls I can't imagine that one's better than the other somehow that's why it's just so surprising that I'm saying this all right testing locally uh it's time to speed uh let's see time it yeah all right here we go it is time to test the speed of each runtime in serializing and returning simple Json strings the task is to serialize a simple Json struct in return okay so this is actually a better test because really what you're going to see so I hope the longevity of the test is there you really do need to run this over the course of a couple minutes which is you want to see garbage collection let's begin with rust and there's another thing that I'm going to talk about here shortly uh with this test rust okay so somehow it is somehow let's see four three four two three 423 it is pretty much the same speed right nothing about it is much different not too surprising very little Works actually going go pretty much the same speed bun drastic fall down that's actually a bit surprising that bun suffered that much from a Json stringify locally now obviously there could be a lot of questions what's going on blah blah blah but nonetheless I'm surprised it suffered that hard from Json stringifying effectively a constant right because if you remember the other one uh you know the other one is about 10 faster and node 's about the same right if you look right here no didn't change no change like rust didn't change right it's effectively the same thing okay so that's interesting to me it says maybe there's something going on with bun and bun doesn't have a good Json whatever uh I'd say I thought they would have pulled uh that into native Zig or something Json is so core to JavaScript well no it should be it's it's within the JavaScript engine it wouldn't be in Zig it'd be within the JavaScript engine it'd be within um uh JavaScript core that's Safari so maybe the Safari implementation of of java uh json.stringify or json.parse isn't quite there read proven's message um pravan say your message to my face right now I can just shortcut it honestly I can just shortcut it oh hold up that's my article roasting me let's go getting roasted get roasted kid okay so I'm actually more surprised by how much bun faltered because go didn't change rust didn't change no didn't change bun really changed that's okay that's a bit surprising that's something to investigate that's kind of interesting running uh the test in the cloud it's time to run the same test in the cloud by the way pravan I really love that you put it also up in lenode and you do like a cloud test I think that that's very good uh this time I have spun up a server with a dedicated CPU in Stockholm oh you're having a little bit of Stockholm syndrome as they call it to avoid limitations I am running The Benchmark from my local computer to the server okay so that can be a little bit I'm a little worried about that but okay uh if I were to run a client server within the node I would uh be limited to choosing only two dedicated CPUs without creating a support ticket additionally my local computer has more cores and internet connection that is good enough for the test fine at least they're all running the same thing I've also increased the number of connections to the server in order to achieve better results okay test testing returning only a simple string is this the Json one I assume this is like the or this is just a simple string all right so rust obviously a huge downgrade this all makes perfect sense if you think about it I'm a little worried about the connection uh and all these things just because this is where you know I see things just fall apart especially locally usually whenever I do something that has a lot of connections I I tend to break it onto several machines uh all in the cloud but I get the idea was looking good okay go Yep this makes sense bun all right bun is now sitting equal with rust what this tells me is that I did you did you run SAR by any chance and just like see the network utilization and the and the server utilization and all that here DDOS your own server absolutely in the name of science because I'd be curious what's the running speed I have that vmrss script as well to see how much memory things are taken up yeah no I saw I saw the link to it but I was just wondering if you ran any of the SAR stuff to look at how much uh CPU is actually being taken and finally no node again or can we all get an rip node I feel bad for no no just always coming in all right testing of Json so this will be interesting so rust again pretty much same speed right 713 718 yeah maybe a one percent difference go same thing uh wait does did go did go get faster somehow go got faster again maybe not long enough tests I mean this is so this would be one of the problems with this type of test right you gotta let it run for a while usually kind of isolate any of these weird issues so go somehow got faster doubt right hashtag doubt um bun bun still doing great somehow bun is pretty much identical to rust in this situation and finally node is like this I'd love to see some profiling are you actually using the CPU summary it's excited to see uh that bun performs so well and seems to be a runtime that can compete with rust or go for HTTP I'm also thrilled that there's a run time that does it all unlike languages such as rust and go which provide package managers bun provide one as well yes note on the other hand has various package managers it has various everythings for everythings and all the things have everything it's very it's a pain in the ass to get started and many different ways of achieving the same thing where each method is faster than the others yep although I'm not a big fan of writing JavaScript in general I look forward to building something with bun I would love to receive feedback this is great so I think this is really great hey go follow go follow pravan on Twitter okay it's right here but uh all right so here's my here's my hot steaming hot thing about this which is I don't find these type of tests interesting because it doesn't really test the environment well uh the the the Json one kind of did but here's the deal is that there's a lot of these things that happen right there's a lot of ways that uh these companies have or companies these well I mean technically buns the company as well but uh there's a lot of way these these languages handle how do how does it do garbage collection and so when you write an endpoint you typically get some data you do like an await it goes off to a database it comes back you do maybe another await you go to some other thing maybe you wait for a couple different awaits and these things can take a little bit of time right and then you get a response and then you get your response back and then you return it all out and so what ends up happening is you have these objects that end up living longer and crossing the boundary of a collection and being promoted from Nursery into something larger and so therefore you get a much more kind of complex operating or runtime experience which means that your your request per second or whatever can go way down because you start to get all of the different uh all the different facets of the language actually running and so that's one of my worries whenever you see just a pure HTTP test is you're not really testing much other than what is the runtime doing and I know that's the purpose of this article but I like to see a little bit more like what does it actually offer does JS core actually offer a compelling difference between V8 or is it purely just how well did they write the system interface for with Zig right because let's just face it like you said it's the least interesting part of the whole thing it's great for yourself let's see it's great if your server is fast but it's not great if it's too easy to accidentally generate gigabytes of GC collected memory for no reason exactly exactly like this is a real thing this is why just last night when we were talking about it we were reading something or I forgot what we were doing last night but it's all about letting node die it's okay that no dies it's hard right that's like the whole argument for why serverless is becoming popular with node is that one of the arguments is that it's hard to make a node server live for a long time which really is kind of a crazy statement to if you really think about it could you really say that that's like a great thing like that's a language or an environment you should be using is one in which you can't get to live for a long time node is not stable the experience is not stable and it's not that node is not stable is that the language itself doesn't give you the constructs to avoid problems from happening you probably just missed a try catch you probably just actually did something you're not allowed to do you just didn't realize you couldn't do that you actually held on to memory and a closure that points to a map and then it ended up exploding it's really easy to do dumb stuff in JavaScript and so I totally get that and that's what always you know that's what worries me more about the language than anything else I would love to see I mean because I'm seeing right now a bunch of O camel being executed from bun so to me that actually seems like a really compelling argument for bun is that bun has really great ffi and so maybe just maybe you know what I mean maybe just maybe and so I I like this idea you know what I mean you got to soak the testing you got to do a deep soaking you know what I mean all right anyways I think ffi is a great selling point I agree I'm on that team I think the ffi is a great selling point and I'd love to do more about that oh wow I really want to make middleware and with o camel I can't wait to use a language level abstractions exactly and so there's something really Dina Wilson Rip but really like to me this is really what makes it more compelling is that you have bun to handle all the shitty Parts about programming right JavaScript is actually a really great language for handling shitty parts of programming we all agree that sometimes you don't want to handle every single type you don't want to have to write all the structs you don't want to have to have everything instead you can kind of like reduce it you know you don't really want to do any of that so you kind of handle the things that are shitty in JavaScript because it's super easy and then you have your your better language do all the complex parts and so it's like I could see why that is kind of exciting JS is kind of great at working it's it's kind of great at doing things but it shoots you the foot right it's it's a Faustian bargain working with JavaScript is a continuous fallacy and bargain you you've missed error handling you've missed some some typing you did not expect because the thing is is that you have to Define all the typing that could happen right whereas it's like the inverse in a static language a static language you define what types are allowed to be and that's that the type system cannot pass if it doesn't work whereas with typescript nothing nothing it's if you just get handed a string instead of a number and you didn't plan for that it doesn't matter your tests your code you've written it just works and that's what's gonna happen right and you have to you're you're duped you're doomed in a weird sense that things are going to happen in a weird way you didn't expect it to happen because you have to know every possible type or you have to do the typeless programming where you enforce your types Zod would be an example and if you use Zod your server is going to Screech to a halt on how fast it could go Kyle Simpson would disagree I don't care what Kyle Simpson has to say you have to know your types either way you don't know what your third-party services are going to respond with they can respond with things you don't expect because that's what happens you have to expect everybody to play ball right and get let's just face it not everyone's great at playing ball anyways the name is I really like this article it was pretty interesting and I'm very excited about more of it by the way for those that don't know I've been I've been I've teased it a few times we're going I'm going through some bun versus node.js performance tighter is better but bun super tight 3 million 3.2 million on what I want to see and another one a 2.2 million on what I want to see exact code exact everything the difference is is that the one I want to see only has 1.3 million and 1.4 million way better performance on bun on identical code way tighter distribution lots of things I'm excited about can't wait to see it that's very bright sorry for the flashbang the name is the primogen

Channel: ThePrimeTime

Views: 163,559

Keywords: programming, computer, software, software engineer, software engineering, program, development, developing, developer, developers, web design, web developer, web development, programmer humor, humor, memes, software memes, engineer, engineering, Regex, regexs, regexes, netflix, vscode, vscode engineer, vscode plugins, Lenovo, customer service

Id: yPcWzSlsteA

Length: 18min 7sec (1087 seconds)

Published: Sat Sep 16 2023