Questions To Ask When Choosing a Programming Language

This week I had a discussion with one of my friends on how to choose a programming language. It was triggered by multiple discussions I had with our customers on their engineering strategy in the last six months and one question that came multiple times was should we use X programming language for our new initiatives. Some customers were thinking of moving from .NET stack to Java, some banks were thinking about moving to Golang because their technical leaders have watched Monzo talks on Golang, for some it was from Java to Kotlin, and some were thinking of dumping JavaScript for Typescript.

To come up with the answer I try to find answers to following questions in context of the organization:

• What is the maturity of the programming language with respect to its community and ecosystem? Should they spend their one innovation token on this language?
• How easy it is to find available talent in the market for that programming language? 
• How easy it is for the organization to acquire production engineering know-how for a programming language?
• What are the productivity and efficiency gains that can be achieved from using a programming language? Are those gains aligned with the organization goals?
• What are the use-cases an organization wants to solve with the programming language?
• What is the future of a programming language? For a big enterprise it is important if the language can last for a decade.
• What is the learning curve of the programming language? Can existing staff be upskilled?

There is no correct answer to these questions. Most engineering organizations will end up using multiple programming languages. For example an organization may choose Golang as a general purpose language to build backend services, Python for scripting and data related work, Typescript for building web frontend. It is also possible that an engineering organization might choose Python for building most services and for few where performance and efficiency is important it chooses Golang. I think the important point is defining a small list of programming languages for the organization and documenting when you will choose which programming language. 

I use a decision matrix like the one shown below to come up with one possible answer. Depending on which factors are important to the organization they can give them weights and that will impact the score of the language. In the image shown below, language 1 is the winner.

As I was writing this post a few more questions came to my mind. 

• Does a programming language help us write less buggy software?
• Does a programming language have some constructs that help us reduce the essential complexity of the system?
• What constraints does a programming language impose and how do they impact the business goals?
• Can a programming language be a competitive advantage for an organization?
• Can a programming language influence the quality of the development team, the quality of code, and practices they follow?
• Does a programming language influence engineering organization culture?
• Can a programming language over time help average Joe become a good software engineer?
• What makes a programming language future safe? Can we predict it to safeguard us?
• Should a language choice depend on NFRs that you want to achieve?
• How does a programming language influence behavior of a team?
• Does a programming language influence product design?
  • I read a post on composability in which author made the point that success of Roam Research could be attributed to its composable design. Roam Research is built using Clojure programming language. Clojure is a functional programming language and one of the characteristics of a functional language is that they enable you to write composable programs.

I don’t have answers to all of the above mentioned questions. I am hoping there is academic research done on the above but I am yet to read those papers.

I recommend that you also watch a talk by Bryan Cantrill where he talks about values of programming languages. The values we are talking about here are compatibility, interoperability, simplicity, resiliency, performance, testability, etc. He talks about values languages like C, C++ Scala, Awk, K consider important. These values help their language designers make design decisions. He then goes on to list values expected from a system language and why C is not the best language for it.

Bryan Cantrill, Rust and Other Interesting Things – Link

I did some research on why different organizations choose certain languages and I found the following key points.

1. Gitlab – Ruby – Link
   • GitHub, a source of inspiration for GitLab, was also based on Rails, making it a logical pick considering his interest in the framework.
   • Ruby on Rails ecosystem allows you to shape a lot of functionality at a high quality
   • We need a lot of functionality and Ruby on Rails is a way to do it
   • Consistent coding practices. You are guided to do the right thing.
   • Big community of Ruby gems
2. CockroachDB – Golang – Link
   • its support for libraries, interfaces, and tooling positioned it as the right choice for CockroachDB
   • Go was designed to scale to large code bases with an emphasis on simplicity and orthogonality of features. The enforced code style, the simple imports and automated import management, the wide variety of linters, the straightforward (and minimal) set of programmatic idioms…all of these attributes of Go are important for clean, understandable code.
   • When comparing to Java, we appreciate the tight focus on implementation instead of OOP and abstraction: interfaces can be added when needed, not as an initial, often unnecessary, step. 
   • When comparing to C++, we appreciate automatic memory management and how there’s rarely more than one way to get something done, for example with static and one-time initializers.
   • Go gives better control over memory allocation that impacts garbage collection.
3. Asana – TypeScript – Link
   • Clean JS
   • Community Support
   • Errors at compile time instead of runtime
   • Static typing
4. American Express – Golang – Link and Link
   • For their assessment, they chose to build a microservice in four different programming languages. They then compared the four languages for speed/performance, tooling, testing, and ease of development.
   • While Go may not have been the fastest language tested, its powerful tooling helped bolster its overall results. Go’s built-in testing framework, profiling capabilities, and benchmarking tools impressed the team.
   • Reasons
     • Simple and straightforward
     • Encourage best practices
     • Concurrency
     • Tooling
5. Nubank – Clojure – Link
   • Nubank provides services in the finance domain, which is very close to mathematical functions — and functional programming is an excellent fit for both scenarios.
   • Clojure, on the other hand, has simple constructs that allow us to focus on the problem we are solving, making evolving the system a small incremental challenge, which doesn’t get that much harder over time.
   • Most of our codebase can be understood locally, looking at any given pure function, understanding its outputs for any given set of inputs. There’s rarely any need to reason about or recreate the internal state of objects. Data moves through the system in a composable, inspectable, consistent, and immutable way (without hiding it inside of objects).
   • Functional code is much easier to test, and that gives us the confidence to deploy an average of over 50 changes per day in a mission-critical domain.
   • Nubank has acquired Cognitect, the US-based software consultancy behind the Clojure programming language and the Datomic database
6. Janestreet – Ocaml – Link , Link , and Link
   • Brevity of the language and the powerful type system that makes OCaml code very readable
   • Powerful abstraction capabilities that reduce boilerplates
   • Static type system for ensuring code correctness
   • He spoke about some of the fancy type tricks like parametric polymorphism, algebraic data types, type inference, phantom types and type indexed values that add to the expressivity of code.
   • Also OCaml hits the sweet spot between expressiveness of code and the performance numbers. The very much tunable GC makes things easier to control.
7. Starling Bank – Java – Link
   • Exceptions are noisy and difficult to ignore
   • Reliable ecosystem (user base, tooling, job market, etc) 
   • Integrations with legacy third parties (SOAP etc)
8. KhanAcademy – Golang – Link
   • Kotlin was more performant
   • Golang used much less memory
9. Lyft – TypeScript – Link
   • Popularity
   • Type safety
   • Less Bugs
   • Productivity
10. Medium – Golang – Link
    • More efficient use of the CPU. While Node is single-threaded, Go is much better suited for the combination of I/O and CPU-intensive operations required to build a ranked feed. Splitting our work onto separate Goroutines means we can avoid the issue of the CPU getting hogged by one single request and other requests getting starved.
    • Opinionated. Go makes it pretty hard to write “bad” code. A typed language that is also highly opinionated in terms of code styling means that even a newbie to Go (which I was when we started writing Rex) can quickly start writing clean and readable code.
    • Prior experience with Go. While much of Medium’s codebase is written in Node, we already had a few smaller-purpose microservices in Go. Adding another microservice in a language that we as a company have familiarity with makes building and maintaining this new service much easier.
11. Instagram – Python – Link
    • Simplicity
    • Practicality

I hope this post helps you understand that there is much more to choosing a programming language.

You can also support me and my work by following me on https://twitter.com/shekhargulati. Thank you 

---

Reading Resources

1. Rust vs. Go: Why They’re Better Together – Link