3 ms·

Doesn't matter. Whether you use Python, JS, PHP or Ruby, you will need to reach millions of users before perfs become a problem for a typical web app because th

Doesn't matter. Whether you use Python, JS, PHP or Ruby, you will need to reach millions of users before perfs become a problem for a typical web app because the hot path are almost never coded in the language. It's not a ruby thing, it's just that servers are beast nowadays, and cheap. And devs are more expensive than ever.

andrewstuart 3y ago
You seem to be saying that bad performance doesn’t matter? I disagree….. see the other comment here who talks about moving to Golang. Only today I rewrote a Python application in Golang and the result was dramatically more responsive. Performance matters. Servers cost alot of money. You want to maximize that resource.
- vidarh 3y ago
  Servers cost, but server cost in absolute terms hit few people before you're big enough that the cost of capital to address it is far lower. And almost any money you invest in trying to minimise server costs at an early stage will end up going out the window because the features you end up needing at scale and that end up costing money to scale will tend to look entirely different from what you started with. So even if you need to switch languages down the line, I'd argue you should pick your initial tools based on what lets you iterate fastest early on, not based on what will keep your server costs down the line. Assuming of course what you pick is fast enough for whatever you want to do. Put in more concrete terms, based on the actual VC deals I've been on one or the other side of the table for, the cost of capital drops to anything from 1/2 to 1/10 per early round if you're doing well. If you do well enough that your server cost is becoming a problem, by the time you need to address it paying to address it ought to not be a problem unless your decisions were truly pathological. Most companies don't survive long enough for this to become a problem. In other words, while performance matters, the value of performance now to an early stage startup is often really low compared to speed of delivery that might improve your odds of actually surviving to a point where performance becomes a problem, and you might easily be willing to trade 2x, 5x, even 10x the total dev cost in cash to deliver faster if you can defer a significant portion of that cost a few years down the line assuming you survive that long and your cost of capital in terms of proportion of equity is a tiny proportion of what it is at the start. This is not an argument for Rails, btw. This is an argument for whichever tool is fastest for YOU and YOUR team to deliver with. If you have multiple alternatives you're equally productive with and one of them is more performant than others, of course pick that one.
- BiteCode_dev 3y ago
  This debate has been going in circle over and over. It's the same arguments than 10 years ago, and the answers are the same. No it's not saying bad performance doesn't matter. Yes Go can make application more responsible. But you have to balance out a lot of compromises in a project, and Pareto tend to favor those languages in the majority of situations because of cost, skills, resources and constraints. etc.

andrewstuart 3y ago

You seem to be saying that bad performance doesn’t matter? I disagree….. see the other comment here who talks about moving to Golang. Only today I rewrote a Python application in Golang and the result was dramatically more responsive. Performance matters. Servers cost alot of money. You want to maximize that resource.

vidarh 3y ago
Servers cost, but server cost in absolute terms hit few people before you're big enough that the cost of capital to address it is far lower. And almost any money you invest in trying to minimise server costs at an early stage will end up going out the window because the features you end up needing at scale and that end up costing money to scale will tend to look entirely different from what you started with. So even if you need to switch languages down the line, I'd argue you should pick your initial tools based on what lets you iterate fastest early on, not based on what will keep your server costs down the line. Assuming of course what you pick is fast enough for whatever you want to do. Put in more concrete terms, based on the actual VC deals I've been on one or the other side of the table for, the cost of capital drops to anything from 1/2 to 1/10 per early round if you're doing well. If you do well enough that your server cost is becoming a problem, by the time you need to address it paying to address it ought to not be a problem unless your decisions were truly pathological. Most companies don't survive long enough for this to become a problem. In other words, while performance matters, the value of performance now to an early stage startup is often really low compared to speed of delivery that might improve your odds of actually surviving to a point where performance becomes a problem, and you might easily be willing to trade 2x, 5x, even 10x the total dev cost in cash to deliver faster if you can defer a significant portion of that cost a few years down the line assuming you survive that long and your cost of capital in terms of proportion of equity is a tiny proportion of what it is at the start. This is not an argument for Rails, btw. This is an argument for whichever tool is fastest for YOU and YOUR team to deliver with. If you have multiple alternatives you're equally productive with and one of them is more performant than others, of course pick that one.
BiteCode_dev 3y ago
This debate has been going in circle over and over. It's the same arguments than 10 years ago, and the answers are the same. No it's not saying bad performance doesn't matter. Yes Go can make application more responsible. But you have to balance out a lot of compromises in a project, and Pareto tend to favor those languages in the majority of situations because of cost, skills, resources and constraints. etc.