[IshKebab]

> double digit performance improvements

You mean like 10% faster, or 10x faster?

Edit: clicked the link; it's 10%. I don't think that's going to make any difference to the perception of Ruby's slowness given that it's on the order of 50-200x slower than "fast" languages like Rust, Java, Go and C++.

[ciconia]

Note this is for a Ruby on Rails application. The slowness is I believe more due to the framework than the language runtime. In any case, it's still early to determine the impact on performance from upgrading to Ruby 3.3. I guess we'll be able to tell more in the coming months.

[pdimitar]

> Note this is for a Ruby on Rails application. The slowness is I believe more due to the framework than the language runtime.

Hardly relevant, I'd think at least 80% of all Ruby usage everywhere is in Ruby on Rails applications.

[ajmurmann]

How much of the time in a given request is even spent in Ruby code? The majority of web apps that were slow and I got a chance to analyze were spending much of the time in DB queries and slowness was usually due to unoptimized DB queries. Even endpoints that were fast, still spent a large percentage of their time not in Ruby but in DB and service requests

[pdimitar]

That is true, yes, but still comparing e.g. Rust vs. Ruby I'd think Rust spends anywhere from 10ns to 100ns (outside of waiting on DB) and Ruby no less than 10 ms. Still pretty significant and can add up during times of big load.

Also I remember Rails' ActiveRecord having some pretty egregious performance footprint (we're talking 10ms to 100ms on top of DB waiting) but I hear that was fixed a while ago.

[ajmurmann]

My point was that if we look at Rails performance going up 10%, what does that mean for time spent in Ruby. I'd believe anything from a 15% to a 80% reduction of time spent in Ruby code

[pdimitar]

I haven't seen 80% anywhere in the linked article[0] so let's use facts and not beliefs.

It is possible Ruby itself got accelerated a lot, okay, I am just not sure that's relevant since almost all Ruby usage is Rails.

[0] https://railsatscale.com/2023-09-18-ruby-3-3-s-yjit-runs-sho...

[Alifatisk]

It is relevant if the cause of the slowness is due to the framework rather than the language itself.

The performance can vary drastically depending on which Ruby framework you use, so it's not due to the language but the upper layer instead.

Note, even if Rails is the most popular framework, there is still other alternatives which makes it even more relevant to the performance impact.

[resonious]

I suspect there's not just one cause of slowness here. Pure language benchmarks also tend to rank Ruby very low. So I'd wager that a fast Ruby framework would still lose to a fast Go framework.

[Alifatisk]

Absolutely, I should maybe clarify that I did not mean to say that we can fully rule out the language itself as a cause of the poor performance, Ruby always perform worse than Go in this example for obvious reasons.

But, saying that the frameworks using the language under the hood has almost no relevancy is wrong in my opinion! And that is what I was trying to point out.

[pdimitar]

> But, saying that the frameworks using the language under the hood has almost no relevancy is wrong in my opinion!

I did not claim that in general sense, I said it with the context that even if Ruby got accelerated a lot then that's still kind of inconsequential because most Ruby usage is Rails.

[cutler]

Apples to oranges again. A more relevant comparison would be Ruby to Python and in recent years Ruby has edged ahead in performance if you factor-out Python's C-based libraries such as Numpy.

[resonious]

If we're comparing "programming languages that can be used to make websites" then it's totally apples to apples. Ruby and Go (and Rust, Java, etc) are all valid options and so I think it's smart to compare them before starting a web project.

[csjh]

Isn’t factoring out C based libraries ignoring a large part of the Python ecosystem?

[ksec]

If you compare pure Ruby without Rails to fast language like Rust, Go and Java. It is probably closer to 10-20x.

The 100x to 200x mainly comes from Rails.

[byroot]

Can we stop with these useless comparisons? 10x-20x, 100x, 200x out of context means absolutely nothing.

All these micro-benchmarks shootouts means nothing either. Is anyone running a mandelbrot or pi-digits SaaS company? I'd think not.

Similarly saying Rails is slow out of context, means nothing, Rails is "slower" than Ruby micro-frameworks X because it does useful things the other doesn't like CSRF protection etc. If you don't need these features, turn them off and Rails will be about as fast as these frameworks.

