Live data from Hacker News

How to Fix Slow Code in Ruby

engineering.shopify.com

131–140 of 213 posts

Re: How to Fix Slow Code in Ruby

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

You’d have to compare them to an equivalent shop in the same market of about the same size with a different stack to get a meaningful answer out of this—I’d say off-hand that it’s very unlikely their edge is tech.

Re: How to Fix Slow Code in Ruby

#132

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…

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 become more important in web dev world than it is now. We're here churning out back office CRUD apps like crazy, I don't know what you're doing. For a small team trying to get something up and running this really doesn't matter and that's what Rails is optimised for. If scale ever matters, if you scale that big, you probably already have the resources to deal with it. For the few startups that have huge scale + have very scarce resources and Elixir works well for them - great! I have no issues with that at all.

Re: How to Fix Slow Code in Ruby

#133

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…

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

Re: How to Fix Slow Code in Ruby

#134

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.

>> Of course it can be faster—if you remove the slow, unique features you can optimize it like any other language.

And at some point you might as well use Crystal if you're going to do that, while keeping a Ruby-like syntax.

Re: How to Fix Slow Code in Ruby

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

> Shopify is an insanely huge e-commerce platform (and a $100B company).

That's an interesting note. They have a $90b market cap, trading at ~53 times sales. It's one of the more extreme valuations I've seen in the last 25 years, including the dotcom bubble (and that's saying something with how overvalued everything cloud-related is today).

As one comparison for the absurdity, Yahoo during most of the height of the dotcom bubble, was trading for 30-50 times sales, growing sales faster than Shopify, and they were solidly profitable (Shopify has never earned a consequential profit in its history). That's how bad Shopify's present valuation is, to get good comps you have to reach into the dotcom bubble.

The market thinks they're Amazon-like. The problem is they've never demonstrated any great margins in their platform (despite 14 years and counting) and Amazon's big lift-off in their stock occurred solely due to the ability of AWS to generate immense operating income. Without AWS, Amazon eventually gets the sad multiples of a Target or Walmart on their retail business.

This is an obviously mistaken valuation riding one of the most overvalued markets in US history, one that will most likely brutalize investors that get in late. It's a classic example of how very inefficient and irrational the stock market can be in the shorter term. And no, that doesn't mean an investor should be the fool to step in front of the irrationality train and short it either (everyone here probably has heard the Keynes line about the market remaining irrational longer than you can remain solvent).

It'll take at least 10-15 years at a minimum for Shopify to grow into its present valuation, in the best case scenario, if everything goes perfectly and they some day find some margin in their business. If they eventually manage an enormous $2 billion profit ($1.7b in sales today ttm), they'll still have a 45 PE ratio at today's valuation. That's a prime market example of insanity.

eBay has a vastly superior business (in all regards, including its quasi-monopoly positioning and the tremendous profitability of ebay's platform), trading for a huge discount to Shopify, on the basis of the market's mistaken extrapolation about Shopify's future. If they're lucky, they'll one day be the size of eBay with a fraction of the profit margin (and of course eBay has a mere $29b market cap, 12x op income multiple; compression is a killer). I mention eBay (beyond obvious reasons), because Shopify is likely doing nothing more than pulling future returns forward to an extreme, as eBay once did (leading to a decade of stagnation in the stock).

Re: How to Fix Slow Code in Ruby

#136

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…

If you want the luxury of scale problems down the road you do RoR until you lock down that first couple billion dollars of valuation. Just ask Stripe, Github, AirBnB, Gusto, Shopify, Coinbase, Dropbox, Twitter, Door Dash etc. Then you can have the "problem" of picking the wrong language. Massive survivorship bias in the panning of Ruby/RoR IMO... Also the Ruby/RoR community and culture is better than most other langu…

I don't think Dropbox use/d Rails. But you can add Gitlab to that list which is a VERY good company.

Re: How to Fix Slow Code in Ruby

#137
post #101

Earlier quoted context omitted.

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

> Shopify is an insanely huge e-commerce platform (and a $100B company). That's an interesting note. They have a $90b market cap, trading at ~53 times sales. It's one of the more extreme valuations I've seen in the last 25 years, including the dotcom bubble (and that's saying something with how overvalued everything cloud-related is today). As one comparison for the absurdity, Yahoo during most of the height of the d…

They are probably overvalued. But they have a great product worth tens of billions and will eventually get earnings in line with their valuation. I wish I bought that stock years ago. No, wouldn't buy it now indeed.

Re: How to Fix Slow Code in Ruby

#138

Benchmarks are subjective, but all benchmarks show Ruby as slower than compared dynamic languages. The relative speed difference is different per benchmark, but across the board Ruby is slower. It fundamentally has to be slower. Ruby is the most dynamic of the dynamic programming languages. And the community has embraced metaprogramming, making it every more dynamic. Especially on webservers, you'll be executing hund…

People used to think JavaScript was too dynamic to optimize, too. Then people poured time and effort into it and now good JavaScript virtual machines can hold their own against competing implementations for other languages.

It's interesting because Lars Bak was optimizing Smalltalk and Self VMs in the 90s.

Re: How to Fix Slow Code in Ruby

#139

Earlier quoted context omitted.

And yet Phoenix hasn't stolen a significant amount of market share from Rails. > There are a number of web frameworks that perform much better than Rails If you're measuring hardware loads and busting out your stopwatch to measure response times, then sure. Bottom line is, there are plenty of good reasons to choose Rails over Phoenix. If you want to label choosing a well-backed framework with an incredibly mature eco…

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

Re: How to Fix Slow Code in Ruby

#140

Earlier quoted context omitted.

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.

There is always Common Lisp ...
Post reply on HN