5 ms·
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
by praveenperera 6y ago
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 wildly more performant code.
- pdog 6y agoShopify is an insanely huge e-commerce platform (and a $100B company). I'd say their developers are pretty productive with Ruby on Rails.
- nitsky 6y agoYes, 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.
- monadic2 6y agoYou’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.
- adventured 6y ago> 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).
- joelbluminator 6y agoThey 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.
- joelbluminator 6y agoI 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.
- praveenperera 6y agoI 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?
- joelbluminator 6y agoThey're still mostly a Ruby monolith afaik, so you can't add new features in Go on top of that. Each company and what works for them. > They are clearly already spending a lot of resources optimizing Ruby code to match their demands. I think the work on Graal is a VERY long term investment. They can grow to become a 200B company even if none of that work succeeds. Also, I think it's just one guy Shopify is hiring to do that but I may be wrong, so definitely not a showstopper for Shopify :)
- joelbluminator 6y ago> 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.
- praveenperera 6y agoHow about Elixir/Phoenix?
- joelbluminator 6y agoAbsolutely not, Shopify is on a roll. What a crazy ass decision it would have been to rewrite things in Elixir lol.
- praveenperera 6y agoI definitely wasn't suggesting that I was replying to: >There aren't that plenty really.
- toomanybeersies 6y agoI think you can absolutely be just as productive with JS, but it's also easy to be incredibly unproductive. The problem I have with JS (both for server side and client side) is that there's usually several different packages/libraries/frameworks to achieve the same goal, and often one gets deprecated in favour of another, requiring constant updates and changes to the development and build environment. JS development is all about the flavour of the week. For example gulp/grunt/webpack, or NPM/bower/yarn. This is compounded by the lack of a standard library. Every company has its own particular build system (and configuration of that system), libraries they use, style guide, and file/folder layout. It's also very easy to abuse scoping and class mutability, with only style guides and eslint to save you. It can be a lot of work keeping a larger and older project up to date.
- pcmoney 6y agoIf 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 languages/framework. I think culture is a totally valid performance reason to pick a language. Sure there are faster languages and there are jerks everywhere but on average it seems RoR devs are on average nicer and more collaborative people relative to peers. There is a just a mindset for wanting to write in a language optimized for developer happiness that dovetails with wanting to be happy and work happily with other people. Ya sure those C++ guys can write more performant code but I know who I want to work next to 8 hrs a day. And who I will be more productive working with. Also I don't think there are plenty of languages that are Ruby/RoR peers. Django doesn't come close. JS ecosystem is a dumpster fire. Some functional and JVM languages maybe but they often come with a corporate culture that kills their benefits. Kotlin would be my bet I guess? Also if scale is your issue and rails isn't cutting it then you need to go to a proven language with a proven and hirable developer base. That rules out a lot of new and promising languages. Sure they might be just as productive languages but they are resource constrained at the people level. It is really hard to hire Elixir/Phoenix devs etc. You need a talent pool of thousands. Also you need to KNOW the language will be there with a community in 10 years and that it has a history of evolving without screwing over the community. I guess Twitter going to Scala would be an example of this, from my understanding it doesn't solve all their problems. Total aside: plenty of language need massive tuning to work at scale but it seems like Ruby is unfairly singled out if someone does "exotic" tuning of it but if someone tunes a JVM language or invent their own it is supported.
- leetrout 6y agoEdit: downvote away for disagreeing. I don’t see anyone presenting a counter argument. This has not been my experience. It has been “do it THIS way in ruby” even though either way is perfectly valid (eg list of Literal strings / symbols vs %i or %w. Lots of bike shedding type discussions on which way is better and unsurprisingly no consistency across the codebase. There’s also a lot of hidden things you can only learn from years of usage and no clear documentation of when / where features came and went. All in all every Ruby dev I’ve worked with across 4 companies have all had the same sort of elitist / pretentious attitude compared to Python, Go or Java devs. Ruby has only been second to Scala and Rust devs (so far).
- epidemian 6y agoWhy 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.
- monadic2 6y ago> 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.
- goatlover 6y ago>> 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.
- jashmatthews 6y agoWhat 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.
- monadic2 6y agoWhich tracing jit would you recommend for production work? The implication is, of course, that there isn’t a good one. This isn’t ruby the language’s fault, it’s just weird that after like 15 years being the go-to tool for VCs there’s no substantial investment in the core infrastructure. We just gotta wait for banking software to be written in it, I guess, so there’s a vested interest in it over the long term. Edit: I’d like to further note that other languages use similar features (string-keyed functions) but they aren’t typically put into high performance code/are seen as a hack around formally definitions (possible exception: common lisp, although I would expect a macro). This is inherently a readability improvement over manually defining the methods you use.
- monadic2 6y agoYou only need to be more efficient than the competition, and there’s a shared incentive to push out products faster than you can maintain existing ones. Over the long term it never makes sense to use ruby; only in the short term when it provides a marginal improvement over the competition does it pay off.