Choosing a backend language, choosing a culture

Somebody was talking to me about choosing a backend programming language for their startup.

I was realizing that in general, it is true that most languages offer many of the same features. But the community and tools that form around the language are the hidden factors that actually are more important.

Languages and cultures

Javascript is used primarily by front-end developers. This community is about fast delivery and rapid change, and many of the developers in this community deeply understand their customers and the user experience. You can build backend services in node.js, and many do. The advantage here is you can build both the front-end and the back-end in the same language, so this can be very tempting.

Ruby on Rails lands in a slightly similar camp. Ruby on Rails has always been popular for whipping out that first implementation, getting the funding you need and delivering value immediately. This community is focused on fast prototyping and quick database integration.

For both of these groups, however, once you move beyond a single, simple monolithic service, you run into trouble. I wish it were not so but I have seen it over and over again. They get stuff to work, but when you start scaling, things start falling over, and they generally don't have the skills or background to understand how to design and manage distributed systems. Some of them even look down on such things and say you're over-complicating things...

When you want engineers who understand distributed service design, who have grown up around design patterns and principles such as query responsibility separation, hexagonal pattern, idempotence, things like that, you're more likely to find that in the Java, Kotlin and Scala communities.

You can see Go in this space as well, but it's tricky, because now you are veering into high-performance, high-scale, no-nonsense platform communities. Rust also falls into this area. These folks understand distributed systems, no doubt about it, but often they have grown up deep in the engine, making it hum, and have neither the interest nor the patience for business domain modeling, design patterns or "thinking like the customer." Their services tend to have hundreds of clients and they have to keep the code super-clean and efficient and drive the API independent of specific consumers to maintain its scale and maintainability.

With Python you are going to find data engineers who know how to build data pipelines and perform deep data analysis, but who also generally don't have a background in distributed service design and maintenance.

My recommendations

So here's how I'd map it out:

Zero-to-one, get your app built quickly - you can definitely use Ruby on Rails or node.js.

The trick with this choice is that if and when your business scales beyond a single backend service, it is a major shift.

You will likely want to change your programming language so you can have more luck finding developers with the right type of experience. That's difficult in itself, but this most also often meets with strong resistance from your initial team.

You'll aso need to invest in training your initial team into distributed systems thinking and a new language, and some people are going to sign off rather than go on that journey.

I personally have been involved in this transition multiple times; it is not easy or fun.

These days I might try as an alternative the build-an-app-with-a-prompt AI tools. This might be a better choice than Ruby on Rails or Javascript because you can still get stuff up and running fast, but you can choose your longer-term language (and developers who are part of that culture). You'll probably still have to clean it up later, but at least you won't have to change your developer culture and your language.

The one risk here is Java or Kotlin developers are sometimes too systematic and want to do a lot of up-front design (DVC raises his hand...), when that is not necessarily what is called for when you're trying to get your first product out the door.

Domain services that model the business domain and which interact well together using well-established design patterns - I would go with Java or Kotlin.

High-scale, high-performance, bare-to-the-metal backend services - definitely Go or Rust. Java can also fit here, but sometimes at this level the size and complexity of the language, which is great for business domain services, can get in its own way. Also often the Java developer community tends to prioritize expressiveness over performance and may not have the skills to build fast fast fast services.

Solid data pipelines with all the expertise and tools for data analysis - Python is your go-to. Be careful building apps with Python, as you'll again probably need to change your language and team culture

In general, be thoughtful about your language choice. At one level, any language can work, but you may be pushing against the natural tendencies of both the tooling and the developer community for that language.