[dlisboa]

Just want to reiterate what the sibling commenter said, it's dead on with my experience.

Static typing would be the main thing teams would've been better off with. I was big on dynamic languages, love Clojure/LISPs and still work with Ruby and JS today, but you just can't trust 100 developers with it. Last company I worked for I ran the dev team and did some bug analysis: conservatively 60% of bugs were things a simple static type system would've caught.

Very few business logic bugs. We had loads of tests but these simple bugs still popped up. Someone in team A would change a method's return type, find and replace in the codebase, but miss some obscure case from team D. Rinse and repeat. Nothing complicated, just discipline but you can't trust discipline on a 500k LoC codebase and a language with no guardrails.

Performance would've been the other main advantage of static typing. While most people think their Rails app will be IO-bound forever that's really downplaying their product. In actuality every company that mildly succeeds will start to acquire CPU-bound workloads and it'll come a point where they are the bottleneck. One might argue that it is at this point you ditch Ruby but in reality no one really wants to run a polyglot company: it's hard to hire, hard to fill in gaps, hard to manage and evaluate talent.

People underestimate the impact of performance on the bottom line these days with phrases like "memory is cheap; devs are not". Like the sibling commenter put it the monthly cloud bill on that last company would've paid about 20 dev salaries. Most of that was for the app servers. That for an app that served about 500 req/sec at peak. You can imagine the unnecessary pressure that puts on the company's finances.

Better choices would've been Go, Rust, even something on the JVM.

[chucke]

Static typing has come, there's RBS, which has (finally) coalesced (after adding support for inlining in code) as the blessed type notation, supported by both steep and sorbet. Considering that big companies have adopted it, I'd say that the community agrees and has done something about it. But as you can imagine, many ruby apps have been stuck in legacy for years.

About performance, not sure how you think static typing could solve it, but considering the significant investment recently in JITs, in particular YJIT and ZJIT, again, the big apps seem to agree with you and have done something about it?

Even if you ditch CRuby for the JVM, you can still use JRuby, and still leverage the language while not being pulled down by the runtime.

It's not like you're without options.

[whstl]

Yep.

The thing about "it's IO bound anyway so who cares" is that it forces you to scale the app much earlier.

At a company I worked, a single Golang instance (there was backup) was able to handle every single request by itself during peak hours, and do authentication, partial authorization, request enrichment, fraud detection, rate limiting and routing to the appropriate microservice. I'm not saying it was a good idea to have a custom Ingress/Proxy app but it's what we had.

By contrast, the mesh of Rails applications required a few hundred machines during peak time to serve the same number of requests, and none of it was CPU-heavy. It was DB heavy!

If it had been a Golang or JVM or Rust app it would require a much smaller fleet to serve.