5 ms·

I learned there that if you build a successful startup on Ruby, your infrastructure costs are going to be insanely high trying to make it scale and you'd be bet

I learned there that if you build a successful startup on Ruby, your infrastructure costs are going to be insanely high trying to make it scale and you'd be better off using a typed language with true multithreading and a solid GC.

faitswulff 4y ago
You could learn the opposite lesson as well, that if you want to create a successful startup you need a dynamic language that responds to business needs and you can put off worrying about infrastructure costs until later.
- likeabbas 4y ago
  Your argument is based on a fallacy that you can build something faster in a dynamic language than a typed one. IMO that argument fails when you need to onboard new people to read the codebase and contribute to it. I'd argue you will be able to onboard people faster to a typed codebase than a dynamic one. And for me personally, I don't see a difference in my ability to produce code between Java/Go and a dynamically typed language.
  - faitswulff 4y ago
    That's not my argument. My argument is that without more data, your original statement that "you'd be better off" is just as subjective. In fact, with data, we see rather the opposite picture: > Y Combinator, an accomplished investment fund, and startup incubator has published a list of its top 100 graduate companies ranked by valuation as of October 2019. 8 out of the 10 most valued companies in the ranking were built using Ruby on Rails. https://spreecommerce.org/ruby-on-rails-most-popular-among-top-y-combinator-companies/ https://spreecommerce.org/ruby-on-rails-most-popular-among-t... I'm not entirely convinced, but my main point is that polemic based on individual experiences is wholly subjective.
    - likeabbas 4y ago
      No it's not. You would objectively be better off in Java or Go than Ruby once you reach scale. Java and Go can truly utilize multi-core threading, and have superior garbage collectors. This matters a lot for latency requirements
    - likeabbas 4y ago
      You edited your response. How many of those companies are profitable?
      - faitswulff 4y ago
        I edited my response from "Without more data, your original statement that "you'd be better off" is just as subjective" to the more fully fleshed out comment you see now while I was looking for a link for my sources. You, on the other hand, are moving the goalposts.
        likeabbas 4y ago
        I'm not moving goal posts. I never said you could not be successful with ruby. All I'm saying is that once you hit scale, you would have an easier time cutting costs in a language that could better utilize less infrastructure and thus lowering your operating costs.
        hbrn 4y ago
        For overwhelming majority of startups hardware is a tiny fraction of their operating costs. Not to mention that a lot of the hardware costs are language-agnostic: database servers, disk volume.
        likeabbas 4y ago
        Why do people keep misreading what I'm saying. The argument is specifically for WHEN YOU REACH SCALE
  - codegeek 4y ago
    I am not GP but the argument that typed language is always better to start with has its own fallacy. What if I don't have experience with a typed language and I need to get to Product Market Fit first where most startups fail ? You need to look at it from a business perspective as well. If I only know say Ruby and I can get something up and running with it, I would use that. I wouldn't worry about Typed Language or whatever.
    - likeabbas 4y ago
      I'm not saying it's not possible to build a successful start up with the language. My argument is just that the language can become a major expense and limiting factor once you reach scale. Many programmers know multiple languages, and if they have a choice then it may be wise to opt for a language that could help you avoid some of these problems later.
      - aerhardt 4y ago
        What proof is there that companies built on dynamic typed languages struggle with server costs, payroll, or development velocity, though? Looking from the outside, all I can say is that both Github and especially Stripe have continued to churn out features and entire product lines well after they reached global scale… Regarding their economics, I’d have to see a serious study proving that that the effect in infra and server costs is not only real but also non-negligible, ie, it has a real impact on the bottom line, shareholder value, company efficiency, competitiveness, or what-have-you…
        likeabbas 4y ago
        > What proof is there that companies built on dynamic typed languages struggle with server costs The proof is in the limitations of the language. If you have a 4 CPU server and you want to run a web application, you would be able to process far more transactions per second in a Java or Go application than Ruby. This is because Ruby has a GIL which means it can't truly multithread, so to get parallelization you need to multiprocess. These days kernels can spawn threads in 5ms (or with Green threads that can be in nanoseconds), but a new process takes 50ms to spawn. Then, there's the issue of Garbage Collection pauses. Java is one of the best with some very low latency (<10ms) GCs. Ruby far from the state of the art GCs. Then there's the runtime, which Ruby can be 10-100x slower than Java or Go. It's just a matter of this logic being scaled to big levels