If anything annoys me more than clueless people shitting on Ruby for bad reasons it's Rubyists spreading FUD about Rails.

[nsajko]

Perhaps it's misleading to throw around specific numbers like 100x, but Ruby is certainly orders of magnitude slower than languages like Go or Java. Both of which are not exactly known for their speed (compared to C++ or Julia, for example).

[byroot]

"speed" thrown without context is meaningless. It's one property of a tool among many others you generally have to trade for.

Some use cases with small margins call for the utmost efficiency to be viable business. Some use cases just need decent efficiency and are happy to trade some efficiency for some other properties.

Many successful people and companies are happy with Ruby, can we just give them a break? Or is there somehow some moral duty to use the "fastest" language available regardless of whether it makes any kind of business sense that nobody told me about?

[ksec]

On the other hand, why is it wrong to say Ruby or Rails is slow? Especially in the context of Java or Go? What is wrong with accepting a simple ground truth that is compiled language is and will always be faster than an interrupted language, even with JIT.

For Rails I often compare to it another CRUD app, StackExchange [1] using ASP.net And the easiest real world comparison with Rails App would be Cookpad. Are we not seeing at least 10x difference if not more.

Is Rails fast enough? That depends on the context. Everyone's business model is different. It is almost definitely fast enough for most SaaS cases.

[1] https://stackexchange.com/performance

[byroot]

> What is wrong with accepting a simple ground truth

Where am I denying that? Saying that one of the most dynamic language is slower than Java or Go it's such a truism it's pointless.

What annoys me is the figures quoted. I can craft you benchmarks were Ruby is barely any slower than these two, or benchmark where it's 1000x slower. So which is the correct number to quote?

> For Rails I often compare to it another CRUD app, StackExchange [1] using ASP.net

This makes zero sense. You said:

> If you compare pure Ruby without Rails to fast language like Rust, Go and Java. It is probably closer to 10-20x.

> The 100x to 200x mainly comes from Rails.

So somehow you are blaming Rails for making Ruby 10 times slower whatever that means. That is a stupid statement that you took out of your hats and that doesn't reflect any reality. Please stop doing that, it's really unnerving for the people who maintain these projects.

[ksec]

>So somehow you are blaming Rails for making Ruby 10 times slower whatever that means.

>That is a stupid statement that you took out of your hats and that doesn't reflect any reality.

I will leave it at that.

[cutler]

Apples to oranges, no?

[Alifatisk]

I seriously don’t think it’s worth comparing Ruby to languages like C++ and the rest.

One is scripting language, the other compiled, the difference is huge already there.

[pdimitar]

> I seriously don’t think it’s worth comparing Ruby to languages like C++ and the rest.

It is worth comparing any two languages and ecosystems if they are used for the same things, in this case -- web backends.

Anything and everything that has a web backend is a fair game for comparison.

[ric2b]

Building a web backend with C++ is a very dangerous and complex ordeal, you're extremely likely to expose memory based vulnerabilities to the entire world.

[pdimitar]

Yes, but I haven't argued that. Let's not shift goal posts.

[jupp0r]

Google, Facebook, Amazon and Twitter beg to differ (not completely C++, but for services where it makes sense). Also nginx, passenger and other parts of your Ruby app.

[hello_moto]

shrug the companies you mentioned do not use C++ for web-app.

Amazon is a huge Java shop.

Twitter used to be huge Rails app with Java/Scala services.

NGINX and Passenger are infrastructure pieces just like Memcached so I think you need to understand the context here...

[jupp0r]

Shrug, you have no idea what you are talking about [1]. Also nginx and passenger are webservers and claiming they are not part of your web app is a pretty wild claim when they literally send http responses to browsers (unlike memcached).

[1] https://en.m.wikipedia.org/wiki/Programming_languages_used_i...

[pdimitar]

I agree but people are doing it anyway. So technically Ruby on Rails and C++ are competitors in the web backend space.

[Alifatisk]

RoR and whatever C++ based web backend there is count as a valid comparison in my book. But comparing the languages itself is maybe a bit off.

On a side note, you can actually compare their performance here if you’re really curious. But take it with a grain of salt since these are synthetic benchmarks.

https://www.techempower.com/benchmarks

[hello_moto]

