6 ms·

> Is it "slow" enough to matter? Probably not until you get to a medium scale. Phew, I'm glad GitHub and Shopify's scale is still small.

ryansouza 6y ago
I guarantee the tradeoffs matter to them
- sosodev 6y ago
  I’ve seen videos on Twitter of the Shopify CEO saying that Ruby’s performance literally doesn’t matter to them. That it’s easy enough to scale it horizontally and the benefits outweigh the cost.
  - joshmn 6y ago
    Probably helps that Tobias also codes, not to mention contributed to Rails quite a bit.
todotask 6y ago
I recall Shopify hired a dev who works on a project, FaastRuby, written in Crystal language for their web app.
dijit 6y ago
Pedantry aside, we've reached a point in our industry where we can do a lot with horizontal scalability. I mean, every programmer who funnels through university understands map reduce, and that helps on multi-core threading up to system job running. But there is a limit, usually in the persistence and caching layers. What you'll find is that those "large scale deployments" are going to have a -lot- of internal cache systems and I can pretty much guarantee that the services running those caches and persistence will not be written in ruby. You can make anything* scale, but how many CPU cycles you need to burn to get the functionality you want is a matter for the finance department. If you're running in a lossy business, you can bet that those CPU cycles will begin to cost more than developer velocity is worth, because servers are an eternal and ongoing cost. On the flip side if you make more money than the infra+devs cost, then nobody is going to hound you for wasting 2x 3x the cost. Because "it's the cost of doing business" is easier to justify when you're cash positive.
- joelbluminator 6y ago
  > services running those caches and persistence will not be written in ruby So what? What's wrong with using software like redis for cache, for a very small (but important) part of your business? I bet java apps use redis as well, and redis isn't written in java. So?
  - pdimitar 6y ago
    Is this an honest question? I honestly can't tell and I am not saying it to show disrespect -- just wondering if you are sarcastic. Erlang/Elixir have built-in caches that respond in the matter of 30-150 nanoseconds. Why would you need an external service for that? It's adding complexity -- and likely hosting costs. Isn't it self-evident to you that adding Redis as a caching layer to your stack is a bandaid to a deeper problem?
    - ronjouch 6y ago
      Interesting but not surprising; I'm being regularly pleasantly surprised by the Erlang/Elixir ecosystem :) . Can you precise what you're talking about when you say "Erlang/Elixir have built-in caches" ? What's the name of the concept and where in the typical stack does it fit? Is this https://blog.appsignal.com/2019/11/12/caching-with-elixir-and-ets.html https://blog.appsignal.com/2019/11/12/caching-with-elixir-an... or something else? Care to share a few link to docs/articles? Thanks.
      - pdimitar 6y ago
        Yes, ETS is the usual go-to but there's also `:persistent_term`[0] for very rare (or never) changing caches. There are libraries that combine Erlang/Elixir's caching mechanisms in an attempt to achieve the best performance for most scenarios[1] as well. Technically, ETS is not perfect because it copies data from its mutable cache to the process that requests it. But it's still orders of magnitude faster than outsourcing that to Redis. [0] http://erlang.org/doc/man/persistent_term.html http://erlang.org/doc/man/persistent_term.html [1] https://github.com/gyson/ane https://github.com/gyson/ane
Thaxll 6y ago
Shopify is actually replacing slow ruby code with Go. And yes they ACK that Ruby is too slow. Also Shopify is a big monolith so it does not help.
- ch4s3 6y ago
  A monolith doesn't necessarily mean slower, even with Ruby. There are lots of opportunities to run less code on each request, do some work with the db, and to split off measure bottlenecks into services in a faster language. It's often good to build things quickly, find fit, and then carefully measure before you introduce calls over the network.
  - Thaxll 6y ago
    A monolith is a problem which they are also breaking down, when you want to make something faster it's easier to target the service that does it vs the giant app. Edit: getting downvoted by people that don't work at Shopify.
    - byroot 6y ago
      I work at Shopify. I can confirm that what you are saying is totally false.
- tekstar 6y ago
  Lol none of these statements are true
pdimitar 6y ago
> Phew, I'm glad GitHub and Shopify's scale is still small. Phew, good thing they can afford to burn a lot of cash for hosting.
- tim333 6y ago
  I guess that's so though it's interesting in the early days Github didn't: >...a web startup like ours doesn’t need any outside money to succeed. I know this because we haven’t taken a single dime from investors. We bootstrapped the company on a few thousand dollars and became profitable the day we opened to the public and started charging for subscriptions. Tom Preston-Werner in 2008. I guess the thing is not how much the hosting costs in absolute terms but how much it costs relative to what customers are prepared to pay for the service.
  - pdimitar 6y ago
    Once a business grows to certain size and beyond the shareholders don't want to hear anything about tech rewrites. They are happy the product is working, they are not alarmed by slow response times (which GitHub has plenty of on my gigabit connection that streams 4k@30fps without any lag) unless there's a big customer churn, and hosting costs, even if big-ish, to them are just the cost of doing business. My point is, yes, you are right -- but there's a lot of conservatism involved once the business gets to a certain size. Nobody cares about improving anything from then on (which usually leads to the now-giant to start steadily losing relevance; GitHub is quite far from that but we all remember Microsoft, right?).

