Anyone who comes across this post while considering what language to use for their next project ought consider factors other than bare-metal throughput or latency when building either user-facing web applications or backend microservices.
These sort of naive questions about whether a language is good based on throughput are generally frowned upon in any development community because they are not the kind that lead to how decisions get made by the vast majority of tech managers or developers. There are scenarios where maximum throughput matters most, but you very likely are not solving problems for that scenario. If you are, you shouldn’t even be using TechEmpower Benchmarks to drive a decision because doing so is evaluating HTTP-based solutions when you ought to be using a gRPC one instead, or another IPC protocol with even less overhead.
RwLock allows for no more than one thread at a time to modify its state. A poison condition is a signal that you were using the wrong synchronization primitive for the problem at hand. This aside, it could easily take an experienced programmer 3 months of onboarding before becoming comfortable with Rust unless they already have experience with low-level primitives. A junior developer could take even longer.
Downloaded and being used in production aren’t the same thing We know lots of big apps using Elixir and Phoenix, yet I know of none using any of those in their top 10.
Phoenix has a cool 97M downloads, Actix has 9M. I would have expected a lot more given their position in those benchmarks, but as mentioned we know lots of real world apps using Phoenix but almost none using those. It does make you wonder why
TBF that’s also down to culture. Most Rust devs I knew were very quiet (not advertising or sharing what they work on and how do they achieve it) but also super hardcore. So it’s a spectrum; it’s not only one factor contributing.
But in the end, Rust is not a good fit for a web / API backend due to the iteration speed being woefully slow esp. compared to the one you’ll get if you employ experienced Rails / Phoenix / Laravel devs. And Rust devs who can quickly iterate on a web / API backend are extremely rare (and likely 3x - 5x as expensive as a corresponding Rails dev).
Whereas Golang can very easily steal Rails or Phoenix lunches. It’s an absolute pleasure to iterate on a Golang project and if you use the right libraries and are decent dev yourself the code is also super terse, almost as terse as Elixir. Surprised I am not seeing more Golang in all these would-be “benchmarks”, at least in terms of downloads / popularity scores.
Now we have to divide the downloads by the amount of releases. Cause if I update my lib with 10 users each day, it’s user base might seem bigger than is actually is.
And how about CI downloading a package for every build?
Statistics are hard, download statistics even harder
Whereas Golang can very easily steal Rails or Phoenix lunches.
Can you iterate more on that? I find golang not a good fit for web development. In my opinion golang lacks good high level libraries (a good example would be using primitives like goroutines in code, to me, this would be equivalent to using low level process functions in elixir). I feel like golang shines where you need to do low level stuff, but you can get away with not using rust or c. For example I know for a fact that Nokia migrates their telecom related stuff from c to golang.
Yeah I meant to try that one but it looks a bit more convoluted and these days I am much more a “generate me 3 files maximum and let’s gooooooo” kind of guy.
We know lots of big apps using Elixir and Phoenix, yet I know of none using any of those in their top 10.