Who builds web backend in C++?

[jupp0r]

7 of the 10 most popular websites https://en.m.wikipedia.org/wiki/Programming_languages_used_i...

[pdimitar]

The amount of companies who do that is greater than zero.

[cutler]

Web backends in Rust and C++? Not saying web frameworks in these languages don't exist but to claim they're anything other than curiosities is misleading. In any case, good luck with the fraction of a millisecond such languages gain you while waiting on database i/o. There are use cases for switching to a compiled language like Rust or C++. Web back-ends isn't one of them.

[wredue]

Nah. One rust based server can power the same number of connections as 10-100 ruby based servers.

This is not just “pretend database IO” problem. This is actual cost that no business should accept on the basis of “but but but database IO (that I’ve never actually measured, but it’s an easy cop out because I read it on medium once).

[cutler]

But you factored-out developer productivity. What you gain in reduced server costs is lost many times over in developer productivity. Companies who chose Rails for decades knew it was slower and more memory-hungry than rolling everything yourself in Rust or C++. They did the math and the business case for Rails was more compelling.

[pdimitar]

> But you factored-out developer productivity.

Let's not act like everyone who tries Rust gives up. OK? Sure it's definitely more difficult but people are learning and practicing and the pool is slowly expanding (me included, though I am not at production-grade experience yet).

> What you gain in reduced server costs is lost many times over in developer productivity.

Are you exaggerating for dramatic effect? I'd say depending on your people's seniority the productivity loss is anywhere from -50% to -500%, which is hardly "many times over".

You absolutely do iterate slower with Rust writing web backends -- no two ways about it. But you also (a) exaggerate the multiplier and (b) underestimate the long-tail of gained productivity that a language like Rust brings to the table (strong static typing et. al.)

And even if we take into account your comparison between server costs and programmer productivity -- there are areas where correctness and speed are more important than Joe and Susan being able to crank out 17 CRUD endpoints this week. I feel that this nuance is often ignored.

> Companies who chose Rails for decades knew it was slower and more memory-hungry than rolling everything yourself in Rust or C++.

I have worked with Rails for 6.5 years and they knew no such thing. They treated server costs exactly like they treated programmers -- a necessary evil, a cost center that (currently) cannot be optimized away.

I am consistently blown away by the protected and downright pampering environments that some HN people have lived in. It's pretty brutal out there though, and somebody has to point that out to you every now and then, lest you forget it (which it seems that you did).

> They did the math and the business case for Rails was more compelling.

They did no math, except one: how easy it is to hire 5 new devs in the next 1-2 months. No other analysis was involved whatsoever. Again, I've looked from within, a good number of times.

---

I am all for an informed debate but that seems to be difficult with you as you resort to exaggerations and dramatic language.

For the record, I don't do my main work neither with Ruby on Rails nor with Rust (though I know both, or should I say I knew RoR because I haven't used it in a while now). I got no horse in the race, I am simply looking for an objective discussion based on merits that can hopefully ignore network effects and popularity. Technologies absolutely can and have won by utilizing network effects and popularity (see: Python) but that does not say much about their objective merits.

[wredue]

Rails is no more productive than go, and a developer taking 20 extra minutes (frankly, not likely, even if we’re talking rust) to write go rather than Ruby is not going to cost more than the $1000 a month the extra Ruby servers cost you just to run.

“But but but developer productivity” is a myth.

[pdimitar]

Yes and no, some languages like Python and Ruby do introduce overhead even in conditions where waiting for the DB is 80-90% of the time spent on a web request -- that much is true. But the database I/O problem is definitely not pretend. It's very real.

[hello_moto]

I'd choose Go and Java any given day before Rust.

That language with C++ mindset is just... horrible.

[pdimitar]

They all have their niches. Rust is difficult but rewards you for your persistence.

I do appreciate Rust a lot but nowadays find myself reaching for Golang more often. I simply don't have the extra time and energy to learn the final more advanced Rust pieces in my own leisure time so I'll learn it whenever I can but yeah, in the meantime: Golang to the rescue.

[IshKebab]

I would agree with C++, but not Rust. Describing Rust web backends as a curiousity is inaccurate.

[pdimitar]

