I’d like to see the performance of an Golang Echo server in a comparison please. Templating html or doing a database query would be realistic tests IMO!
Hello, the second test feels sus! Why does the s3 upload take so much time? Is the Upload blocking? Can you replace it with an async wait and try again?
I think this is a perfect analogy for go vs rust. You can get nearly as far as any language with Go with (relatively) little knowledge. You can get even further with deep knowledge of Rust.
@@curio78 of course Java is slower than C or Rust.. Java is generally 7th to 12th fastest, depending on the benchmark (and the depth of languages tested) & is usually sitting behind Go. More code for a slower result.. I'm not seeing the draw card of Java. People are generally moving away from Java, not to it. Doesn't mean it doesn't serve a purpose, but speed & simplicity are not its' strong points.
It is amazing to me how well go keeps up even being garbage collected. Glad you did this video. I think it’s much more fair to what rust is capable of. That said I would argue that most teams would be better served by go especially if you don’t have +10k rps problems and an extremely well defined problem space for your application. That’s because it was easier for you (and most devs) to get a fair well optimized application with go first time around. I find in the real world most projects only get one serious pass at the time it’s initially created.
@@anonymousalexander6005 I don’t think that’s true. As someone who’s doing backend js begrudging at work if you are running in kubernetes golang start up time is a real advantage. No JIT needed either. Not to mention the memory usage. I can run a 3 go servers on the smallest ec2 instance no problem. Can’t say the same for JavaScript.
Depends on the kind of work you do. Complex logic is better served by a compiler able to do more compile time checks and a language which has a much higher expressive power. Few real world workloads are as simple as serving constants or uploading some stuff to multiple places.
@@cole.maxwell I was referring to the "just get it done, you will only have 10 users are max, just use a cheap VPS" use case, but yeah I agree with you
I found Axum to be really simple, if a bit immature, didnt feel like I was much slower that with other languages and frameworks. But maybe that just means I suck at all of them 😂😂
@@jonnyso1No Axum is pretty straightforward. It has a really good balance of exposing features (not hiding everything behind macros like rocket), and being simple enough. I think that (As long as you’re working with REST APIs and not holding state), Axum and Go are ~equal in difficulty here. If you need to get more complicated Go will likely be easier to use but rethinking your design might also help.
@@houstonbova3136I gave up on frameworks because I didn’t like any of them. I just use hyper directly (what all these frameworks for Rust use anyway), and get absolutely *silly* performance out of it. With just a few simple macros I wrote myself it does everything it needs to do, and I have absolute control over everything.
@@jonnyso1using axum may as well be easy and straightforward, but it does not mean that all other parts of your Rust program are going to be the same.
Thanks for doing Rust vs (non-Fiber) Go. Would be interesting to see how PHP ecosystem compares to this. Not only classic frameworks (for example Symfony vs Laravel), but also newer solutions like ReactPHP and FrankenPHP.
Many thanks for revisiting this test. These new results are much more in line with my expectations. The updated Rust code is also extremely easy to read.
Thanks for all the work you've done to produce these tests. I would like to add a small modification to the Rust code, you are using Serde for serialization and deserialization, use sonic-rs instead, it will give you 20% more performance.
Amazing video! I’m just starting to learn cloud as well so I’m glad I found your channel. An extra comparison that I think could be interesting would be adding in a node.js or even something like a python server (or both) as a comparison to show the concrete performance benefits we are achieving with go and rust. I imagine it’ll be a sort of Olympic athlete vs regular civilian comparison but could add good perspective to how well both of these are already doing despite already each having relatively similar limitations.
Hey! awesome one! I took a look into the rust code and I saw that each time a new prepared statement is being created, while it could reuse statements. I'll take a look into S3 as well sometime and try to give it PR.
Hi Anton! I’d love to see a comprehensive course on observability and monitoring from you, covering everything from basics to advanced topics. It would be amazing if you could include: what to monitor (applications and clusters), how to monitor (tools and techniques), key metrics for applications and clusters, insights from 12+ years of experience, and an overview of metrics, logs, traces, OpenTelemetry, Jaeger, and how to create custom dashboards in Grafana. Also, a section on implementing monitoring for different programming languages would be incredibly valuable. Your approach and expertise in monitoring are unmatched on TH-cam-I'm sure your course would offer insights that no one else provides. Thanks!
I believe the kubernetes CPU throttling is giving this benchmark an unfair comparison of the latency. Go is not aware of the cpu limit that you gave it. in general you should avoid cpu limits since how the kernel applies this limit will cause high tail latency, which can also explain why the throughput goes from 12K/s to 7K/s when throttling starts. Would like to see the same test but with rust and go on their own nodes which they can use fully (so without any cpu limits). And would also be interesting to see them running on one node where they both get the same amount of cpu request but again no limit to avoid throttling, the requests will still make sure that both can equally use the cpu
@@erkintek You can set the GOMAXPROCS and GOMEMLIMIT env vars according to the pod cpu and memory limits respectively (rounded down to the nearest integer in the case of GOMAXPROCS). I do this regularly with GOMEMLIMIT (sometimes also tweaking GOGC) but haven't yet tested GOMAXPROCS. But the theory seems sound: Goroutines will be scheduled over only that many OS threads, so there should be less thread contention which improves tail latency. Uber has a package called automaxprocs to handle this automatically, and they measure significantly better p99.9 latency. Anton, this could be an interesting thing to test.
I would LOVE to see the optimizations benchmarked next to each other as another video. Eg. Changing to cope on write improved speed by 20%. That way the audience would learn some optimization techniques vs just seeing what frameworks / languages are the most efficient.
Thanks! I keep getting PRs to improve Rust, Go, and other frameworks. I'll consider creating another video to go over each optimization technique I've received so far.
The big question - "Is the extra cost of developing a large app in rust worth the (minor) additional server costs if you choose go?" If you build a project in Rust and it is successful, finding good rust devs to scale it is much more difficult (and expensive) vs go devs
It's just a matter of time before many properly skilled rust programmers will become available. It's too good a language to pass up. There's evidence (a study performed internally by Google as it has started rewriting C++ stuff in rust) that once you've spent a couple of months in rust you start writing code much faster that with other languages - no surprise, I'd say, given rust's expressive power. Go's expressive power, OTOH, is awful, compared to most modern languages - which makes it a lot easier to learn, but once you're past that initial learning there's not much that you can improve further.
In the real world, to solve business problems, 9 out 10 times you should pick Go. Rust would be the right pick for niche cases where your specific use case benefits from the performance. I keep reading how popular Rust is but the reality is that the job market for it is tiny, you would certainly have issues hiring to maintain that codebase.
@@hyper_channel Provided you already know both languages, why would you _ever_ pick Go over Rust? Rust is faster, uses less memory and allows you to write the same thing in fewer lines of code. Also, the Rust compiler detects many more problems at compile time than the Go compiler. What would be even a single advantage of Go? That a half-retarded code monkey who you wouldn't trust writing a hello world on his own could possibly understand the code? That's not relevant, in a professional setting. The only situation in which Go would be a better choice is when your team already knows Go but doesn't know Rust, and the task at hand is a small one-off. If it's a larger project that's performance-critical, learning Rust already pays off. If it's a larger project without stringent performance requirements, Java or C# will do just fine, and still allow you to write less code faster. Go filled a niche at a time when there was nothing to fill it: a relatively simple language adequate for writing robust and not overly complex systems software. Rust fully covers that, and much more, and does so better than Go. Recently, Google started to rewrite its massive C++ codebase in Rust. They're the ones who created Go in the first place. How come _they_ didn't pick Go over Rust? Oh, and Google also translated some code from Go into Rust - leading to lower memory usage and lower bug count. Google hires tens of thousands of programmers, in case you missed it. Also, there's some pushback, but Linus is supporting Rust being used in the Linux kernel. Amazon and Microsoft are also using Rust. You won't need to search much for a job if you know Rust well. The only reason there are more jobs for Go is that Go is an older language.
The use of Rust can be a example of premature optimization. With Go your can iterate faster with good performance, only if your project scale a lot, at the point in which that minor difference is translated in hundreds of thousands of dollars, maybe makes sense search for something more low level, but in that case makes more sense use something like Zig instead of Rust, because Zig has better performance (more grained use of resources) than Rust and is more simpler (like Go) to implement.
@@SilasDuarte-e9k There's no optimization if your team already knows Rust. Unless you write the code in certain ways which cause Rust to generate inefficient binary code, Rust and Zig provide comparable performance. Zig or Go may make sense if your team doesn't know Rust already and if your project asks for performance but is expected to remain small and simple long term. For larger and more complex projects, even if your team has to learn Rust first it is still worth it.
Thank bro for doing that second test scenario, because that is a more frequent use case where you are talking to other services doing file and network stuff.
I work with some people that think Node is good enough. I’d love to see the same comparison, with Node and/or Python mixed in. I know they’re not in the same league, I’m curious just how far out performed Node would be in this test. Very cool stuff, thanks for doing this!
This is great esp the ecosystem of erlang and telecommunication. I prefer Go, coz it has better ROI on what I do(APIs). My ROI is balance btw devtime and speed.
axum is great and more intuitive than the other rust frameworks but i wish there was a website. the docs are great but it would attract more developers if there was a website. especially for new developers because the rust docs are very difficult to read unless you are familiar with reading them.
Thanks for your awesome work!, It would be great if you could add a final time section at the end where you talk about conclusions drawn or summary of the finding.
Nowadays there's a lot of discourse (in some places) about moving from JS to PHP, especially Laravel. A performance benchmark between those two would be great!!
When we are talking about go, rust.. it means that we are trying to match them with C... Js and php are 10000 times slower than these languages in congestion.. use case is different for js and php now a days.. not sure if it is really worth to compare js and php.
Very interesting! One benchmark i would be really interested on would be replicating floats vectors over udp; for moving 3d objects; ( Actually it could be any kind of vectorized data going through udp ) it should be pretty straightforward but could also make use of several optimisation like cpu intrinsics; and it would also be interesting to compare it over different cpu architecture and see if arm is really that big of a deal in terms of costs; Let’s say that one client have one vector of data that can change ( no need to add dirty bit / compression algorithms ) something like 60 time a second and it must be replicated to other clients; how many clients can it handle and what’s the error rate Would also be nice to have the comparison between go / rust / ebpf? / other?
Hey, Anton. Love your content. I'm quite new to programming - how are you running these tests? Are you using a prometheus library inside the code which exposes metrics so it can bee scrapped? Would be awesome if you did a beginner introduction so we could learn how to do some of these tests ourselfs
Is surrealdb really as fast as they claim? I know it’s fast with little data, but I’d love to see some benchmarks vs other databases with lots of rows.
It looks like the go postgres library automatically caches the prepared sql statements, but the rust tokio_postgres connection don't (you can opt-in to this with prepare_cache instead of prepare though).
I wonder how this compares to real life scenarios. Like what's the scale of the app that constantly has 14k requests per second. How many users is that typically?
Most large-ish apps I see have much more CPU usage, so you should add that in somehow. Maybe rendering a template dynamically. Also, p90 is a better metric here than p99. Go will benefit from p99 due to GC not running in the 1%
I’d also like to see how much of difference you are able to see when using the Minio client instead of the official AWS client. In my experience (with Rust and C#) the official AWS SDK is complete and utter garbage. The Minio libraries work far better, even when using real AWS S3!
It's interesting if you benchmark not only by language programming, but also by Technology such as implementing grpc or graphql based on go vs rust vs c# vs python
I think you need to show the network metrics. Are you saturating network. Since rust isn't using all of the cpu or memory, i think you are hitting limits in the network. Also, for the last test, you are getting latency spikes in both rust and go at similar times again, implying network limits.
It seems that developing real-world web applications in Rust, with databases and storage in S3, is similar to developing them in Golang. I think even Python might offer similar "performance" because the database is often the bottleneck.
@@AntonPutra I don't know how overwhelmed you are but what would be really cool is adding Elixir to the test mix. They (and many others) claim it's the best thing ever invented for high user load like WhatsApp is using it etc.
if you know javascript i would go the wasm route for learning with leptos or dixious. i did rustlings, went through the book, and then wasm. it was a lot easier that way.
Can you do the same tests but not setting a CPU limit in k8s (only request if you like it). We noticed that the k8s throttling is a Problem and using or restricting too much resources. We had 100% CPU spikes with a limit and without the services took only 1/3 of the production resources. Its only s problem if you run the service close to the limit of cou resources
Which json library did you use for serializing JSON. Most of the time when I saw the profile of benchmarks envolving JSON, the JSON marshal/unmarshal part always takes the most CPU. Could if you try a different library for it?
This is cool but see how close they are as soon as you get to a common real world scenario. 99% of the time you will be I/O bound. Apart from very niche cases there's no reason to go with Rust over Go to write APIs, hell even JavaScript is plenty fast 99% of the use cases.
But what if in the test where go started failing at 14k rps you re-ran it but gave the go pod 500mb or even 1gb. out of interest maybe performance would be close ? using more RAM at the cost of an easier language than rust could be worth it ?
Nice benchmark. I didnt know rust web lib is mature to handle more traffic than go. Would be great if axum is compared with go fiber. Go fiber is more popular now a days.
Likely there are more in flight connections, and so more RAM used. It might be nice to add a gauge metric to count the number of concurrent connections to show this, but you can infer it from the request latency. If the request latency is rising, then the total connection time is taking longer and by applying Littles law you can see that the average queue amount growing.
50 seems low for requests per second. I wonder if you're running into some inadvertent local throttling (something like a default max concurrent connections in the sdk, or perhaps something like a max open files constraint). Turn the tracing level up to debug and look at the aws-sdk messages when you're hitting capacity. Also maybe add gauges for upload bytes to get a feel for whether this is bandwidth constrained.
I see one of the challenges of Rust moving forward is to improve the ecosystem and language so that it is easier to get most of the performance wins an expert can currently get, with drastically less expertise. For example, Cow is not a day one of learning Rust concept, but it is also something that in many situations a smarter compiler should be able to inject for you given immutable data structures.
@@mrpocock Maybe - the delta we're talking based on the RPS change is ~40 nanoseconds and is less than a 1% difference in runtime. Choosing a data structure that requires an extra memory lookup seems like this is exactly the perf which this is hitting, and the sort of thing you'd really expect only to find when running something like this in a profiler to determine maximum efficiency. The fact that Cow was used here at all was a mistake that unintentionally caused a perf regression.
Is the 2nd test a show case to prove that the language doesn't really matter as much as the IO connections you handle (or maybe the libraries that manages this IOs)?
👋What should I test next???
👉 [Playlist] New Benchmarks: th-cam.com/play/PLiMWaCMwGJXmcDLvMQeORJ-j_jayKaLVn.html&si=p-UOaVM_6_SFx52H
I’d like to see the performance of an Golang Echo server in a comparison please.
Templating html or doing a database query would be realistic tests IMO!
c#/dotnet vs java/springboot，thank you
Axum vs acrix?
For go html/template vs Templ or encoding/json vs Jsoniter could also be interesting.
Hello, the second test feels sus! Why does the s3 upload take so much time? Is the Upload blocking? Can you replace it with an async wait and try again?
Glad you went back and did it again after feedback from the other video. Nice
🫡
I think this is a perfect analogy for go vs rust. You can get nearly as far as any language with Go with (relatively) little knowledge. You can get even further with deep knowledge of Rust.
true
Fair assessment!
@@curio78 😂
@@curio78 256MB ram maybe not enough for 1 java spring application to run
@@curio78 of course Java is slower than C or Rust.. Java is generally 7th to 12th fastest, depending on the benchmark (and the depth of languages tested) & is usually sitting behind Go.
More code for a slower result.. I'm not seeing the draw card of Java. People are generally moving away from Java, not to it.
Doesn't mean it doesn't serve a purpose, but speed & simplicity are not its' strong points.
Love watching your benchmark videos.
thanks!
It is amazing to me how well go keeps up even being garbage collected. Glad you did this video. I think it’s much more fair to what rust is capable of. That said I would argue that most teams would be better served by go especially if you don’t have +10k rps problems and an extremely well defined problem space for your application. That’s because it was easier for you (and most devs) to get a fair well optimized application with go first time around. I find in the real world most projects only get one serious pass at the time it’s initially created.
yeah, go is beginner friendly😂
Python, JavaScript, Java all still hold the top marks in those terms, even though I love Go.
@@anonymousalexander6005 I don’t think that’s true. As someone who’s doing backend js begrudging at work if you are running in kubernetes golang start up time is a real advantage. No JIT needed either. Not to mention the memory usage. I can run a 3 go servers on the smallest ec2 instance no problem. Can’t say the same for JavaScript.
Depends on the kind of work you do. Complex logic is better served by a compiler able to do more compile time checks and a language which has a much higher expressive power. Few real world workloads are as simple as serving constants or uploading some stuff to multiple places.
@@cole.maxwell I was referring to the "just get it done, you will only have 10 users are max, just use a cheap VPS" use case, but yeah I agree with you
It's nice how fast you can do something in Go while it still runs pretty fast
yesah, beginner friendly 😊
I found Axum to be really simple, if a bit immature, didnt feel like I was much slower that with other languages and frameworks. But maybe that just means I suck at all of them 😂😂
@@jonnyso1No Axum is pretty straightforward. It has a really good balance of exposing features (not hiding everything behind macros like rocket), and being simple enough.
I think that (As long as you’re working with REST APIs and not holding state), Axum and Go are ~equal in difficulty here.
If you need to get more complicated Go will likely be easier to use but rethinking your design might also help.
@@houstonbova3136I gave up on frameworks because I didn’t like any of them.
I just use hyper directly (what all these frameworks for Rust use anyway), and get absolutely *silly* performance out of it.
With just a few simple macros I wrote myself it does everything it needs to do, and I have absolute control over everything.
@@jonnyso1using axum may as well be easy and straightforward, but it does not mean that all other parts of your Rust program are going to be the same.
Woha, benchmarks fights ! nice videos ! I love your channel
thank you! :)
Thanks for doing Rust vs (non-Fiber) Go.
Would be interesting to see how PHP ecosystem compares to this. Not only classic frameworks (for example Symfony vs Laravel), but also newer solutions like ReactPHP and FrankenPHP.
Many thanks for revisiting this test. These new results are much more in line with my expectations. The updated Rust code is also extremely easy to read.
my pleasure, but fiber is still faster than rust 🙈 i was trying to find analog in rust to test and so far i got Ntex
Thanks for all the work you've done to produce these tests. I would like to add a small modification to the Rust code, you are using Serde for serialization and deserialization, use sonic-rs instead, it will give you 20% more performance.
Amazing video! I’m just starting to learn cloud as well so I’m glad I found your channel. An extra comparison that I think could be interesting would be adding in a node.js or even something like a python server (or both) as a comparison to show the concrete performance benefits we are achieving with go and rust. I imagine it’ll be a sort of Olympic athlete vs regular civilian comparison but could add good perspective to how well both of these are already doing despite already each having relatively similar limitations.
Hey! awesome one! I took a look into the rust code and I saw that each time a new prepared statement is being created, while it could reuse statements. I'll take a look into S3 as well sometime and try to give it PR.
Thanks! I appreciate it!
@@AntonPutra The go code doesn't call prepare - I wonder if that's the cause for the CPU difference?
Thank You SIR, ❤ I learned real world technology from a great teacher, prayers for you! JazakAllah ❤ 🙏 🤲 👍
Hi Anton! I’d love to see a comprehensive course on observability and monitoring from you, covering everything from basics to advanced topics. It would be amazing if you could include: what to monitor (applications and clusters), how to monitor (tools and techniques), key metrics for applications and clusters, insights from 12+ years of experience, and an overview of metrics, logs, traces, OpenTelemetry, Jaeger, and how to create custom dashboards in Grafana. Also, a section on implementing monitoring for different programming languages would be incredibly valuable.
Your approach and expertise in monitoring are unmatched on TH-cam-I'm sure your course would offer insights that no one else provides. Thanks!
thank you! yes it is coming!
I love watching your comparisons; I really enjoy your videos. I hope you can make a comparison between Fiber, Iris, and Gorilla Mux. Best regards!
thank you! noted! never heard about iris before :)
Add Hertz to the list too!
I believe the kubernetes CPU throttling is giving this benchmark an unfair comparison of the latency. Go is not aware of the cpu limit that you gave it. in general you should avoid cpu limits since how the kernel applies this limit will cause high tail latency, which can also explain why the throughput goes from 12K/s to 7K/s when throttling starts.
Would like to see the same test but with rust and go on their own nodes which they can use fully (so without any cpu limits). And would also be interesting to see them running on one node where they both get the same amount of cpu request but again no limit to avoid throttling, the requests will still make sure that both can equally use the cpu
ok i can do it, i was thinking about vm vs k8s benchmark due to throttling. i'll run few tests and see
this is normal cgroup cpu limit nothing special, just golang don't care how to calculate GOMAXPROCS inside cgroup
I think in real world app can be deployed like that, not under the perfect conditions. Go Lang should correct itself for limited usage.
@@AntonPutra consider adding GOMAXPROCS env with fieldRef to your container manifest
env:
- name: GOMAXPROCS
valueFrom:
resourceFieldRef:
resource: limits.cpu
@@erkintek You can set the GOMAXPROCS and GOMEMLIMIT env vars according to the pod cpu and memory limits respectively (rounded down to the nearest integer in the case of GOMAXPROCS). I do this regularly with GOMEMLIMIT (sometimes also tweaking GOGC) but haven't yet tested GOMAXPROCS. But the theory seems sound: Goroutines will be scheduled over only that many OS threads, so there should be less thread contention which improves tail latency. Uber has a package called automaxprocs to handle this automatically, and they measure significantly better p99.9 latency. Anton, this could be an interesting thing to test.
Nice! A lot more in line with what I saw with other tests. 👍
thanks!
PR sent with some basic improvements to the Go version.
Awesome video as usual 📺👍🏻
_Just a little unrelated note:_
Noun: *Degradation*
Verb: *Degrade* NOT -Degradate- 🚫
thank you! 😊
Rust is really incredible, it's shocking to see how fast it is and still offers so many features.
yeap!
I would LOVE to see the optimizations benchmarked next to each other as another video. Eg. Changing to cope on write improved speed by 20%. That way the audience would learn some optimization techniques vs just seeing what frameworks / languages are the most efficient.
Thanks! I keep getting PRs to improve Rust, Go, and other frameworks. I'll consider creating another video to go over each optimization technique I've received so far.
@@AntonPutra Awesome! thanks - I'm really enjoying your videos! super cool stuff here!
The big question - "Is the extra cost of developing a large app in rust worth the (minor) additional server costs if you choose go?" If you build a project in Rust and it is successful, finding good rust devs to scale it is much more difficult (and expensive) vs go devs
It's just a matter of time before many properly skilled rust programmers will become available. It's too good a language to pass up. There's evidence (a study performed internally by Google as it has started rewriting C++ stuff in rust) that once you've spent a couple of months in rust you start writing code much faster that with other languages - no surprise, I'd say, given rust's expressive power. Go's expressive power, OTOH, is awful, compared to most modern languages - which makes it a lot easier to learn, but once you're past that initial learning there's not much that you can improve further.
In the real world, to solve business problems, 9 out 10 times you should pick Go. Rust would be the right pick for niche cases where your specific use case benefits from the performance. I keep reading how popular Rust is but the reality is that the job market for it is tiny, you would certainly have issues hiring to maintain that codebase.
@@hyper_channel Provided you already know both languages, why would you _ever_ pick Go over Rust? Rust is faster, uses less memory and allows you to write the same thing in fewer lines of code. Also, the Rust compiler detects many more problems at compile time than the Go compiler.
What would be even a single advantage of Go? That a half-retarded code monkey who you wouldn't trust writing a hello world on his own could possibly understand the code? That's not relevant, in a professional setting.
The only situation in which Go would be a better choice is when your team already knows Go but doesn't know Rust, and the task at hand is a small one-off. If it's a larger project that's performance-critical, learning Rust already pays off. If it's a larger project without stringent performance requirements, Java or C# will do just fine, and still allow you to write less code faster.
Go filled a niche at a time when there was nothing to fill it: a relatively simple language adequate for writing robust and not overly complex systems software. Rust fully covers that, and much more, and does so better than Go.
Recently, Google started to rewrite its massive C++ codebase in Rust. They're the ones who created Go in the first place. How come _they_ didn't pick Go over Rust? Oh, and Google also translated some code from Go into Rust - leading to lower memory usage and lower bug count. Google hires tens of thousands of programmers, in case you missed it. Also, there's some pushback, but Linus is supporting Rust being used in the Linux kernel. Amazon and Microsoft are also using Rust. You won't need to search much for a job if you know Rust well. The only reason there are more jobs for Go is that Go is an older language.
The use of Rust can be a example of premature optimization. With Go your can iterate faster with good performance, only if your project scale a lot, at the point in which that minor difference is translated in hundreds of thousands of dollars, maybe makes sense search for something more low level, but in that case makes more sense use something like Zig instead of Rust, because Zig has better performance (more grained use of resources) than Rust and is more simpler (like Go) to implement.
@@SilasDuarte-e9k There's no optimization if your team already knows Rust. Unless you write the code in certain ways which cause Rust to generate inefficient binary code, Rust and Zig provide comparable performance. Zig or Go may make sense if your team doesn't know Rust already and if your project asks for performance but is expected to remain small and simple long term. For larger and more complex projects, even if your team has to learn Rust first it is still worth it.
Thank bro for doing that second test scenario, because that is a more frequent use case where you are talking to other services doing file and network stuff.
Good job. Would love to see more i/o centric middleware framework comparisons
thank you! will do in the future
I work with some people that think Node is good enough. I’d love to see the same comparison, with Node and/or Python mixed in. I know they’re not in the same league, I’m curious just how far out performed Node would be in this test.
Very cool stuff, thanks for doing this!
Go vs Elixir, Specifically for real time communication, where you have to maintain ws connections and send and receive messages from them.
This is great esp the ecosystem of erlang and telecommunication. I prefer Go, coz it has better ROI on what I do(APIs). My ROI is balance btw devtime and speed.
axum is great and more intuitive than the other rust frameworks but i wish there was a website. the docs are great but it would attract more developers if there was a website. especially for new developers because the rust docs are very difficult to read unless you are familiar with reading them.
Thanks for your awesome work!, It would be great if you could add a final time section at the end where you talk about conclusions drawn or summary of the finding.
Please make a Laravel vs express benchmark.
Loving your videos ❤
thank you! will do!
Love ur videos man, really useful
thank you!
Nowadays there's a lot of discourse (in some places) about moving from JS to PHP, especially Laravel. A performance benchmark between those two would be great!!
When we are talking about go, rust.. it means that we are trying to match them with C... Js and php are 10000 times slower than these languages in congestion.. use case is different for js and php now a days.. not sure if it is really worth to compare js and php.
Reference php on a rust & go benchmark is a joke lmao
@@trumvkl exactly 😅🤣😂
Absolutely no one is moving towards php
You just made that up, nobody would move anything from anything else to PHP
Very interesting!
One benchmark i would be really interested on would be replicating floats vectors over udp; for moving 3d objects; ( Actually it could be any kind of vectorized data going through udp )
it should be pretty straightforward but could also make use of several optimisation like cpu intrinsics; and it would also be interesting to compare it over different cpu architecture and see if arm is really that big of a deal in terms of costs;
Let’s say that one client have one vector of data that can change ( no need to add dirty bit / compression algorithms ) something like 60 time a second and it must be replicated to other clients; how many clients can it handle and what’s the error rate
Would also be nice to have the comparison between go / rust / ebpf? / other?
great learning about profiling n optimizations
thank you!
Great video!! Thanks!!!
Hey, Anton. Love your content. I'm quite new to programming - how are you running these tests? Are you using a prometheus library inside the code which exposes metrics so it can bee scrapped? Would be awesome if you did a beginner introduction so we could learn how to do some of these tests ourselfs
Excellent testing, thank you.
Oh, you are parsing uuid every single request last time in rust, no wonder it uses so much cpu last time
Thank you for this great content
Gin vs Echo benchmark please
thanks, noted!
Is surrealdb really as fast as they claim? I know it’s fast with little data, but I’d love to see some benchmarks vs other databases with lots of rows.
Would love to see how rocksdb vs the tikv cluster for data storage effects it.
AWS has recently deprecated the GO runtime. And recently released the Rust sdk out of beta
Go sdk v2 exists in 2024, if you mean lambda, provided.al2 or provided.al2023 are replacement of go runtime
Sir, can you please make a video on "Deno" vs "Node" vs "Bun". You are our trusted one. we don't trust company benchmark. they always lies to us.
It looks like the go postgres library automatically caches the prepared sql statements, but the rust tokio_postgres connection don't (you can opt-in to this with prepare_cache instead of prepare though).
thanks, i got your PR
I wonder how this compares to real life scenarios. Like what's the scale of the app that constantly has 14k requests per second. How many users is that typically?
it is possible that you have internal api which provides specific data that many your microservices would request, it's not necessary external api..
I hope fireship or prime watches this.
it's insane how rust handle memory
well golang has garbage collection and rust doesn't
@@AntonPutra yep that's my point too. tho props for golang to be pretty efficient being a language with gc
Most large-ish apps I see have much more CPU usage, so you should add that in somehow. Maybe rendering a template dynamically. Also, p90 is a better metric here than p99. Go will benefit from p99 due to GC not running in the 1%
fiber is best for performance. because we already saw the compression between go std/net vs fiber.
I’d also like to see how much of difference you are able to see when using the Minio client instead of the official AWS client.
In my experience (with Rust and C#) the official AWS SDK is complete and utter garbage. The Minio libraries work far better, even when using real AWS S3!
Hope that Rust fan won't complain about Go anymore
haha
Did you consider using axum framework instead of actix
yes, next video "actix vs axum vs rocket"
@@AntonPutra looking forward to thi :) Thank you.
@@AntonPutra nice 🔥
Mantulll😊@@AntonPutra
do c/c++ vs zig vs rust next time ;P
yes something from this list definitely :)
It'd be interesting to see how Zig relates to these two as well.
Zap (Zig) is coming in a day or two, but I discovered that you can only send JSON or text payloads in u8 size only :( Not very practical.
I would like to see the comparison between the rust(actix) with the optimization and go (stdlib) and go(fiber
)
It's interesting if you benchmark not only by language programming, but also by Technology such as implementing grpc or graphql based on go vs rust vs c# vs python
thanks for the tip, grpc vs rest vs graphql is coming. i tested grpc vs rest in the past as well and kafka vs grpc, lol
I think you need to show the network metrics. Are you saturating network. Since rust isn't using all of the cpu or memory, i think you are hitting limits in the network. Also, for the last test, you are getting latency spikes in both rust and go at similar times again, implying network limits.
ok, i have all the metrics. i will include them in the following videos, as well as packet drops
Can you do rust(actix) vs nodejs(express) so I can convince my team and manager to use rust over nodejs 😅
noted :)
It seems that developing real-world web applications in Rust, with databases and storage in S3, is similar to developing them in Golang. I think even Python might offer similar "performance" because the database is often the bottleneck.
yes, but try to develop one in zig (zap) 😊
Would be nice to see bottleneck in profiler instead of just client time
are there any articles on that topic🧐?
@@AntonPutra a lot, yes
@@AntonPutra"how to profile go/rust code"
@@CuriousSpy 🫡
I might get roasted but can you do rails newest vs Django latest
ok, noted!
@@AntonPutra that will be awesome thanks!
What we need right now is list result of th e benchmark for every language , so whois better for some cases , idlove to see the web
I think it would be nice to test with Postgres reads/ writes only, as it will show how well the two handle async operations in general.
ok i'll keep this in mind
Maybe Golang (Fiber) vs PHP v8.1 (+nginx if nessecary) next?
Java and Node. And then summary of all 4.
will do!
@@AntonPutra Thank you. Your work is very appreciated.
@@AntonPutra I don't know how overwhelmed you are but what would be really cool is adding Elixir to the test mix. They (and many others) claim it's the best thing ever invented for high user load like WhatsApp is using it etc.
Man I would like to be a competent rust developer so bad
if you know javascript i would go the wasm route for learning with leptos or dixious. i did rustlings, went through the book, and then wasm. it was a lot easier that way.
What charts library are you using? echarts?
no it's just grafana charts
I would love to see a comparision between golang grpc vs tonic
Good video.
At first test I think rust is not the limit, with %60cpu, and plenty of ram. K8s or requests may be?
LETS GOOO
🚀
Can you do the same tests but not setting a CPU limit in k8s (only request if you like it). We noticed that the k8s throttling is a Problem and using or restricting too much resources. We had 100% CPU spikes with a limit and without the services took only 1/3 of the production resources. Its only s problem if you run the service close to the limit of cou resources
Does the urge of comparing and proving rust is “awesome” come with its std?
Just comparing different languages and projects. I don't have any agenda.
dotnet aot vs java native vs go std pls
thanks, noted!
compare to fastapi?
Well, when I compare Rust with Fiber/Fasthttp, the Rust community gets upset :)
Which json library did you use for serializing JSON.
Most of the time when I saw the profile of benchmarks envolving JSON, the JSON marshal/unmarshal part always takes the most CPU.
Could if you try a different library for it?
which one you recommend?
They deprecated the lambda runtime for golang too, a while back
yeah just saw in in supported runtimes page, well i guess generic runtime for binaries is good enough
This is cool but see how close they are as soon as you get to a common real world scenario. 99% of the time you will be I/O bound. Apart from very niche cases there's no reason to go with Rust over Go to write APIs, hell even JavaScript is plenty fast 99% of the use cases.
I wonder if Rust can be more efficient for writing data pipelines. It may make a huge difference in cost savings.
clicked because of pic honestly
💔
It seems your new improved rust code is based on Axum, not Actix, am I wrong?
🤭
But what if in the test where go started failing at 14k rps you re-ran it but gave the go pod 500mb or even 1gb. out of interest maybe performance would be close ? using more RAM at the cost of an easier language than rust could be worth it ?
i don't think memory matters in this case but i'll check next time
Fiber vs Axum
next axum vs actix vs rocket, then i may run fiber vs fasthttp vs hyper
Nice benchmark. I didnt know rust web lib is mature to handle more traffic than go.
Would be great if axum is compared with go fiber. Go fiber is more popular now a days.
thank you
🫡
Спасибо Бро
🫡
Can you test PHP against other languages?
I'm curious if the cpu and memory differences in the second test point to not using a buffered file strategy in rust with go using one.
maybe i need to test
Rust is impressive!
it is!
I’m shocked to see so big differences in simple applications with two modern compiled languages 😮
Why the suddenspike in memory usage in rust? @12:50
Likely there are more in flight connections, and so more RAM used. It might be nice to add a gauge metric to count the number of concurrent connections to show this, but you can infer it from the request latency. If the request latency is rising, then the total connection time is taking longer and by applying Littles law you can see that the average queue amount growing.
50 seems low for requests per second. I wonder if you're running into some inadvertent local throttling (something like a default max concurrent connections in the sdk, or perhaps something like a max open files constraint). Turn the tracing level up to debug and look at the aws-sdk messages when you're hitting capacity. Also maybe add gauges for upload bytes to get a feel for whether this is bandwidth constrained.
thanks, i'll take a look at the defaults
next compare nodejs pls
can you compare Rust with C# too?
yes will do in the future!
Please compare speedb & rocksdb, thanks
ok noted!
Common rust W
Go (Fiber) beat Rust 🙃
@@MrlegendOr rare go W
I see one of the challenges of Rust moving forward is to improve the ecosystem and language so that it is easier to get most of the performance wins an expert can currently get, with drastically less expertise. For example, Cow is not a day one of learning Rust concept, but it is also something that in many situations a smarter compiler should be able to inject for you given immutable data structures.
The Cow change was reverted in a recent PR as being unnecessary
@@joshka7634 ok, but it is still the sort of optimisation that a smarter compiler should be dealing with. There are others.
pls take a look at this PR - github.com/antonputra/tutorials/pull/258
@@mrpocock Maybe - the delta we're talking based on the RPS change is ~40 nanoseconds and is less than a 1% difference in runtime. Choosing a data structure that requires an extra memory lookup seems like this is exactly the perf which this is hitting, and the sort of thing you'd really expect only to find when running something like this in a profiler to determine maximum efficiency. The fact that Cow was used here at all was a mistake that unintentionally caused a perf regression.
What impact has nginx ingress on the graphs?
i don't use nginx ingress in these tests, i just mentioned it.
Is the 2nd test a show case to prove that the language doesn't really matter as much as the IO connections you handle (or maybe the libraries that manages this IOs)?
Nice test. You may want also use PGO for go.
ok
With IO(s3, db) basically no difference
the file read time is between 100 to 200 microseconds, which is not relevant..
In aws lambda, we can increase the concurrency to 1000, without any extra cost. It will give more request per second.