nahname 4y ago
Your biggest expense will be people. Rails is ancient at this point, but I regularly see people ship product with it in fractions of the time. You can also re-write parts in rust later, when you need to.
- likeabbas 4y ago
  Once you reach scale, Ruby can be a limiting factor depending on how much latency impacts your revenue. And it's not so easy to remove that dependency as I've seen.
  - darkerside 4y ago
    > Once you reach scale We should all be so lucky
  - nahname 4y ago
    Latency is important to sales and it hasn't been an issue for Shopify. In my experience, you need people that understand how to scale things more than you need a scalable language.
  - nthj 4y ago
    Rails can easily serve up pages in <100ms. If you do have an endpoint that is CPU-bound to where you can’t meet your SLA goals, you can serve up just that endpoint in Rust or Golang. But that’s rare. Usually what happens at scale is that the SQL database starts slowing down as more data is loaded in. Partitioning, indexes and painful refactorings aren’t prioritized. Engineering will champion “a faster language”—that incidentally allows them a new data model where they add in proper indexes at the start. They aren’t really incentivized to realize they could see the same gains by just improving their existing data inside the Rails monolith. Source: experience improving performance (including latency) with multi-billion-dollar Rails monoliths
    - likeabbas 4y ago
      You can’t scale Ruby to <25ms which is important for some businesses where every 10ms is millions in lost processing
sanderjd 4y ago
What are the options that fit this bill? JVM? Go? This does seem to at least rhyme with twitter's experience, and maybe also github, at least as observed from outside, where a pretty innovative initial product has difficulty progressing after a period of massive scaling. But also: Is the lesson maybe just knowing when to pivot to more efficient runtime environments? For instance, I believe facebook had a similar experience with php, and pivoted to running it on a custom vm. Did stripe wait too long to do that kind of pivot? Or perhaps you were just there in the middle of it, which is bound to be a messy time.
- roncesvalles 4y ago
  Go is pretty much a better-in-every-way replacement to that entire cluster of developer-friendly languages like Ruby, Python, Node.js etc. A startup in 2023 would need to have pretty good reasons to not start in Go.
  - likeabbas 4y ago
    Agreed. Although I like Rust and modern Java too.
  - sanderjd 4y ago
    Humorously I was just in a conversation within "a startup in 2023" about how Go is not working all that well. Of course opinions vary, but I thought it was an interesting counterpoint to your comment. For my part, my intuition is that my last project, in java, seemed to be more productive than the current project in go, and another current project, in python, also seems to be working better. But there are so many variables, it's impossible to untangle causality.
    - roncesvalles 4y ago
      What criticisms did they have?
      - sanderjd 4y ago
fsociety 4y ago
This ignores internal efforts to speed-up Ruby and make it concurrency safe. Facebook took this method and did well with it. Hack is typed, and its perf is fast. Shockingly fast.
mattbrewsbytes 4y ago
Rewriting a huge software base from one language to any other is going to cost a lot more than throwing money at scaling infrastructure. If performance is actually a customer observable pain point, a company would be better off investing in performance tuning their own software as well as investing in people to work on Ruby itself. Engineers love to pull out the "it doesn't scale" card with alternative language suggestions that usually align with whatever pet/fad language they've been playing with because its new and shiny (I accuse myself here as well). At some point a business is successful enough, like Stripe, where the risk of changing out an entire tech stack outweighs any perceived benefit.
- auntienomen 4y ago
  Stripe already invested in performance tuning and people to improve Ruby. Ya gotta give people some credit for thinking of the first most obvious thing.