I am not interested in being put in a corner where I have to defend web backend creation that I don't even practice. I only said it's being done by people. Feel free to reject it or degrade it as being "a curiosity", from where I am standing reality disagrees with you though.

[Alifatisk]

> It is worth comparing any two languages and ecosystems if they are used for the same things, in this case -- web backends.

Right I see your point, but in this case it’s about Ruby, the language itself, not RoR.

[pdimitar]

Not denying it, I just struggle to find any non-RoR usage of Ruby out there except maybe for Homebrew.

[Alifatisk]

You're right about that, and that's something I believe the Ruby team is struggling with, to show where Ruby is useful outside the Web field. Everyones picture of Ruby is web related thanks to Rails, there is no question about it.

And I find that bit sad because Ruby is also good at other things like building cli apps (have a look at Metasploit for example) & gluing different moving parts together, creating your own DSL thanks to its flexible language structure.

I wouldn't say Ruby is better than any other languge though, all general purpose language could probably achieve the same result, it's just a matter of taste.

[pdimitar]

We're venturing in the not exhaustively objectively proven benefits and virtues of strong static typing but nowadays I reach for Golang and not for shell scripts (or Ruby, or Python).

Why?

Just today I again had to do Homebrew cleanups so one recipe can install. Likely my fault, 100% sure about it, but I just need non-confusing tools in my life.

...Or I kept grooming my homemade cross-machine provisioning scripts (i.e. install baseline tools like git and a few others, and then bring my up entire environment along) and in the end it still couldn't source a script that is right there in the file system and even after I made sure it got sourced, it still couldn't find the stuff inside it... while all other 20+ such similar `source stuff.zsh` work just fine.

