The Fastest Programming Languages Aren’t The Most Popular. Why Not?

One of the perks of working as a software engineering consultant is that you get to experience a wide variety of tech stacks. Having a group of smart individuals working on a variety of stacks inevitably leads to many discussions around the pros and cons of each stack, and one particular metric comes up often: performance.

It’s a fairly common occurrence in our office to have someone ask about the performance of a certain language or to link an article showcasing benchmarks that paint a certain language in a negative light. This usually leads to someone else saying, “Performance doesn’t matter.”

This article by Google reveals that the real-world impact of performance absolutely does matter. Even a 100ms faster page load can lead to non-trivial conversion improvements.

However, cross-referencing recent stats about language popularity from GitHub with the Benchmarks Game shows that the most popular languages (Javascript, Java, Python) are quite a bit slower than the fastest alternatives (Rust, C, C++).

So why do so many developers use slower languages if performance actually does matter? And why is it common to hear from senior folks that performance doesn’t matter?

The short answer is: real-world perceived performance (for example, page load speed) does matter but what contributes to that speed is not nearly as straightforward as choosing the language for your stack.

---

Conversion improvements come from how your users perceive the speed of your site or app. The technical considerations don’t matter, and nobody cares if your page is slow for good reason, like if you’re loading some wonderful, interactive data visualization. If a view “feels slow”, your users will be less happy, and conversion and engagement will be reduced.

Let’s look at the process that happens when a user loads your app, assuming it’s a basic SPA (client-side rendering and an API, no CDN):

1. The user (their computer, not them personally) does a DNS lookup to get the IP address associated with your domain name.

2. The user’s browser makes a request for the HTML contents of the page from your server, then downloads that HTML.

3. The user’s browser renders the DOM from your source HTML and paints the page for the first time. Since we’re assuming a basic client-side rendering scenario, this paint is essentially blank because the frontend framework hasn’t executed and filled the page with content yet.

4. At the same time as it’s working on DOM rendering, the user’s browser fires off requests for all the assets listed in the HTML: Javascript, CSS, images, etc.

5. The user’s browser interprets and runs all Javascript it receives.

6. Once the DOM is ready, the user’s browser executes Javascript that was waiting on it (which is often most of the Javascript).

7. The client-side rendering framework (React, Vue, Angular, etc.) runs and appends all the DOM elements needed for the initial page.

8. The user’s browser renders images and videos as it receives them.

Using some made-up but relatively realistic numbers, the page load graph looks like this:

A couple of notes:

• In reality, browsers will do some of these things at the same time, but the overall picture is about the same.
• Chrome dev tools Network tab does a great job of showing this in action. Go to some web apps you use and check it out!

A variety of things are interesting about this graph:

First, many things are out of your control. DNS, request latency, etc. are simply going to take some particular amount of time, regardless of what you do in your stack.

Second, client-side rendering is a large portion of time. Discussing the tradeoffs of Client-side vs. Server-side rendering (and hybrid approaches) is a great topic that we’ll cover in a follow-up post shortly.

Finally, and most importantly, the only portion that your backend does control is “Waiting (TTFB)”. In our example (and in my experience, most real-world cases), this is a very small portion of the overall time. This is where the “performance doesn’t matter” opinion comes from: spending a lot of effort on such a tiny portion of the overall page load may be a fool’s errand.

---

Why Not Just Use the Fastest Programming Language?

Even though individual components of a stack may have little effect on the whole picture, you might still be thinking: even if it helps by 10ms, it still helps, so why not use the fastest programming language possible?

There’s merit to that opinion. Since 100ms page-load difference has a non-trivial conversion impact, you can infer that even 10ms of improvement would have an impact. Why then do so many developers use slower languages?

The reason is that language, framework, and database design is a series of tradeoffs. Nothing is free.

To illustrate the concept, let’s look at memory management: something has to manage memory in an application. A language can take a variety of approaches, generally fitting into these two buckets:

1.Force the developer to manage memory

This requires additional knowledge and effort on the part of the developer, and depending on the model, a higher risk of memory-related bugs (buffer overflow, etc.). Even models that avoid that issue still have a tradeoff of some form. For example, Rust forces the developer to manage memory and is memory safe, but the tradeoff is complexity with borrow checking and lifetimes.

2. Manage memory automatically (garbage collection)

This makes the developer’s job easier and avoids memory-related bugs, but comes at the cost of overhead. Garbage-collected languages are effectively always slower than non-GC languages.

Every programming language is a long series of trade-offs like that, often with the two sides being performance vs. developer efficiency.

Rhetorical question to prove the point: is a 10ms faster page load speed worth 20% more development hours? Is 100ms faster worth 100% more development hours?

---

The development community would benefit from speaking more honestly about performance. It’s a fact that page-load speed impacts conversion. It’s also a fact that some languages are faster than others, but that speed likely comes at a cost in some other area.

Instead of saying either “let’s create everything from scratch in C because it’s the fastest” or “performance doesn’t matter,” consider the real-world implications of the choice for your particular situation. If a certain choice costs a bit in terms of developer efficiency but leads to 300ms better load times, then it might be worth it. If a different choice is equally costly but only changes your load times by 1ms, then it’s likely not worth it, and discussing it endlessly is bikeshedding.

So instead of getting into arguments about algorithm performance with language zealots on the internet, embrace the fact that a language you love is slow because that probably means it has other things going for it.

---

Author: Allan, CTO and Co-Founder