faitswulff 4y ago

You could learn the opposite lesson as well, that if you want to create a successful startup you need a dynamic language that responds to business needs and you can put off worrying about infrastructure costs until later.

likeabbas 4y ago
Your argument is based on a fallacy that you can build something faster in a dynamic language than a typed one. IMO that argument fails when you need to onboard new people to read the codebase and contribute to it. I'd argue you will be able to onboard people faster to a typed codebase than a dynamic one. And for me personally, I don't see a difference in my ability to produce code between Java/Go and a dynamically typed language.
- faitswulff 4y ago
  That's not my argument. My argument is that without more data, your original statement that "you'd be better off" is just as subjective. In fact, with data, we see rather the opposite picture: > Y Combinator, an accomplished investment fund, and startup incubator has published a list of its top 100 graduate companies ranked by valuation as of October 2019. 8 out of the 10 most valued companies in the ranking were built using Ruby on Rails. https://spreecommerce.org/ruby-on-rails-most-popular-among-top-y-combinator-companies/ https://spreecommerce.org/ruby-on-rails-most-popular-among-t... I'm not entirely convinced, but my main point is that polemic based on individual experiences is wholly subjective.
  - likeabbas 4y ago
    No it's not. You would objectively be better off in Java or Go than Ruby once you reach scale. Java and Go can truly utilize multi-core threading, and have superior garbage collectors. This matters a lot for latency requirements
  - likeabbas 4y ago
    You edited your response. How many of those companies are profitable?
    - faitswulff 4y ago
      I edited my response from "Without more data, your original statement that "you'd be better off" is just as subjective" to the more fully fleshed out comment you see now while I was looking for a link for my sources. You, on the other hand, are moving the goalposts.
      - likeabbas 4y ago
        I'm not moving goal posts. I never said you could not be successful with ruby. All I'm saying is that once you hit scale, you would have an easier time cutting costs in a language that could better utilize less infrastructure and thus lowering your operating costs.
        hbrn 4y ago
        For overwhelming majority of startups hardware is a tiny fraction of their operating costs. Not to mention that a lot of the hardware costs are language-agnostic: database servers, disk volume.
        likeabbas 4y ago
        Why do people keep misreading what I'm saying. The argument is specifically for WHEN YOU REACH SCALE
- codegeek 4y ago
  I am not GP but the argument that typed language is always better to start with has its own fallacy. What if I don't have experience with a typed language and I need to get to Product Market Fit first where most startups fail ? You need to look at it from a business perspective as well. If I only know say Ruby and I can get something up and running with it, I would use that. I wouldn't worry about Typed Language or whatever.
  - likeabbas 4y ago
    I'm not saying it's not possible to build a successful start up with the language. My argument is just that the language can become a major expense and limiting factor once you reach scale. Many programmers know multiple languages, and if they have a choice then it may be wise to opt for a language that could help you avoid some of these problems later.
    - aerhardt 4y ago
      What proof is there that companies built on dynamic typed languages struggle with server costs, payroll, or development velocity, though? Looking from the outside, all I can say is that both Github and especially Stripe have continued to churn out features and entire product lines well after they reached global scale… Regarding their economics, I’d have to see a serious study proving that that the effect in infra and server costs is not only real but also non-negligible, ie, it has a real impact on the bottom line, shareholder value, company efficiency, competitiveness, or what-have-you…
      - likeabbas 4y ago
        > What proof is there that companies built on dynamic typed languages struggle with server costs The proof is in the limitations of the language. If you have a 4 CPU server and you want to run a web application, you would be able to process far more transactions per second in a Java or Go application than Ruby. This is because Ruby has a GIL which means it can't truly multithread, so to get parallelization you need to multiprocess. These days kernels can spawn threads in 5ms (or with Green threads that can be in nanoseconds), but a new process takes 50ms to spawn. Then, there's the issue of Garbage Collection pauses. Java is one of the best with some very low latency (<10ms) GCs. Ruby far from the state of the art GCs. Then there's the runtime, which Ruby can be 10-100x slower than Java or Go. It's just a matter of this logic being scaled to big levels

