4 ms·

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

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
        faitswulff 4y ago
        Probably because your original comment doesn't say anything about scale and instead says specifically "you'd be better off," which implies "better off from the start." I'm not saying that's what you said, but that's what it reads as.
        likeabbas 4y ago
        I guess "successful startup" doesn't equate to "scale" ?
        faitswulff 4y ago
        No, it doesn't. A successful startup can have a few large customers and millions of dollars in revenue.
        hbrn 4y ago
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

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
        faitswulff 4y ago
        Probably because your original comment doesn't say anything about scale and instead says specifically "you'd be better off," which implies "better off from the start." I'm not saying that's what you said, but that's what it reads as.
        likeabbas 4y ago
        I guess "successful startup" doesn't equate to "scale" ?
        faitswulff 4y ago
        No, it doesn't. A successful startup can have a few large customers and millions of dollars in revenue.
        hbrn 4y ago

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