Must be recent decision. I was at Stripe last year. They have a ton of Ruby. They were full throttle investing in Ruby.
And yes, Sorbet is magical. They’ve taken good ideas from typesystems such as Typescript including the tooling for code completion, inference and refactoring.
Sorbet truly brought joy to my lift.
Although Ruby is way too dynamic for my liking. Many ways you can shoot yourself with it.
I upvoted you only to get attention. You will need reference for this.
>But nearly all of Stripe’s codebase is implemented in Ruby running on the default Ruby VM (YARV). Not only did we not need Java VM-level interoperability, choosing either alternative Ruby implementation would have made for a difficult migration path.
Not at Stripe, but I guess it was picked as a compromise between efficiency and developer productivity. Dynamic languages like Ruby and Python don't perform well in the first area, native languages like C++ not much in the latter. Rust might be better, but it's still harder to learn than Java and there's less experienced developers to hire. That tradeoff usually leads companies to pick one of Java, C# or Go.
In my experience it's usually JVM at these companies, not specifically Java, and certainly in recent years more and more teams use Kotlin for backend services.
Maybe Java includes the possibility to use Kotlin? At many teams I know its up to the team to write parts of Java libraries or services within Kotlin since it's mostly an implementation detail. But again - I'm not part of Stripe so I can't talk for them.
Must be recent decision. I was at Stripe last year. They have a ton of Ruby. They were full throttle investing in Ruby.
And yes, Sorbet is magical. They’ve taken good ideas from typesystems such as Typescript including the tooling for code completion, inference and refactoring.
Sorbet truly brought joy to my lift.
Although Ruby is way too dynamic for my liking. Many ways you can shoot yourself with it.
I upvoted you only to get attention. You will need reference for this.
>But nearly all of Stripe’s codebase is implemented in Ruby running on the default Ruby VM (YARV). Not only did we not need Java VM-level interoperability, choosing either alternative Ruby implementation would have made for a difficult migration path.
https://sorbet.org/blog/2021/07/30/open-sourcing-sorbet-comp...
How/why did you land on Java for all new services?
Not at Stripe, but I guess it was picked as a compromise between efficiency and developer productivity. Dynamic languages like Ruby and Python don't perform well in the first area, native languages like C++ not much in the latter. Rust might be better, but it's still harder to learn than Java and there's less experienced developers to hire. That tradeoff usually leads companies to pick one of Java, C# or Go.
Why not Kotlin as it's arguably closer to Ruby?
Yeah, I would be interested in the logic here. I'd assume Kotlin to be a far more productive language for ex-rubyists than Java.
Perhaps it's that they don't believe in the future of Kotlin outside of mobile?
In my experience it's usually JVM at these companies, not specifically Java, and certainly in recent years more and more teams use Kotlin for backend services.
Maybe Java includes the possibility to use Kotlin? At many teams I know its up to the team to write parts of Java libraries or services within Kotlin since it's mostly an implementation detail. But again - I'm not part of Stripe so I can't talk for them.
Is there any source for that? Their public github profile shows that Go is their most preferred language these days.