Enhance solution performance by choosing the right programming language

It is a fact that software driven solutions drive our lives and have become ubiquitous across the world.

As famously said by Silicon Valley venture capital firm, Andreessen Horowitz, software is indeed eating the world.

Take the modern car as an example, a typical model will have in the region of 50 CPUs running and maintaining its systems. Every time you see a car on the road, you should think of it is as 50 electrical processors transporting biological data processors – us. Given this prevalence of software in the world, one area where little attention has been placed is the relative performance of different programming languages. Computer programming languages act as a crux, enabling us to give instructions to a computer in a language the computer understands. Just as many human-based languages exist, there is an array of programming languages that engineers and architects can use to communicate with a computer. While all Turing complete languages can solve similar problems, some are more suitable to certain challenges by design. For instance, few would consider using C++ to create a front end.

The portion of the language that a computer can understand is called a “binary.” Translating programming language into binary is known as “compiling.” Each programming language, from Fortran, C, to Python, has its own distinct features, though many times there are commonalities between programming languages. Because of the ubiquity of software driven solutions in today’s world, it is essential that organisations select the right language to maximise solution performance. To make an effective choice, understanding the prime differentiating factors is vital.

Analysing the factors

Programming languages allow computers to efficiently process large and complex data structures and information. For example, if a person is given a list of 100 numbers and asked to determine whether they are prime numbers, chances are that it will take a significant amount of time and include some errors. To compare the performance of various programming languages, we conducted a similar test. We used various programming languages to determine which numbers between 2 and 1,000,000 were primes. Here is our output:

‍

‍

Some of the older programming languages were designed with antifragility baked in and are actively maintained. This means that some languages may actually be ageing like fine wine, but execution performance is not the only thing that matters. The ability to easily write code to incorporate newer architecture patterns like microservices is also extremely important, if not more so than execution as a prime factor. Businesses must also consider that in the world of distributed compute, the time it takes for a data packet to travel across a network is critical, with a round trip taking an average of 115ms.

Language loyalists would be right to point out that our example does not represent a real-world use case or algorithm. Because of this, it is worth noting that specific language and platform optimisations can significantly change the outcome of a speed test like ours. The Go programming language serves as a good example here, with a multi-threaded implementation winning in our speed testing process. Similarly, we should see implementations that use Newton’s method for computing square roots winning on older hardware with slower math co-processors.

‍

‍

Priorities for engineers and architects

In the world of system design, architecture encompasses the important choices you make that will change infrequently. At this point, architects may be asking how ‘infrequently’ can be defined in the context of system design. In principle, we generally accept that anything that our stakeholders consider important should form part of the architecture. A prime example to factor in would be whether your solution is client facing, which would indicate the need for front-end design. In our experience, rarely is there a business case for large scale refactoring of an application to be re-written, so it is a valuable use of time to make the right programming language decision at the outset.

When designing and developing a solution, engineers and architects need to view the selection of a programming language as a conscious architectural decision. This choice will ultimately have an impact on the performance of the solution for a long time to come, including factors like execution and ease of re-writing code. The decision should be made with the same weight of importance as is given to getting domain boundaries right, choosing whether to use a content delivery network, or deploying full stack solutions onto remote region servers. As enterprises continue on their journey towards adoption of Microservices based architectures and eventually end up with functions as service, they shouldn’t hesitate to explore a Polyglot solution architecture that uses different languages to suit different functional and non-functional performance requirements.

Perhaps an unintended advantage that a faster language might bring is lowering the carbon footprint. A language that runs faster consumes fewer CPU cycles, and hence lower energy. For a lot of software the impact might be insignificant, but at an extreme, consider mining cryptocurrencies using a language like Python – our guess is the power consumption might be 50 times higher.

Source code : github.com