At one point you do get fed up. (And yes I know this is not strictly related to strong static typing; it's just one example of a thing that will reduce bug surface.)

Ruby is easy to write. And that's the problem. People tried to do too much with it. And it's early glory of including a gem that monkey-patches the core library APIs did not do it any favors either.

Nowadays I don't appreciate unbridled freedom as much. I appreciate and even enjoy constructive limitations. Truth is we can be very much like kids and should be protected from harming each other.

But yeah, that's venturing into philosophy which was not the topic.

TL;DR: Ruby is fine but is fairly limited for my taste. My needs are far bigger and they also include maximum 50ms of startup time.

[chucke]

Metasploit? Logstash? Docker-sync? Vagrant? Jekyll?

[CoolCold]

Chef? Puppet?

[pdimitar]

Oh oops. I used Chef years ago but forgot. Thanks for reminding me.

[trealira]

It may be worth comparing this new JIT to fast implementations of dynamic languages, like LuaJIT or SBCL for Common Lisp (SBCL is an AOT compiler and not a JIT though).

[tomlin]

I'm so glad that you said this and weren't downvoted into the ground. Honestly, Ruby needs to die. It performs like a go cart in a Formula 1 race. I'm actually just exhausted watching smart people tell me this is a language and toolchain worth dedicating brain cells to.

[the_gastropod]

What a bizarre take. Ruby is primarily used in web applications, where round-trip http requests, database queries, and other 10s-of-ms things are commonplace. Ruby is very rarely the bottleneck in these applications. Choosing to make your job significantly more challenging in order to maximize the performance of a small portion of the total response time of a web application is not, in my estimation, a smart decision.

[seabrookmx]

There's always this rift between the "language is slow" crowd and the "but it's not the bottleneck" crowd. I think this comes from the types of applications you work on and their scale.

I work at what a company that's not particularly large. Our original API is a Django monolith that serves about 1000req/s.

While you could argue Python isn't the bottleneck, Django often is. I hear the same feedback from colleagues that work in Rails. Not only do we run into issues with latency per request but we have to run a significant number of Kubernetes pods to serve this workload. With c#, golang, java or a similar language we would only require a handful of pods and drastically cut our compute costs.

Even for web workloads, these slow interpreted languages and their developer experience optimized frameworks absolutely do become a bottleneck and claiming they don't (or that you need to be at Google/Facebook scale before they do) is false.

Everything is a tradeoff but the way I think of it: speed is a feature.

[ochoseis]

Further, with a lot of the batteries-included web frameworks you end up with a ton of suboptimal database queries (e.g. unintentional query-in-loop). Some would argue that you can just profile your code and optimize the hot spots, but I would tend to think it still slows you down quite a bit overall.

[neonsunset]

One of the biggest breaking changes that EF Core did was to explicitly disallow such generated queries that required application-side evaluation and could not get compiled to pure SQL (you can get other behavior back with a toggle but it is discouraged).

I strongly believe it is wrong to do otherwise and is a source of numerous footguns unless you invest in tracking them down.

[seabrookmx]

I will admit I'm behind the state of the art with EF, but I switched to dapper in the early days of dotnet core and never looked back. It gets out of my way so I can properly utilize postgres' advanced features like jsonb while cutting out a lot of the boilerplate associated with hand-rolled queries.

[seabrookmx]

So common that apps like sentry have special logic to detect these "N+1" queries. We find DRF is awful for this.

[fomine3]

It's 'resource usage' rather than 'speed'

[tomlin]

You're literally the exact person I'm talking about. No serious application developer who's interested in speed is working in Ruby. This isn't my opinion. I don't care personally, it's just a fact if you care about reality. When Netflix announces that they use Ruby because it performs faster than Node.js, I'll change my opinion, because my opinion is based on facts and not feelings. I didn't make Ruby, so whether it does well or fails isn't personally important to me. If Ruby was the fastest interpreter, I'd be pro-Ruby but it absolutely isn't and pretending it is is depressing and shows you are making political or selfish decisions, not practical ones.

[Lio]

I don't think you can argue that you personally don't care about ruby.

You wouldn't spend so much of your time reading and writing about ruby if you didn't care about it. You'd move to things you do care about.

Ruby, and scripting languages in general, are fast enough for the jobs they get used for. When they're not they get replaced.

[tomlin]

Most of your comment is about what you think I think, and not a lot about metrics, data or examples where Ruby performs beyond my interpretation. I think that says a lot right there.

[the_gastropod]

Nobody is pretending Ruby is the fastest interpreter. Who are you arguing against? Rubyists generally consider Ruby “fast enough”. Which it is, for many applications.

For every engineer insisting Ruby is fast enough in a situation where it is not, there are 1000s in environments where Ruby absolutely is more than sufficient, insisting it’s too slow.

[tomlin]

It doesn't answer the question of why you would choose Ruby. Honestly, you all sound like you got a Sega Genesis for Christmas, while everyone else got a SNES. You can tell other kids on the playground that Genesis has better graphics, but the spec sheets don't lie.

You're trying to make it seem like it's a wash, because "scripted" but it's not. Node.js outperforms Ruby in every department. And it's based on one of the slowest scripting languages of all time. Ruby is a dead language in many countries.

In Canada, you would have to travel the country to find a Ruby job. And if you don't think in American-centric terms, that is meaningful.

[the_gastropod]

Fine analogy. Plenty of people liked the Sega Genesis more than the SNES. (I think a more apt analogy is more contemporary consoles, where the lowly-spec’d Nintendo competes just fine against the competition’s higher performance units. People like Nintendo for reasons other than the spec sheet.)

I enjoy writing Ruby a heck of a lot more than I do writing JavaScript. I like the object model. I like Ruby’s standard library. I like the Ruby community. I like the tooling: irb is fantastic. Bundler is still one of the best package managers around—makes npm and yarn look silly by comparison.

The spec sheet just does not matter for virtually any of my work. Switching to a less enjoyable, more performant, language might make a 60ms response time average become 55ms. Who cares? That performance difference was even bigger 15 years ago, and it didn’t matter then. It matters less today.

GitHub, Shopify, Airbnb, Netflix (yes! Even Netflix!), Soundcloud, Kickstarter, etc. etc. all use Ruby today. It is a fantastic development environment when you’re more concerned with doing your job, and less concerned with performance pissing contests.

[aantix]

Ruby and Python are the only two ecosystems that seem to prioritize developer happiness. They're a pleasure to work with. So they're not going to die anytime soon.

[cutler]

Python might be popular but developer happiness isn't a concept I'd associate with the language. There's no joy in being limited to single statements in lambdas, for example.

[tomlin]

Python is somewhat pleasure. Ruby might as well be sandscript as far as I'm concerned. The use of pipes is gross, uncoordinated and lacking direction.