Live data from Hacker News

How to Fix Slow Code in Ruby

engineering.shopify.com

111–120 of 213 posts

Re: How to Fix Slow Code in Ruby

#111
post #101

I wonder what would be more efficient, constantly trying to eke out some performance out of a inherently slow language? Or writing/rewriting new/critical paths of the codebase in a faster language. Ruby used to be able to say we sacrifice performance for developer productivity. I don’t think this is any longer true, there’s plenty of languages out there that developers can be just as productive with, while producing…

Shopify is an insanely huge e-commerce platform (and a $100B company). I'd say their developers are pretty productive with Ruby on Rails.

Yes, and at the time Shopify was started Ruby was likely a very good choice. The parent comment is saying that today there are alternatives that run faster and provide similar levels of productivity.

Re: How to Fix Slow Code in Ruby

#112

Earlier quoted context omitted.

> For 3.5 years with Elixir this is the first time I hear that this is a problem. Any data to back this up? My point is that it doesn't come with Phoenix out of the box (unless something has changed?), and that difference in philosophy is the core of what I'm getting at. With rails new I'm getting an end-to-end test suite and chrome driver installation for free. Phoenix also has no plans of implementing something sim…

> If Phoenix wants to increase their adoption, then I think they need to accept that things like this matter. It's gonna be tough for them really, even if it's a great framework (I have no idea). Elixir didn't take off like Golang or other languages from the last decade. It seems to have quite the learning curve, so for beginners any of ruby / php or even .net / java will make much more sense. For seniors...idk. Not…

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 have said in the past, if Rust (or OCaml, or any statically strongly typed language that compiles to native code) gains all the guarantees of the BEAM VM then I'll abandon Elixir the next day.

Re: How to Fix Slow Code in Ruby

#113

I wonder what would be more efficient, constantly trying to eke out some performance out of a inherently slow language? Or writing/rewriting new/critical paths of the codebase in a faster language. Ruby used to be able to say we sacrifice performance for developer productivity. I don’t think this is any longer true, there’s plenty of languages out there that developers can be just as productive with, while producing…

I don't wanna answer for Shopify because I don't work there, but: 1) Shopify LIKES Ruby. The founders love it. You don't drop this after 15 years to gain 20% more speed. 2) Rewrites are hard. We're talking about millions(?) of lines of code 3) Their teams will have to adapt to a new language 4) Maybe 10 years from now a faster language appears - do they do a rewrite yet again? 5) Optimising things is a part of what we do as developers and even love to do. Is it unheard of to try to optimise your code in java? 6) > there’s plenty of languages out there that developers can be just as efficient in. That was always the case. Rails devs still believe (for the most part) their framework is productive and fast enough.

Re: How to Fix Slow Code in Ruby

#114

Earlier quoted context omitted.

I've seen conflicting benchmarks on this showing different results - possibly has changed over time, or run different comparisons. What you linked seems current at least.

No, both your post and this reply are dogmatic. As I said, Ruby is the slowest modern dynamic programming language (and it's much slower than Perl). I really wish the Ruby community would listen to valid criticism. All dynamic languages are deeply flawed in some way, especially Ruby, and most ecosystems are open to learning from others.

> …much slower than Perl

To do some things but not others?

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: How to Fix Slow Code in Ruby

#115

Earlier quoted context omitted.

Why?

Because crystal lang has all of the main syntax and features that people love about Ruby, but it's way faster because of the typing and compiling. "Fast as C, slick as ruby"

> Because crystal lang has all of the main syntax and features that people love about Ruby

Except for one at least massive feature... runtime metaprogramming... on which the entire Rails ecosystem is built.

Re: How to Fix Slow Code in Ruby

#116

I wonder what would be more efficient, constantly trying to eke out some performance out of a inherently slow language? Or writing/rewriting new/critical paths of the codebase in a faster language. Ruby used to be able to say we sacrifice performance for developer productivity. I don’t think this is any longer true, there’s plenty of languages out there that developers can be just as productive with, while producing…

> there’s plenty of languages out there that developers can be just as productive with

There aren't that plenty really. Golang has nothing like Rails, neither does Node. You can say Django / Laravel but then it's the same performance issues. Or maybe you're talking good old enterprise software like Spring / Asp. I don't think Ruby/Rails should feel inferior to any of those names for web development.

Re: How to Fix Slow Code in Ruby

#117

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?

Is Python is able to do so many things quickly?

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: How to Fix Slow Code in Ruby

#118

I wonder what would be more efficient, constantly trying to eke out some performance out of a inherently slow language? Or writing/rewriting new/critical paths of the codebase in a faster language. Ruby used to be able to say we sacrifice performance for developer productivity. I don’t think this is any longer true, there’s plenty of languages out there that developers can be just as productive with, while producing…

> there’s plenty of languages out there that developers can be just as productive with There aren't that plenty really. Golang has nothing like Rails, neither does Node. You can say Django / Laravel but then it's the same performance issues. Or maybe you're talking good old enterprise software like Spring / Asp. I don't think Ruby/Rails should feel inferior to any of those names for web development.

How about Elixir/Phoenix?

Re: How to Fix Slow Code in Ruby

#119

Earlier quoted context omitted.

> there’s plenty of languages out there that developers can be just as productive with There aren't that plenty really. Golang has nothing like Rails, neither does Node. You can say Django / Laravel but then it's the same performance issues. Or maybe you're talking good old enterprise software like Spring / Asp. I don't think Ruby/Rails should feel inferior to any of those names for web development.

How about Elixir/Phoenix?

Absolutely not, Shopify is on a roll. What a crazy ass decision it would have been to rewrite things in Elixir lol.

Re: How to Fix Slow Code in Ruby

#120

I wonder what would be more efficient, constantly trying to eke out some performance out of a inherently slow language? Or writing/rewriting new/critical paths of the codebase in a faster language. Ruby used to be able to say we sacrifice performance for developer productivity. I don’t think this is any longer true, there’s plenty of languages out there that developers can be just as productive with, while producing…

I don't wanna answer for Shopify because I don't work there, but: 1) Shopify LIKES Ruby. The founders love it. You don't drop this after 15 years to gain 20% more speed. 2) Rewrites are hard. We're talking about millions(?) of lines of code 3) Their teams will have to adapt to a new language 4) Maybe 10 years from now a faster language appears - do they do a rewrite yet again? 5) Optimising things is a part of what w…

I agree for Shopify a rewrite would not make sense.

But I think writing new features, or rewriting some critical paths of the codebase in a new language could make sense.

It's atleast a valid question.

They are clearly already spending a lot of resources optimizing Ruby code to match their demands.

My question is at what point does continuing with Ruby become trying to force a round peg into a square hole?

Post reply on HN