If you want to scale, the question is more about what languages not to use.

Don't use Ruby, especially Rails. Ruby on Rails in particular is so slow that handling the full load can cost 100x as much. For instance, it could mean the difference between $50,000/month of server costs vs. $500/month.

Don't use any language that doesn't support static types. Static types are important to help you manage complexity in any system. [1]

Beyond that, you could choose TypeScript+Node.js, Go, Java, or even C++. There are other options but those are the most popular, and popularity is important if you want to have an easy time finding people who can work on your service.

Go and Node.js (with TypeScript) are probably the most productive environments in that list. Translation: The code will be done faster if you have a competent developer who uses a productive language.

The real question is whether you mean 100M concurrent users, or 100M occasional users, with only a thousand on at the same time?

A skilled developer using any of the above languages could write a server that would handle a few thousand concurrent users for next to nothing, and with no special scaling infrastructure (beyond using managed databases, for instance Amazon DynamoDB or RDS).

If you're looking at 100M concurrent users, then it depends a lot on the exact needs of your app. Contrary to what other people might claim, you can't just expect any language or design to be scalable by just “throwing more hardware at the problem.” Aside from the potentially extreme costs, the increased contention of shared databases may actually bog your service down to a crawl if the design isn't right.

And that's key. You need someone experienced with optimization and server architectural design so that you don't end up with a scaling disaster.

I'm working on a system right now where the scaling goal is 10M concurrent users. The client (who will remain nameless) has previously sold a business for $50M+, and they've already purchased a very expensive domain name for this project, so they have the resources to actually acquire that many users. When I started, there were already performance problems with a half dozen users. Now it's faster and can handle a few thousand, but I already have plans in place to enable scaling out to 10M.

And more than the “right” language, you need the right plan. You can't pick your development team just based on the language. What you need is a world class architect who can guide the project.

If you don't believe me, just look at the range of framework performance benchmarks.[2] In some cases there is a range of over 10,000x performance variation between two frameworks, even when both frameworks are using C++. That's a difference between $100/month and $1M/month in server costs, even though both servers are using the fastest language around.

Picking the right language guarantees nothing. Picking the right architect is far more important.

This article was originally published at Quora.

Image Credit: Gerd Altmann from Pixabay.

Footnote: https://coderescue.com