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

[neonsunset]

Dapper is great. I'm very happy that there now exists an AOT-supporting flavour of it too: https://aot.dapperlib.dev/

As for EF Core - it very good as of today (has it ever been bad?). You can transparently compose your queries with `context.FromSql(...).SingleAsync()` which will use string interpolation API to consume your plain $"SELECT * FROM {myTable} ..." and make it injection-safe and transform passed arguments as appropriate. It's quite handy.

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

[tomlin]

I'm a Nintendo die hard fan boy, I don't care about speed. I learned how to "code" in ColdFusion. I am all for the underdog POV.

We're talking about performance because of the context, which is – there aren't the jobs to support the language's continued growth and dedication. We're talking about speed because there needs to be a defining reason to continue using a language and develop in an ecosystem that isn't moving at the growth of other communities.

If Nintendo Switch had 4 games, and they all looked like dog piss - asking why would I bother wasting time with Switch is a valid opinion.

There's also this insect-minded logic of only being a "front end developer" or "back end developer", and that mindset is furthered by languages that don't bother speaking the language of the web. If I learn javascript, I can be both - pretty much on day 1. If I learn Ruby and Javascript, great. How easy is that to do for a junior developer just getting out of school? Not widely.