The choice of programming language for a project is often a complicated one, particularly when the decision involves switching from one language to another. Programming language choice is not only a technical exercise but also for many programmers, a deeply emotional one. The lack of known methods for getting clear measurements on criteria for language choice often means the act of choosing one quickly digresses into a series of emotional appeals.
I've been involved in many different discussions on which language to choose, and these discussions usually end one of two ways: either the decision is made using measurable, yet unimportant criteria while ignoring the relevant, yet hard to measure criteria or it is made using anecdotes and emotional appeals.
There has, however, been one language selection process that I've been a part of that has gone - at least until this point - rather smoothly: the growing consideration for Rust inside of Microsoft.
So what are the different criteria usually used for selecting a programming language, especially in large businesses, and why does this process usually not end successfully? Why has the consideration of Rust in Microsoft process gone smoothly so far, and is there some general best practices that can be gleaned from it.
There are many criteria that are used for deciding whether to switch to a new programming language. In general, the criteria that are most easily measured are the ones that get talk about the most even if such criteria are not as important as some other, more difficult to measure criteria.
The first group of criteria is the the technical considerations which are often for many the first that come to mind often because they are the easiest to measure.
Interestingly, the technical costs (e.g., build system integration, monitoring, tooling and support libraries, and more) are often easier to measure than technical benefits. This is especially detrimental to the adoption of new programming languages as the downsides of such adoption are often the clearest part of the picture.
While some technical benefits can be measured relatively easily, like performance, some others are much harder to measure. For example, what are the relative merits of a dynamic typing system like in Python to a relatively verbose and feature poor type system like Java's and how does this change when comparing to stronger type systems like Scala or Haskell? Many have strong gut feelings that such technical differences should be taken very seriously in language considerations, but they are no good ways to measure them.
A side effect of the discrepancy in ease of measurement is that the easiest to measure items are often given the most amount of weight in the decision making process even if this would not be the case given perfect information. This throws off not only cost/benefit analysis but also the process of assigning different costs and benefits appropriate importance.
The next set of criteria is the organizational. For example:
- how easy will it be to try and hire developers in this language?
- how easy is it to enforce programming standards?
- how quickly on average will developers be able to deliver software?
Both cost and benefits of organization criteria are hard to measure. People usually have vague, "gut feeling" answers to these criteria which give them strong opinions on the matter. Unfortunately, however, it's often very difficult to measure these criteria. For example, it might be obvious to most that TypeScript allows programmers to more quickly deliver functioning, relatively bug-free software to customers more quickly than C does, but where is the data to back this up?
Moreover, it's often extremely difficult to assign importance weights to these criteria. It's easy to see that Go more easily enforces standardized coding practices than Scala does due the wide use of gofmt, but what concrete benefit does standardizing code bases bring to a company? This is extremely difficult to measure.
These criteria are still extremely important, but because of the difficulty of measuring them, they are often either ignored or reasoned about through anecdotes.
Next are the emotional criteria which tend to be overlooked if not outright dismissed.
Software programming has traditionally tried to emulate more true "engineering" practices where technical considerations are generally the most important consideration. Some would argue that programming languages are "just tools" and so should only be measure against technical criteria. Others would argue that programming languages assist the programmer in some of the more artistic aspects of the job. These criteria are extremely difficult to measure in any meaningful way.
In general this comes down to how happy (and thus productive) programmers feel using this language. Such considerations can have real impact on programmers, but how this translates to benefit to an entire team is next to impossible to measure.
Because of the difficulty to quantify this criteria, it is often completely ignored. But does this mean that emotional considerations to programming languages have no significant impact on programmers or programming organizations?
Lastly, there's a set of criteria that often get overlooked because the new programming language is usually judged on the criteria set by the existing language. Many who are evaluating new languages might not be familiar with aspects of the new language that the current language being compared to has no equivalence to. Not having exposure to these aspects of a language might mean they're either unknowingly ignored or downplayed.
These criteria can be technical (e.g., the merits of Kotlins data classes over Java constructs), organizational (e.g., how helpful Elm's error messages are for teaching those new to the language), or emotional (e.g., the way Ruby makes the programmer feel when writing it).
Because these aspects are hard to measure and someone completely unfamiliar with them has no existing framework for judging them based on intuition or anecdote, they are often undervalued in comparison to more well understood criteria if not outright ignored.
So that brings us back to the example of the growing excitement for Rust in Microsoft. Why have the discussions around Rust adoption gone relatively smoothly so far? Because Rust has presented an extremely clear and compelling advantage over not only the existing language choice it seeks to replace (C++) but also any other language practically available to industry: great performance and high-level of control while being memory safe.
The investigation into Rust (and other languages) was initially started to address the fact that roughly 70% of CVEs in Microsoft were due to memory safety issues in C and C++. When it was discussed that most of the affected code bases could not be effectively rewritten in C# due to performance concerns, the search began. Rust was seen the only possible candidate to replace C++. It was similar enough that not everything had to be reworked, but it has a differentiator that made it measureably better than the current alternative. It was clear that being able to eliminate nearly 70% of the most serious of Microsoft's security vulnerabilities was a measurable differentiator.
There are other reasons beyond memory safety, performance, and control that make Rust appealing (e.g., strong type safety guarantees, Rust being an extremely loved language, etc.), but as expected these aspects were hard to talk about because they were hard to measure. In general, most involved in the selection process were more interested in verifying that these other aspects of the language weren't perceivably worse than C++, but because measuring these aspects was so difficult, they weren't often touted as active reasons to adopt the language.
However, when surveying teams at Microsoft that had already adopted Rust, they would normally tout other aspects of Rust (particularly "correctness" due to the advanced type system) as the reasons they were most keen on investing more in the language. These teams couldn't provide reliable measurements for this criteria, but they had clearly developed intuition that this aspect of the language was extremely important.
With Rust at Microsoft, the main criteria being judged happened to be an easily measurable one. But what happens when the most important issues to an organization happen to be hard to measure? This issues are no less important just because they happen to currently be difficult to measure.
It's clear that having clearly measurable criteria is important when adopting a new programming language, but this does not mean that hard to measure criteria aren't real and shouldn't be taken seriously. We as an industry simply lack the tools to evaluate new languages holistically.
There has been some research into this question, but it has not yet produced anything that has been widely adopted by industry. While the case for Rust was relatively clear inside of Microsoft, this doesn't mean that new languages should only be adopted where there is only one clear technical reason to do so. We as an industry should become better at evaluating more aspects of programming languages outside of just the traditional ones (such as performance).
The path to Rust adoption is just beginning at Microsoft, and only being able to justify investment in Rust for one reason, is definitely not ideal. While we're beginning to form collective anecdotal evidence to justify further Rust adoption, there is definitely a need to better quantify this understanding and to be able to talk about it in more objective terms.
How we do this, we're still not quite sure, but stay tuned for more in the future as we go down this path.
Interesante conocerlo.