I would be curious to hear what someone who’s written both go and Ruby with a type system (forget what it’s called) is.
My view from the outside is that while Rubyists have correctly figured out that being strongly typed is an advantage, it’s an awkward retrofit, and just starting with a language that has a native type system would be better.
To your point, the calculation as a N-thousand person profitable company is very different from what those companies would pick today were they starting from scratch.
I worked on Ruby code at Stripe using Sorbet and currently work in a Go code base full time now!
Sorbet is pretty incredible and IMO was a huge benefit in a massive code base. Not having to worry about nil checks and always knowing the shape of the input data to functions was immensely valuable. It made data transformations really easy.
I'm also a big fan of sum types which is available in Sorbet. It made expressing failure conditions with data really easy to do, and obvious to users of your code. This wasn't a pattern used everywhere though which is understandable given that it came much later in the Stripe code base.
Go is actually a pretty nice language. It really is easy to pick up and be pleasantly productive in it. The built in libraries are extremely good, and the eco-system seems to favor using as many of the standards where possible (e.g. http middlewares all use the same patterns, no matter which framework you choose).
I really dislike error handling in Go though. It's hard to actually know what errors you're receiving from functions you're calling, especially as they trickle their way up. For instance, if you're wanting to display certain error types to your users, you have to hope you've enumerated all of the potential errors returned and handle them in a janky manner (errors.Is / errors.As).
I also really dislike that lots of things can be nil, and the compiler won't really help you there. You just have to know that some things are interfaces vs others being structs.
The way interfaces are defined and used in Go are quite nice and it ends up being really easy to refactor something slightly to make it easier to test.
edit: summary, I think I would agree with you that starting with Go is likely the better option for many types of backend services. Ruby on Rails is still really hard to beat for productive web oriented services though, and I think you could do pretty well mixing the two together.
My view from the outside is that while Rubyists have correctly figured out that being strongly typed is an advantage, it’s an awkward retrofit, and just starting with a language that has a native type system would be better.
To your point, the calculation as a N-thousand person profitable company is very different from what those companies would pick today were they starting from scratch.