nahname 4y ago

Your biggest expense will be people. Rails is ancient at this point, but I regularly see people ship product with it in fractions of the time. You can also re-write parts in rust later, when you need to.

likeabbas 4y ago
Once you reach scale, Ruby can be a limiting factor depending on how much latency impacts your revenue. And it's not so easy to remove that dependency as I've seen.
- darkerside 4y ago
  > Once you reach scale We should all be so lucky
- nahname 4y ago
  Latency is important to sales and it hasn't been an issue for Shopify. In my experience, you need people that understand how to scale things more than you need a scalable language.
- nthj 4y ago
  Rails can easily serve up pages in <100ms. If you do have an endpoint that is CPU-bound to where you can’t meet your SLA goals, you can serve up just that endpoint in Rust or Golang. But that’s rare. Usually what happens at scale is that the SQL database starts slowing down as more data is loaded in. Partitioning, indexes and painful refactorings aren’t prioritized. Engineering will champion “a faster language”—that incidentally allows them a new data model where they add in proper indexes at the start. They aren’t really incentivized to realize they could see the same gains by just improving their existing data inside the Rails monolith. Source: experience improving performance (including latency) with multi-billion-dollar Rails monoliths
  - likeabbas 4y ago
    You can’t scale Ruby to <25ms which is important for some businesses where every 10ms is millions in lost processing

sanderjd 4y ago

What are the options that fit this bill? JVM? Go? This does seem to at least rhyme with twitter's experience, and maybe also github, at least as observed from outside, where a pretty innovative initial product has difficulty progressing after a period of massive scaling. But also: Is the lesson maybe just knowing when to pivot to more efficient runtime environments? For instance, I believe facebook had a similar experience with php, and pivoted to running it on a custom vm. Did stripe wait too long to do that kind of pivot? Or perhaps you were just there in the middle of it, which is bound to be a messy time.

roncesvalles 4y ago
Go is pretty much a better-in-every-way replacement to that entire cluster of developer-friendly languages like Ruby, Python, Node.js etc. A startup in 2023 would need to have pretty good reasons to not start in Go.
- likeabbas 4y ago
  Agreed. Although I like Rust and modern Java too.
- sanderjd 4y ago
  Humorously I was just in a conversation within "a startup in 2023" about how Go is not working all that well. Of course opinions vary, but I thought it was an interesting counterpoint to your comment. For my part, my intuition is that my last project, in java, seemed to be more productive than the current project in go, and another current project, in python, also seems to be working better. But there are so many variables, it's impossible to untangle causality.
  - roncesvalles 4y ago
    What criticisms did they have?
    - sanderjd 4y ago

fsociety 4y ago

This ignores internal efforts to speed-up Ruby and make it concurrency safe. Facebook took this method and did well with it. Hack is typed, and its perf is fast. Shockingly fast.

mattbrewsbytes 4y ago

Rewriting a huge software base from one language to any other is going to cost a lot more than throwing money at scaling infrastructure. If performance is actually a customer observable pain point, a company would be better off investing in performance tuning their own software as well as investing in people to work on Ruby itself. Engineers love to pull out the "it doesn't scale" card with alternative language suggestions that usually align with whatever pet/fad language they've been playing with because its new and shiny (I accuse myself here as well). At some point a business is successful enough, like Stripe, where the risk of changing out an entire tech stack outweighs any perceived benefit.

auntienomen 4y ago
Stripe already invested in performance tuning and people to improve Ruby. Ya gotta give people some credit for thinking of the first most obvious thing.