ryansouza 6y ago

I guarantee the tradeoffs matter to them

sosodev 6y ago
I’ve seen videos on Twitter of the Shopify CEO saying that Ruby’s performance literally doesn’t matter to them. That it’s easy enough to scale it horizontally and the benefits outweigh the cost.
- joshmn 6y ago
  Probably helps that Tobias also codes, not to mention contributed to Rails quite a bit.

todotask 6y ago

I recall Shopify hired a dev who works on a project, FaastRuby, written in Crystal language for their web app.

dijit 6y ago

Pedantry aside, we've reached a point in our industry where we can do a lot with horizontal scalability. I mean, every programmer who funnels through university understands map reduce, and that helps on multi-core threading up to system job running. But there is a limit, usually in the persistence and caching layers. What you'll find is that those "large scale deployments" are going to have a -lot- of internal cache systems and I can pretty much guarantee that the services running those caches and persistence will not be written in ruby. You can make anything* scale, but how many CPU cycles you need to burn to get the functionality you want is a matter for the finance department. If you're running in a lossy business, you can bet that those CPU cycles will begin to cost more than developer velocity is worth, because servers are an eternal and ongoing cost. On the flip side if you make more money than the infra+devs cost, then nobody is going to hound you for wasting 2x 3x the cost. Because "it's the cost of doing business" is easier to justify when you're cash positive.

joelbluminator 6y ago
> services running those caches and persistence will not be written in ruby So what? What's wrong with using software like redis for cache, for a very small (but important) part of your business? I bet java apps use redis as well, and redis isn't written in java. So?
- pdimitar 6y ago
  Is this an honest question? I honestly can't tell and I am not saying it to show disrespect -- just wondering if you are sarcastic. Erlang/Elixir have built-in caches that respond in the matter of 30-150 nanoseconds. Why would you need an external service for that? It's adding complexity -- and likely hosting costs. Isn't it self-evident to you that adding Redis as a caching layer to your stack is a bandaid to a deeper problem?
  - ronjouch 6y ago
    Interesting but not surprising; I'm being regularly pleasantly surprised by the Erlang/Elixir ecosystem :) . Can you precise what you're talking about when you say "Erlang/Elixir have built-in caches" ? What's the name of the concept and where in the typical stack does it fit? Is this https://blog.appsignal.com/2019/11/12/caching-with-elixir-and-ets.html https://blog.appsignal.com/2019/11/12/caching-with-elixir-an... or something else? Care to share a few link to docs/articles? Thanks.
    - pdimitar 6y ago
      Yes, ETS is the usual go-to but there's also `:persistent_term`[0] for very rare (or never) changing caches. There are libraries that combine Erlang/Elixir's caching mechanisms in an attempt to achieve the best performance for most scenarios[1] as well. Technically, ETS is not perfect because it copies data from its mutable cache to the process that requests it. But it's still orders of magnitude faster than outsourcing that to Redis. [0] http://erlang.org/doc/man/persistent_term.html http://erlang.org/doc/man/persistent_term.html [1] https://github.com/gyson/ane https://github.com/gyson/ane

Thaxll 6y ago

Shopify is actually replacing slow ruby code with Go. And yes they ACK that Ruby is too slow. Also Shopify is a big monolith so it does not help.

ch4s3 6y ago
A monolith doesn't necessarily mean slower, even with Ruby. There are lots of opportunities to run less code on each request, do some work with the db, and to split off measure bottlenecks into services in a faster language. It's often good to build things quickly, find fit, and then carefully measure before you introduce calls over the network.
- Thaxll 6y ago
  A monolith is a problem which they are also breaking down, when you want to make something faster it's easier to target the service that does it vs the giant app. Edit: getting downvoted by people that don't work at Shopify.
  - byroot 6y ago
    I work at Shopify. I can confirm that what you are saying is totally false.
tekstar 6y ago
Lol none of these statements are true

pdimitar 6y ago

> Phew, I'm glad GitHub and Shopify's scale is still small. Phew, good thing they can afford to burn a lot of cash for hosting.

tim333 6y ago
I guess that's so though it's interesting in the early days Github didn't: >...a web startup like ours doesn’t need any outside money to succeed. I know this because we haven’t taken a single dime from investors. We bootstrapped the company on a few thousand dollars and became profitable the day we opened to the public and started charging for subscriptions. Tom Preston-Werner in 2008. I guess the thing is not how much the hosting costs in absolute terms but how much it costs relative to what customers are prepared to pay for the service.
- pdimitar 6y ago
  Once a business grows to certain size and beyond the shareholders don't want to hear anything about tech rewrites. They are happy the product is working, they are not alarmed by slow response times (which GitHub has plenty of on my gigabit connection that streams 4k@30fps without any lag) unless there's a big customer churn, and hosting costs, even if big-ish, to them are just the cost of doing business. My point is, yes, you are right -- but there's a lot of conservatism involved once the business gets to a certain size. Nobody cares about improving anything from then on (which usually leads to the now-giant to start steadily losing relevance; GitHub is quite far from that but we all remember Microsoft, right?).