Live data from Hacker News

Ruby 3.3

ruby-lang.org

241–250 of 277 posts

Re: Ruby 3.3

#241
post #193

Earlier quoted context omitted.

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…

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…

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.

Re: Ruby 3.3

#242

Earlier quoted context omitted.

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.

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

Oh okey, that clarifies it!

Re: Ruby 3.3

#243

Earlier quoted context omitted.

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

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

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.

Re: Ruby 3.3

#244

Earlier quoted context omitted.

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

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…

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.

Re: Ruby 3.3

#245
post #95

Earlier quoted context omitted.

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

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.

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

Re: Ruby 3.3

#246
post #241
post #193

Earlier quoted context omitted.

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…

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.

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.

Re: Ruby 3.3

#247
post #193

Earlier quoted context omitted.

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…

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.

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.

Re: Ruby 3.3

#248
post #247

Earlier quoted context omitted.

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.

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

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.

Re: Ruby 3.3

#249

Earlier quoted context omitted.

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

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

I wasn't trying to say that Ruby indeed is 80% faster, but that it's pretty much impossible to drive actual Ruby speed up from Rails numbers, since we don't know nearly enough about the Rails app

Re: Ruby 3.3

#250

Earlier quoted context omitted.

I'd choose Go and Java any given day before Rust. That language with C++ mindset is just... horrible.

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.

> I simply don't have the extra time and energy to learn

Nobody does these days. Language is just a tiny piece of the whole Cloud ecosystem aside from k8s, docker, different storages (elastic, rdbms, mongo), different monitoring/metrics solution, etc.

I work for a company that is testing Rust and the complain was that the tooling wasn't there compare to Golang.

Post reply on HN