3 ms·

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

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
- dalyons 4y ago
  I work at a company that does ruby “at scale” too (10mil b2c users). Yes we need more web instances than we would have in go(or whatever). No, it doesn’t really matter at all - web process compute is a tiny fraction of our AWS bill, and a meaninglessly tiny % of overall op-ex. We’re talking sub sub 1%. It doesn’t matter, really. Of course if we had a few billion users , diff story, but approximately no one does.

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
dalyons 4y ago
I work at a company that does ruby “at scale” too (10mil b2c users). Yes we need more web instances than we would have in go(or whatever). No, it doesn’t really matter at all - web process compute is a tiny fraction of our AWS bill, and a meaninglessly tiny % of overall op-ex. We’re talking sub sub 1%. It doesn’t matter, really. Of course if we had a few billion users , diff story, but approximately no one does.