Go vs Rust vs Bun vs Node | Prime Reacts
Vložit
- čas přidán 15. 09. 2023
- Recorded live on twitch, GET IN
/ theprimeagen
The Author and Article
Article: www.priver.dev/blog/benchmark...
Author: / emil_priver
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/deeznuts - Věda a technologie
Rust has electrolytes, its what plants crave
The rust fungus in return, craves for the plants
Hahaha, idiocracy
Do you get paid every time you say that? 😂
LOL because Prime uses the "Welcome to Costco, I love you" clip :-)
Hello welcome to Rust. We love you.
It's hilarious because Python devs would be more than happy to get the numbers node got
python devs have fastapi which outperformes node. Dunno what numbers for their Django, I assume that they will be really happy with node's numbers
@@whu.9163it doesn’t outperform node. They claim it’s on par with node. And even that isn’t true. Go and test it yourself. I did and others have done it as well. It’s on average 5x slower than express on node.
@@whu.9163 Python dev here. FastAPI and Django aren't HTTP servers (tho they have "test" ones), they're web frameworks. What you want to compare are uWSGI, gunicorn, etc.
@@whu.9163 Not true. Fastapi has similar performance to express or maybe koa, which are just average in the node world. Fastapi is heavily outperformed by Fastify.
could u tell me why bro ? ? ?
we need original primeagen to do rust vs go vs bun vs node!!!
Working on something now
@@ThePrimeTimeagenyou gotta add Deno to the mix!!!!
@@ThePrimeTimeagenplease include zig as well
@@ThePrimeTimeagenPlease don't leave Ocaml out
and obviously C# since its blazinglyfaster than everything else listed here.
Yeah but did he test url parsing????
I conducted tests on two servers, each equipped with 1Gbit bandwidth and running Ubuntu 22.04. My tests focused primarily on Rust and Go, though I also looked at Bun and Node in single-threaded modes. I adjusted the ulimit -n setting and the responses were approximately 1kb in JSON format, simulating a typical production response.
For the production server(16 cores), I used a local test with the following settings: wrk -t10 -c4000 -d10s. The results were:
Rust (using warp) achieved 950K requests/s at 2200% CPU utilization.
Rust (using axum) achieved 850K requests/s at 2200% CPU utilization.
Go reached 400k requests/s with a CPU utilization of 2400%.
Bun, in single-threaded mode, achieved 120k requests/s at 100% CPU utilization.
When running 10 Bun instances on different ports, the combined score was 950k requests/s at 1000% CPU utilization.(runned 10 wrk -t1 -c400 -d10s for different port)
Node, in single-threaded mode, registered 34k requests/s at 100% CPU utilization, but with 10 threads, it hit 300k requests/s at 1000% CPU utilization.
For the second test, wrk was executed on the other server, the results were:
Go managed 128k requests/s with 900% CPU utilization.
Rust (warp) matched this with 128k requests/s but at a lower 420% CPU usage.
Rust (axum) also achieved 128k requests/s, consuming 500% of the CPU.
Bun maintained its performance at 120k requests/s in single-threaded mode with 100% CPU utilization.
Node in single-threaded mode had a slightly decreased performance of 30k requests/s at 100% CPU utilization.
In conclusion, bandwidth limitations were evident in the second test. Impressively, Bun showcased exceptional requests handling capabilities.
Also, the preceding text was structured with the help of ChatGPT.(and this one)
I'm working on a second test using some database inserts/reads
Also tested with wrk for 2 mins for all the above, same performance
Thanks for these details. Much appreciated
this is awesome work, than you!
I think the next step is to JSON stringify a result that was awaited from a DB. Same DB for all tests, but it’d test more of the concurrency system.
Yeah. But it will benchmark the library that connects to DB too. For this benchmark to work will be a looong one, maybe choose at the least 3libs from each one to test and need to have same configuration like connection pool size and so on. Ive already tried to do some benchmarks like these and its frustrating how I can’t make rust beat node. Hahahah. I’m 100% sure its my way of writting rust. I don’t have magical powers YET.
I don't think you would have to actually connect to a real database; just use an async timeout for a slightly random duration.
Latency is important as well. GC does not run on every request. So, there would be some requests with very long responses because they waited for GC.
Go Rust yourself you Node Bun! ❤
least brain rotting comment
hey thats offensive
No it is not, ... 😁
Two developers in the same company:
One is writing a web backend that connect to database using Node or Bun
the second is writing the same app using Rust
The final result:
no real benifits from using Rust.
The first developer was sleeping in his home while the second developer was still writing his fast code
By the way my friend you can NOT live without JavaScript (without JavaScript there will be no internet or web you know now at all)@@chris-zlrr
nah, thats the point haha.
Go uses multiple threads to schedule goroutines at runtime, bun runs in a single thread, and to make these tests comparable we need to run bun service per cpu core and use http balancer, the same for node
Node spawns a group of worker threads to do the IO stuff so it is not comparable to say that it only uses one. Sure, the event loop is in one, but there are way more things than a simple event loop.
@@Qizot what i mean, it still processes http requests concurrently but not in parallel (num of cores), but golang does. To make it close to a go parallelism you need a forked node/bun service per cpu core
Good point@@shadowfaxenator
These synthetic benchmarks are pointless when there are real world nuances like this.
Yo. The Article didnt build bun properly (i think). By default bun does --target=browser and not --target=bun, which would be the intended thing for a serverside usecase. But the results still make sense in general.
I'll let my boss know that this is why my code is slow... obviously if I just rewrite it in a good language it'll be better.
I do not understand why Gary says "I feel bad for node" - Node and Bun were doing pretty good and he is comparing them to a system-level languages. Let's see what you will get from languages in the same category like php, ruby, pyhton or even Java and c#....
facts.... or where's the comparison of doing SSR (e.g. builtin templating), it's not even comparable 🫣
Firstly, what does it matter that one is a "system-level language", it doesn't change the outcome.
Secondly, Java and C# are really in another performance class from languages like Python and Ruby in terms of performance. They're much more similar in performance to something like Go.
Regardless, there's more comprehensive benchmarks that compare a lot more languages and frameworks.
You'd feel worse for node. It can't even compete in it's own category.
Java and C# will kick Node and Bun's ass all day everyday.
@@ConernicusRexhow so? Python, Ruby and PHP are much slower
Go is the language. Fast enough, simple enough. Everything else is a madhouse these days.
😂😂
That really looks like an upload / download speed limitation. They were all coming in right around 3MB/s transfer when running in Linode. It's pretty unbelievable the bottleneck is the server or Linode's network. If that is a limitation from Linode, then it'd be better to test against AWS or GCP.
I may write an article like this comparing package install times between 'bun add' and 'npm install'. Those are some sexy numbers.
Until Bun appeared, I straight up refused to build any backend in Javascript after learning about Go and Rust. Tbh, I'm still not a huge fan of JS because of the problems with the language itself, but I feel more comfortable now going to sit at the soy dev table with the React Andys where they keep all the money.
Javascript still don't have good orm as java/C# does and when it comes to typescript on backend it will make your life living nightmare instead of helping. Fighting types just to have code completion is wrong.
@@RaZziaN1 Prisma? its pretty sick
@@RaZziaN1 I mean, Entity Framework 6+ and EF Core now is a really high bar for an ORM. Linq and all that.. JS/TypeScript may never have an ORM that nice.
But I find MikroORM pretty good. The main dev on that has been doing great work.
I’ve also noticed a drop in performance when serving JSON from Bun
it would be so cool if u made this benchmark (maybe adding some more technologies) and walk us through it :)
I've had to deal with API's that have returned things so far out of spec that I just had to defensively model specifically what is aloud per endpoint,
it might be a 404 error, it might be a 200 error returning "404 OK" as text, json, it might return a 0 or 1 as text, again with that 200 status
it might be a json stacktrace presented (even though it really should not be sent to me),
it might be a valid output with 1-2 tags missing
all depending on where in there code did it hit an error, and I'm expected to just deal with it :/
That was the coldest hot take I've ever seen
yea but can bun rust and go parse urls like node?
I did a similar test locally using drill to measure the performance and bun did very well.
I would like so much that prime understand Portuguese to show him "the fight" that we have in our Brazilian community. Basically build a http server in any language that could support concurrent connections to the database. You would love it.
Can I just start using bun for my dream project ? or it might cause issues ?
You make it sound like all C++ implementations should be equally fast. There's also the rigmarole involved in the FFI when calling a C/C++/Rust/Zig implementation from a js/python/etc interface. There's sufficient places for variance.
I still haven't watched the video, but I am getting more excited that at family dinner if there will be ribs.
url parsing drama was nice
the second (Linode) set of tests is not really useful because most of the time is spent waiting for the network (his local PC Linode)
that scream at 5:55 killed me
Nice idea, i'm I was thinking about it
::)
I still do not understand why the js ecosystem accepted Typescript but refused Dart. Weird.
Maybe because TypeScript is just a JS extension so the same tooling, knowledge, code etc can still be used. Same with CoffeeScript and other attempts before TS.
JS people do not use neurons
@@SaHaRaSquad isn't the fact that TS is a JS extension the problem itself?
TS is just JS with Types
multi dollar companies running node wondering what this guy is talking about.
originally for his takes. stayed to figure out what his name is this week
Node is like the internet explorar meme.
What API library was used in RUST for this test?
we need original primeagen to do rust vs go vs bun vs node!!!(2)
Interesting but does this matters for 90% of the apps out there?
Using zig for a backend instead. Why ? Resources. 4mb for the container (including all assets), and 20mb memory footprint under load … that’s app + threaded http server.
Requests all served under 1ms
Throughput not a requirement for my use case (I don’t need 128k req per sec), but I do care about server costs, because I pay for them
"the pre-why". Okay hear me out but i think now that every dev-post is supposed to have it!
Why C and C++ are not being brought in your discussions? Even in the market in general. I have an electrical engineering background and I've been introduced to the programming world in those "outdated" languages, recently I've started a role as programmer and, as an attempt to update myself, I went online to see the technologies in use in the recent years, but I'm not seeing barely any mentions to C or c++ in the discussions. What's has happened to those languages? Why are they not as popular as golang, Javascript, rust or python? Are they more inefficient than the newer languages?
It's just less to convenient to code backends in those languages.
Forget C and C++, why are C# and Java not mentioned, given that they're normally used for these exact use cases?
I think C++ can be viable but it's very DIY and lacks polish. I'm looking forward to official functional programming support being fleshed out (not until C++23/26 at least).
Mainstream stacks railroad you into conforming to their design choices, but it's part of their effort to ease the DIY burden. Going off public job postings I've seen near me, I'd also guess there's A LOT more legacy Java, Python, C#, and JavaScript backend code out there in comparison to C++.
People also tend to use what they know or what their employer is using.
If you feel C or C++ may be the best tools for the problems you're solving, go for it. I think there's a lot more to be learned in trying things out than blindly following the crowd (regardless of whether your hypothesis turns out to be right or not).
well now i dont have to setup tsc just to run typescript
Señior primogen how about a course on how to benchmark effectively?
blazing fast
It depends. That is the only acceptable response from a real engineer.
Where is the video on DX?
Go is the ultimate balance. Love it.
I like rust but in my opinion writing good concurrent code is pretty hard. I build a implementation of Conway's game of life where in go it was easy to do. I used two threads: one where the game would update (iter the game following Conway's rules) and in the other thread I rendered the game with Raylib. In go it was as easy as go func() {game.update()} in rust, it was a whole different story. I had to use an arc mutex to be able to move the game struct around. It also worked poorly, getting less FPS than Go! (I get it isn't that fair of an example given I'm using a external library, Raylib, but they are pretty much 1:1 bindings of the C version). I love Rust's safety, Rust's syntax, I love ranges, I love enums, I love traits, but I hate concurrency. I know it's probably my fault for using an arc mutex to move a struct around but I couldn't find a better way and in Go it was just as simple as using it.
I don't think the Bun is the ultimate 1-fit-4-all people hyped it to be, but it also isn't the scam all the salty contrarians make it to be.
I'd like to see WASM in such comparisons. It could probably also be an alternative to Node/Bun.
wasm is for browsers.. you can just run rust natively as a server if you wanna lol
See wasmtime, wazero, wasmedge, etc, for server side wasm. Arguably wasm may be more impactful long run on the server side.
@@aryajpegasusWASM runs ANYWHERE it is just bytecode.
@@NathanHedglin ye but the point was so u can leverage system level langs performance on browsers right? even if it can why would you run it server side
Imagine having a web server more complicated than `nc -lc jq`
Tom's a genius btw
On the cloud test, the results were about the same. Which makes me suspecious that a middle component is regulating and normalizing the results which makes the test dirty. Since all tested languages here could easly exceed the numbers of the cloud test benchmark, when running on a clean local machine
This could be a network level or other type of component that limits bandwith and/or performance
It only proves that on the specific cloud service used for the test, there would be no difference for which langauge you pick, in terms of bandwith. Since you are not given the full potential anyway
*Network hops exist*
@@Zzznmop Not hops. Limitation. Probably to regulate their resources
Damn, I love Deno 🚀
We need to add PHP to the mix of "cool kids"
Tbh Axum is rather a feature rich and convenient for development framework than the fastest. The tester should use something better, or use gin in go and nestjs in node and bun, to make things fair
for golang they should use chi and not using a bigger framework
NestJS is slow as hell.
To make it fair run Stric in Bun, Hono in Node, Gin in go and Actix in Rust.
Those should be the fastest in each runtime/language
@@philheathslegalteam actually actix was the fastest back in 2020, now it's rather something like tiny-http
ye big agree. at least in Rust and Go, the bottlenecks are going to be how the underlying framework was implemented. Axum for example promotes a lot of Arc and cloning of state, which is probably why a few of the Bun frameworks (Elysia namely) are nearly grazing it in synthetic benchmarks.
@@TheWrapperup but with all of it we shouldn't forget that it's just hello world projects. In reality rust will beat bun up in times
We dont know how node is configured and what config is behind multithread. I bet its configured bad and not all cores are utilized.
Would like to see Deno here
Why does Deno not make it to the conversation?
Rust not in release mode?
What’s FFI? Same FFI as other FFIs?
11 out of 10 of these types of tests always result with a :facepalm:
15:35 about js
But can you write an OS with Bun
2:13 lmao
Who is Kyle Simpson? I mean, the NAME.. starts with simp
isnt Bun using JSCore and Node is using JSv8 ?
thats why Bun is faster?
misinformation
@@theairaccumulator7144 indeed, i love conspiracies
14:20 yeah because JS doesn't belong to backend, that's it.
I want to run tsserver with Bun, I need a fork
c# would have destroyed all of them if it was included
Have you performed the URL parser benchmark? 😂
Can you use rust and go to build desktop apps?
rust - tauri
go - wails
@@salman0ansari wails is so good tho. been using it a bit recently. do enjoy.
rust tauri / dioxus
@@salman0ansari wails is very nice
Yes, there's a lot of GUI kits and bindings for both
So runtimes is the new JavaScript trend
This is an unfair comparison node rust and go are tested in runtimes and the other is a buntime
django supremacy
There is a big outlier in the rust data in the max requests per second being 138k while all the other samples have values that are significantly lower.
The average req/s and stds are comparable for all the samples while this datapoint is out by about 5x and unexplained in the article.
Your assuming there *_is_* anything to explain. If one language performing significantly differently is itself evidence of a testing issue then I want every test ever to rebenchmark python against C.
12:25 . It's http perf PLUS all awaits. So http perf still matters...
web dev. yeah so today we are comparing rust and go and bun and node to see who is best
Meanwhile in embedded systems: never heard of rust, did you mean ROS ?
"Welcome to The Embedded Rust Book: An introductory book about using the Rust Programming Language on "Bare Metal" embedded systems, such as Microcontrollers."
Maybe it would be nicer to see the assembly produced across these 4 runtimes, especially if they are all doing the same thing and its simple enough
haha! hot and fresh primogen.
Can’t 3rd party services return unexpected types in any language?
I'm a little worried about the connection?
Well you should be worried a lot. No one should do a comparative benchmark over a network. LOL.
deno cries in a corner. They are not even considering me for competition.
I feel like a web server written in C++ can double Rust's speed here.
Rust sucks. I refuse to elaborate.
@@VivekYadav-ds8ozChad move.
Doubtful
Elaborate
13:25 about nodejs
stdlib vs tokio XD why not fiber or at least echo
standard encoding/json vs serde/json XD, why not goccy/go-json
everyone know the latter is superior because of buffer reuse
JavaScript on the backend is a mistake. Go with go or rust, preferably go since you can write code faster
"JavaScript on the backend is a mistake"!! My friend, JavaScript was present long before Go and it was proofed that it was the most good one compared to many other languages (especialy php)... May be in the future there might be some language that might be faster and has more performance than Go then I do not think that you might say "Go on the backend is a mistake"
We should NOT be programming language racists 🙂
@@HassanAllaham JavaScript is a glue language on the frontend to extend the dom and it’s actions via various web apis. One of it core purposes is to be backwards compatible as to keep in line with not breaking the web. This means it keeps all its core issue it’s had since it’s inception. It cannot be fundamentally fixed as it will break the web. It’s fine sprinkling JavaScript on the front end for extra interactivity but you probably wouldn’t write css as the backend framework just because you can now use functions and it has variables.
my friend,
No one can say JavaScript is a perfect language but it is unfair to say that it was a mistake in the backend .. that's what was my comment about ..@@PwrXenon
@@HassanAllaham no language is perfect ofcourse I agree with you. But a frontend glue language on the backend is a mistake
Any language is just a tool which might be used here or there. If using JavaScript (Node js) on backend a mistake then why there are thousands of successful projects around the web which made, and still, using JavaScript in backend (Node js) !! (Will you please write this in Google "companies using node js backend")
There was no Go and no Rust when those projects was made @@PwrXenon
Bun would be better if unlike the others didn’t limit its entire community space to proprietary Discord.
We are almost never CPU limited at the application level, and if we are, we just scale to more nodes. Which is why Rust and Go are not really that important to 90% of scenarios. And for that 10%, I would probably use C or C++ anyway and make the library accessible to Node. Less hassle.
Node Tokio!
PHP and jQuery
Waaarrrrrrr
a few years ago, the dream was for wasm to dominate: you include what packages you need in whatever language youre writing in, and you offset what you dont/wouldnt want to write with the wasm file/package thats already been written and compiled into wasm from c++/whatever. it was hyped, at least to me, to be the glue between languages. idk anything about bun, but im assuming it doesnt utilize this. just sad to see that the future isnt moving in a direciton of wasm unifying everything by being an intermediary glue that finds the most efficient path
Bun is server side js runtime, wasm is a way to run stuff client/server side
@@moar-chan1060 you just said that wasm is a way to run server side and bun uses server side code... doesnt detract from my statement
@@dmonitize9011WASM is for clients. Of course you can use it for server applications too, but it doesn't have as many advantages there.
Also, WASM is still relatively new. It's not a dead/dying dream, it's a dream that hasn't had time to take a foothold yet.
Wasm is to run assembly in browser, nothing serverside. Tf?
Who sold WASM as "the glue between languages"? I never got that impression and if anyone said it I would have had serious doubts about it. WASM is no more the glue between languages than regular assembler and machine code is the glue between languages. Sure you can write programs in all kind of languages and run them on the same machine. Actually building a single program out of multiple languages is not so easy. Despite every language like Python, JS, Rust, C++ having the ability to use libraries that provide a C interface you can use use Python libraries from JS or C++ libraries from Rust. WASM is basically a kind of assembler for an abstract it does not magically solve such problems. Same as regular assembler does not solve it.
Bun is the cutest. Bun wins.
Buns value proposition being just speed will never work for it.
The venn diagram of people who really care about performance goals and people who are using Node looks like deez nuts.
At least with other languages theres some other positive tradeoff. Maybe Go isnt as fast as Rust but its simpler. Maybe Haskell isn't faster than Go but it has a strong rype system.
Maybe Node isnt faster than other options but... you get to write JavaScript on the server?...yay?
The speed and ease of the workflow actually matters if you are required to actively maintain a project, Bun makes that process a breeze. Their whole spiel about latency to serve and hot reloading is part of that, change a script and being able to see the results in real time.
Even if Node keeps V8, they should at least be able to symlink a default software stack that covers most use cases, this is how Audacity and Gimp has dealt with default tools for a long time, the only thing actually stopping Node from doing this is tradition.
Bun is now offering a good enough proposition to those who don't want to suffer from compiled language hell. Yes I have 2 decades of experience writing C and NO, I'm not crazy enough to use it for ALL tasks
"compiled language hell" 😂😂 have fun running into undefined js issues
13:00 primegen is really hurt by working on limited resources on a tv for netflix that is why is worried about all these memory soo much , we mere mortals need not worry for this
A huge indicator into how well your application will perform and how often it will crash is memory usage. This is not some high brow take
I refuse to accept that people are still talking about bun. Node will forever be the only thing that touches my packages.
Pssh. My packages don’t want none unless you got Bun, hon.
Edit: for posterity...
[hotline bling no.jpg]
mix@mack:~$ conda create -yn back nodejs
mix@mack:~$ conda activate back
[hotline bling yes.jpg]
(back) mix@mack:~$ npm install -g bun
(back) mix@mack:~$ touch baby.js
@@bjmcculloch don't call me when you get http
Bun is another JS hype that will be dead after a year or less like DENO.
These sorts of benchmarks are always very dumb as it's always done by a developer that knows one thing way better than the others and can make one thing in one language way faster than all the others. It's like asking a fish if it's faster to travel by sea by land or by air. Guess what the fish will pick. .
I get the results but I hate how he presents them why didn't he make some plots to read the results in an easier manner
100c is too ridiculous