Rust has electrolytes, its what plants crave

It's hilarious because Python devs would be more than happy to get the numbers node got

Yeah but did he test url parsing????

we need original primeagen to do rust vs go vs bun vs node!!!

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.

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

Go Rust yourself you Node Bun! ❤

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 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

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 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#....

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.

Go is the language. Fast enough, simple enough. Everything else is a madhouse these days.

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.

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.

I’ve also noticed a drop in performance when serving JSON from Bun

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 :/

it would be so cool if u made this benchmark (maybe adding some more technologies) and walk us through it :)

That was the coldest hot take I've ever seen

multi dollar companies running node wondering what this guy is talking about.

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.

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

I did a similar test locally using drill to measure the performance and bun did very well.

that scream at 5:55 killed me

Can I just start using bun for my dream project ? or it might cause issues ?

I still haven't watched the video, but I am getting more excited that at family dinner if there will be ribs.

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.

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)

url parsing drama was nice

yea but can bun rust and go parse urls like node?

Nice idea, i'm I was thinking about it ::)

Node is like the internet explorar meme.

originally for his takes. stayed to figure out what his name is this week

What API library was used in RUST for this test?

blazing fast

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.

Where is the video on DX?

Interesting but does this matters for 90% of the apps out there?

"the pre-why". Okay hear me out but i think now that every dev-post is supposed to have it!

we need original primeagen to do rust vs go vs bun vs node!!!(2)

django supremacy

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

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?

Señior primogen how about a course on how to benchmark effectively?

well now i dont have to setup tsc just to run typescript

Damn, I love Deno 🚀

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.

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

Rust not in release mode?

What’s FFI? Same FFI as other FFIs?

Imagine having a web server more complicated than `nc -lc jq` Tom's a genius btw

It depends. That is the only acceptable response from a real engineer.

We need to add PHP to the mix of "cool kids"

I'd like to see WASM in such comparisons. It could probably also be an alternative to Node/Bun.

Why does Deno not make it to the conversation?

isnt Bun using JSCore and Node is using JSv8 ? thats why Bun is faster?

Would like to see Deno here

We dont know how node is configured and what config is behind multithread. I bet its configured bad and not all cores are utilized.

But can you write an OS with Bun

I still do not understand why the js ecosystem accepted Typescript but refused Dart. Weird.

11 out of 10 of these types of tests always result with a :facepalm:

This is an unfair comparison node rust and go are tested in runtimes and the other is a buntime

Can you use rust and go to build desktop apps?

14:20 yeah because JS doesn't belong to backend, that's it.

Who is Kyle Simpson? I mean, the NAME.. starts with simp

12:25 . It's http perf PLUS all awaits. So http perf still matters...

c# would have destroyed all of them if it was included

2:13 lmao

Can’t 3rd party services return unexpected types in any language?

No love for DENO?

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 ?

I want to run tsserver with Bun, I need a fork

So runtimes is the new JavaScript trend

Have you performed the URL parser benchmark? 😂

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

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

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.

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.

haha! hot and fresh primogen.

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?

I feel like a web server written in C++ can double Rust's speed here.

JavaScript on the backend is a mistake. Go with go or rust, preferably go since you can write code faster

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.

PHP and jQuery

Bun is the cutest. Bun wins.

Waaarrrrrrr

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. .

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 another JS hype that will be dead after a year or less like DENO.

Node Tokio!

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

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

100c is too ridiculous

Next time look at req/sec.

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

I refuse to accept that people are still talking about bun. Node will forever be the only thing that touches my packages.