If Shopify, Github, or Gitlab wrote their code in golang or rust, would they need less CPU and memory? Would they have less bugs? Are refactors fast? How has RoR's ever changing JS ecosystem impacted these organizations?
- Lyft is built in Python (which IMHO, is comparable to ruby).
Who out computed who?
- WooCommerce is written in PHP.
- Shopify is written in Ruby.
Who has more customers? hint: [0]
I do not think programming languages define a company's success.
[0] - https://6sense.com/tech/ecommerce-platform/woocommerce-vs-sh...
Just curious.
We also got 98~100 lighthouse by using pure JS with sprinkles of stimulus after the initial rendering.
2x8gb elasticsearch 1x512mb redis 1xRDS mysql 16gb
low thousands/year of cloudflare enterprise
half of the budget (personnel+infra) than the next competitor in the niche I worked
It's not a ruby thing, it's just that servers are beast nowadays, and cheap.
And devs are more expensive than ever.
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.
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.
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.
As much as I think RoRs initial love for coffee script was a mistake (although it certainly did help at a time when javascript was in a horrible, braindead place) - I'm not sure I'd like the js mess at Rails' feet.
I think that the team navigated js integration as well as could be expected - and everyone was happy in version 7 when js support in browsers had advanced to the point that most of the special handling could simply be ripped out.
The remaining issue IMNHO is that there's no browser support for typescript - and using ts dictates a build pipeline which would otherwise be needless complexity with modern js and js modules.
was?
The only thing that could have saved (maybe) is better tooling but the community had no interest in it (who knows why). Rust feels like this too.
I think the initial version was a moderate enhancement on js, fixing some things like global scope etc?
IMO when you work with it properly it's so little of an issue (especially compared to the Dev time saved) that most Rails Devs simply don't care about the 'ruby doesn't scale' talk
Add Twitter to the list. They started with Rails, then switched to something else. Too many background jobs, Ruby is not ideal for that. However they became Twitter and owned that space before having to switch so Rails didn't harm them too.