5 ms·

A better question to ask is, why are these "slow" languages winning? If performance is as important as we think it is, why don't we see startups using Rust or w

by yen223 4y ago

A better question to ask is, why are these "slow" languages winning? If performance is as important as we think it is, why don't we see startups using Rust or whatever just running circles around startups using Ruby? The answer to this will lead to what actually matters in a language, in terms of building a product. Raw performance isn't it.

clpm4j 4y ago
One plausible reason in my mind is that startups tend to hire devs on the younger side, and it seems (from my perspective in the USA) that most new-ish grads come out of school having done most of their programming in Python. Plus some Javascript if they've dabbled in web dev building hobby projects.
- hw 4y ago
  Ruby/Rails optimizes for developer productivity. Once you prove yourself as a company and your product reaches a scale where you cant just throw $$$ at the problem, you’d be in a good spot to then hire folks to start rewriting parts in $languageofchoice.
- pjmlp 4y ago
  40 years ago those newly hires would have only learned BASIC. Except at least BASIC had compilers available, and Darthmound BASIC was originally designed with what we call JIT nowadays, even if that wasn't a thing on 8 bit home computers.
nickjj 4y ago
This is something I've thought a lot about over the years too. Runtime performance is great and very much welcome if you can get it for free but for a ton of web apps it's not a major selling point on its own. If I can write 30-100% less code and be able to Google almost every single problem I encounter and find tons of high quality blog posts, documentation and videos along with having decently maintained third party libraries for common features then this is going to win every time in my book against something that doesn't have this. It doesn't matter if your web app uses 100mb of memory instead of 1gb or can serve 300 requests per second instead of 30. Most apps never come remotely near the point where this level of performance matters and Rails makes it easy enough to cache things where you can get your p95+ responses responding in 50-100ms or less without much effort. Basically Rails sets you up where a solo dev or small team can run an entire SAAS app on a single $20-40 / month server and have tens of thousands of paying customers without really having to think much about performance. Combine this with Hotwire and you can build really nice feeling sites very quickly if you're the type of person who doesn't want to build APIs + JS front-ends. On the other side of the spectrum with Shopify, GitHub and Basecamp you have engineers running Rails at massive scale making the framework better for everyone (themselves included). It's a self-fulfilling prophecy and win / win scenario because the more people that use it contribute back to the project (patches, community related things, etc.). At this point the only things that matter are fast how you can build your app and how happy are you building / maintaining it. As Ruby, Rails and compute resources get faster then frameworks who focus mainly on performance become less appealing over time for a huge class of web apps because once you reach "good enough" performance it's all about the community and mass adoption. It's like a company who pops up and tries to copy another company but adds 1 small feature to differentiate themselves. As soon as the company you copied decides to add that feature you're going to be climbing way up hill to barely survive.
erik_seaberg 4y ago
Latency matters, but nobody’s platform is unusably slow. Expressiveness matters for morale and hiring, and most of all while iterating early on. Efficiency only starts to matter when product/market fit brings enough load to push your backend budget.

by yen223 4y ago

clpm4j 4y ago

One plausible reason in my mind is that startups tend to hire devs on the younger side, and it seems (from my perspective in the USA) that most new-ish grads come out of school having done most of their programming in Python. Plus some Javascript if they've dabbled in web dev building hobby projects.

hw 4y ago
Ruby/Rails optimizes for developer productivity. Once you prove yourself as a company and your product reaches a scale where you cant just throw $$$ at the problem, you’d be in a good spot to then hire folks to start rewriting parts in $languageofchoice.
pjmlp 4y ago
40 years ago those newly hires would have only learned BASIC. Except at least BASIC had compilers available, and Darthmound BASIC was originally designed with what we call JIT nowadays, even if that wasn't a thing on 8 bit home computers.

nickjj 4y ago

This is something I've thought a lot about over the years too. Runtime performance is great and very much welcome if you can get it for free but for a ton of web apps it's not a major selling point on its own. If I can write 30-100% less code and be able to Google almost every single problem I encounter and find tons of high quality blog posts, documentation and videos along with having decently maintained third party libraries for common features then this is going to win every time in my book against something that doesn't have this. It doesn't matter if your web app uses 100mb of memory instead of 1gb or can serve 300 requests per second instead of 30. Most apps never come remotely near the point where this level of performance matters and Rails makes it easy enough to cache things where you can get your p95+ responses responding in 50-100ms or less without much effort. Basically Rails sets you up where a solo dev or small team can run an entire SAAS app on a single $20-40 / month server and have tens of thousands of paying customers without really having to think much about performance. Combine this with Hotwire and you can build really nice feeling sites very quickly if you're the type of person who doesn't want to build APIs + JS front-ends. On the other side of the spectrum with Shopify, GitHub and Basecamp you have engineers running Rails at massive scale making the framework better for everyone (themselves included). It's a self-fulfilling prophecy and win / win scenario because the more people that use it contribute back to the project (patches, community related things, etc.). At this point the only things that matter are fast how you can build your app and how happy are you building / maintaining it. As Ruby, Rails and compute resources get faster then frameworks who focus mainly on performance become less appealing over time for a huge class of web apps because once you reach "good enough" performance it's all about the community and mass adoption. It's like a company who pops up and tries to copy another company but adds 1 small feature to differentiate themselves. As soon as the company you copied decides to add that feature you're going to be climbing way up hill to barely survive.

erik_seaberg 4y ago

Latency matters, but nobody’s platform is unusably slow. Expressiveness matters for morale and hiring, and most of all while iterating early on. Efficiency only starts to matter when product/market fit brings enough load to push your backend budget.