Live data from Hacker News

How to Fix Slow Code in Ruby

engineering.shopify.com

141–150 of 213 posts

Re: How to Fix Slow Code in Ruby

#141
Really surprised how many commenters are talking about using a faster language when the example of slow code in the post is failing to cache the results of an expensive database query.

In my experience, even in "slow" languages, that type of thing is the predominant source of major performance problems, and the supposedly "slow" language would be perfectly adequate if you an stop shooting yourself in the foot (and if you can't, a faster language will not help you).

I'm sure there are extremely high-performance or high-scale points where language choice starts to matter more, but I'm also not surprised if Shopify is correct not to think they're there yet.

Re: How to Fix Slow Code in Ruby

#142

Earlier quoted context omitted.

Basically do not use Ruby

How is it that Python is able to do so many things quickly (even excluding NumPy/SciPy)? Is it more native code libraries? Could Ruby follow this path as effectively?

Are the Python web frameworks that much faster?

Re: How to Fix Slow Code in Ruby

#143

Earlier quoted context omitted.

> And yet Phoenix hasn't stolen a significant amount of market share from Rails. I thought we all learned popularity does not correlate with quality. It correlates pretty closely with corporate inertia and perceived lower risk of developer churn though. Businesses love tech stack for which there are bigger pools of programmers. Says nothing of the quality of the stacks. > If you're measuring hardware loads and bustin…

For years several Elixir cargo cult members are trying to preach to the Rails community to make the move and join them. But performance! But functional programming! Nobody cares guys. If performance and functional programming were critical in our domain we wouldn't have been Rails programmers right? I suspect most of the Ruby devs who got bored with Ruby already made the move to Elixir. The rest just read posts like…

Another point worth mentioning is that Elixir is only optimised for lightweight processes. If you have to do any heavy lifting you're better off with Go or a JVM language, not Elixir. Forget math with Elixir too - it doesn't even have an arrary/vector data structure of its own. Instead it relies on Erlang's hacky implementation.

Re: How to Fix Slow Code in Ruby

#144

Earlier quoted context omitted.

Both are not equal at all. Redis you can definitely do without. A database you can't skip in most apps. Sessions work quite fine in Elixir's local cache as well. :)

> Redis you can definitely do without. This seems to suggest otherwise https://hex.pm/packages/redix , Why is the redis client is so popular in Elixir world? For such a small community 3+ million downloads is huge.

Hint: it's most likely habit.

It's no accident that there's even a library that emulates OOP patterns in Elixir.

Re: How to Fix Slow Code in Ruby

#145

Earlier quoted context omitted.

Popular tech pays the bills of many people. Fringe tech is usually a secret weapon in consulting, or, more rarely (but still happening quite a bit), in a full-time job. Apples to oranges. Erlang existed for 30 years and has been used by its small-ish but also very vibrant community, with great success. So you know, very popular or not, us the people who use it successfully commercially will keep doing so. But as I ha…

The people who flocked to Elixir thought it was gonna be the new Node / Rails. They're now finding out it's definitely not gonna be either of those things. It remains to be seen if they love it enough to stick around, or will we see a silent churn to the new hotness or even back to Ruby.

Another gross generalization.

Re: How to Fix Slow Code in Ruby

#146

Earlier quoted context omitted.

Why do you consider Ruby to be inherently slow? I don't see why that would be the case. In fact, the performance improvements during the 2.x era seem to indicate the contrary: that Ruby can be faster.

> I don't see why that would be the case Well, the extensive use of “method_missing” appears to be staggeringly difficult to optimize short of a tracing jit and it’s also the core idiom of many popular frameworks. Of course it can be faster—if you remove the slow, unique features you can optimize it like any other language.

What makes you say that? method_missing is trivial with a tracing JIT and Chris Seaton's PhD covers how to do it for a method JIT.

Re: How to Fix Slow Code in Ruby

#147

Earlier quoted context omitted.

This is putting words in the mouths of other people and is close to a flame bait. (Not to mention your gross generalization of the members of a not-small community.) 1. The Elixir community doesn't seem to aim for popularity (at least several important maintainers have said so on ElixirForum). 2. The tech is useful, scales very well and helps with the hosting costs by using less resources. That's an objective fact, p…

> The Elixir community doesn't seem to aim for popularity (at least several important maintainers have said so on ElixirForum). Wow, then why does every Rails thread has an Elixir guy trying to tell us what an inferior software we're running? For the sake of humanity? > and will get more and more important as our CPUs can't get faster single-core performance and are just getting more cores. I don't think it will beco…

> Wow, then why does every Rails thread has an Elixir guy trying to tell us what an inferior software we're running? For the sake of humanity?

If you prefer that melodramatic phrase. I've been a Rails dev for 6 years and I know that many current Rails devs don't dare try something else -- call it a survivorship bias, fear to abandon what pays the bills now, habits, and most of the time you won't be wrong.

Every now and then I speak with some of them and we exchange ideas.

And you should stop stereotyping, it's juvenile and definitely has no place in HN.

Re: How to Fix Slow Code in Ruby

#148

Earlier quoted context omitted.

This is putting words in the mouths of other people and is close to a flame bait. (Not to mention your gross generalization of the members of a not-small community.) 1. The Elixir community doesn't seem to aim for popularity (at least several important maintainers have said so on ElixirForum). 2. The tech is useful, scales very well and helps with the hosting costs by using less resources. That's an objective fact, p…

> is close to a flame bait. (Not to mention your gross generalization of the members of a not-small community.) You're the one who chose to use the term cargo cult a few comments above

Well, I've been to Rails meetups. I can bet a few bucks that you haven't been to Elixir ones.

Re: How to Fix Slow Code in Ruby

#149
post #143

Earlier quoted context omitted.

For years several Elixir cargo cult members are trying to preach to the Rails community to make the move and join them. But performance! But functional programming! Nobody cares guys. If performance and functional programming were critical in our domain we wouldn't have been Rails programmers right? I suspect most of the Ruby devs who got bored with Ruby already made the move to Elixir. The rest just read posts like…

Another point worth mentioning is that Elixir is only optimised for lightweight processes. If you have to do any heavy lifting you're better off with Go or a JVM language, not Elixir. Forget math with Elixir too - it doesn't even have an arrary/vector data structure of its own. Instead it relies on Erlang's hacky implementation.

Which is exactly what many Elixir advocates say.

Contrary to what you and others try and insinuate, we are very aware that the language is not a universal tech.

So yet again, you guys are smacking at a strawman that's very easy to beat. It's quite tiring to argue with stuff that I never said (and most of Elixir's community haven't said it either). But I think I'll give up for now. :)

Re: How to Fix Slow Code in Ruby

#150
post #139

Earlier quoted context omitted.

> And yet Phoenix hasn't stolen a significant amount of market share from Rails. I thought we all learned popularity does not correlate with quality. It correlates pretty closely with corporate inertia and perceived lower risk of developer churn though. Businesses love tech stack for which there are bigger pools of programmers. Says nothing of the quality of the stacks. > If you're measuring hardware loads and bustin…

Can you elaborate how Rails maitenance is "much higher" than with Laravel given that Laravel is PHP's version of Rails?

This is what I have been told by a former Rails dev who is now doing Laravel. He said that Rails has much more automatically injected code that behaves in a way you can't anticipate intuitively (and many libraries encourage and extend that behaviour). As a former Rails dev myself I agree with that part.
Post reply on HN