Seasoned course author, Jack Card, takes a look at the safest programming languages today..
It's important to get some perspective. Back in the 1970s and 1980s the development of programming languages was quite slow compared with today. Certainly, there would be at most an update to a language around once a year and the language standards tended to evolve at a much slower rate. At the time very few people got excited about the release of a new version of a language. Of course, back then there were fewer programming languages to choose from and they were more similar to each other than perhaps some of today’s languages are.
One of the features of that period was a gradual move away from low level assembly languages to higher level programming languages such as Pascal, C or even big corporate languages such as IBMs PL/1. This was in part due to the safer more secure nature of these higher-level languages; that is, it was harder to make simple, fundamental mistakes in these higher-level languages. In addition, productivity tended to be faster as the developer could focus more on solving the problem at hand rather than trying to deal with low level features such as memory locations and registers.
This pattern continued for some time, but by the mid 80s a new trend started to appear; languages that raised the bar further and in doing so distanced the programmer further from the lower-level features of the computer that they ran on. The poster child for this new approach was Java with its virtual machine and automated memory management model. The aim here was to allow the developer to avoid the need to allocate and deallocate the memory they used themselves.
Part of the argument here was that trying to manage the memory your program used, while also trying to solve whatever application problem the software was intended for caused the resulting code to be more complex and thus harder to understand, harder to maintain, harder to extend and easier for undetected bugs to crop up.
Not everyone liked this approach …I remember well that programmers transitioning to C reacted very negatively to the idea that they didn't manage the memory their programs used. Their argument was along the lines of “How do I know it will work, how do I know that it will deallocate the memory correctly?!” …Whereas they felt their own programming ability allowed them to guarantee that their programs would be bug-free in this respect.
Of course, the counterargument is that a language like Java might well have bugs but very many developers have used Java many, many times and any problems should be identified and resolved quickly as a result. In contrast, a single developer’s own code might only be tested by one or two people (and then not necessarily as thoroughly as one might hope).
An additional advantage of allowing the programming language / runtime to manage a program’s memory allocation and deallocation is that the system can potentially perform additional checks to ensure that dangerous operations or access attempts won’t corrupt your program or its memory. For example, in a language such as C it is possible to use pointers and pointer arithmetic to access memory beyond the scope of, say, an array and either read from, or write to, that memory corrupting other parts of the program. Whereas, in languages like Java, C#
or Kotlin this is either not possible or much, much harder to achieve.
Spring forward to 2024 and you might expect that languages such as C and its ‘offspring’ C++ might have fallen out of favour; however, C and C++ both still have some significant advantages over more recent languages such as Java and Kotlin – namely speed and low level memory / device access.
Because of this, many commercial applications are still written in C and C++. If you look at the recent TIOBE index for February 2024, C is second in the index and C++ is third. You might find this surprising – but this is how they work out the rankings:
“The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third-party vendors. Popular web sites Google, Amazon, Wikipedia, Bing and more than 20 other engines are used to calculate the ratings.”
Many industry experts find this a good indicator of a language’s true popularity.
Interestingly, Python is number 1 in the index and that is another language which has an ‘automatic memory management’ style of operation. However, from a safety and security point of view, it has its own major weakness – type safety. Languages such as Java, C# and Kotlin are ‘strongly typed’ languages that check for basic type safety at compile time. They will then reject a program if it contains any type safety issues. As a simple example, one system I worked on over 30 years ago failed because one part of the system sent a number in string format while another expected it in a binary format and thus the number could be misinterpreted. However, in a strongly typed system a value will be specified as being of ‘type String’ or ‘type Integer’ (for example) and the compiler will report a compile time error if this condition is not met.
Looking at the TIOBE index, the languages that capture some of these safety and security ideas such as Java, C#, Kotlin and Rust come further down the index - for example Java and C# are 4th and 5th but Kotlin is down in 17th place and Rust in 18th.
So why should we care about this? Developers should just choose the language which suits their needs best, for example Python is excellent for Data Analytics, partly due to the fact that it is not strongly typed and C/C++ are fast and allow for low level access etc.
Interestingly, the White House in the USA has urged developers not to use languages such as C and C++ but instead to use safer and more secure languages in a report called ‘Back to the Building Blocks: A Path Toward Secure and Measurable Software’ published in February 2024.
The report advocates several recommended actions for software development. Principal amongst these is the use of memory safe programming languages. In particular, they say:
“There are two broad categories of memory safety vulnerabilities: spatial and temporal. Spatial memory safety issues result from memory accesses performed outside of the “correct” bounds established for variables and objects in memory. Temporal memory safety issues arise when memory is accessed outside of time or state, such as accessing object data after the object is freed or when memory accesses are unexpectedly interleaved.”
Languages such as Java and C# certainly address the spatial aspect – in that it is not possible to access such memory from within an application. The temporal aspects are mostly addressed, although newer languages such as Kotlin and Go are better when we consider the unexpected interleaving of memory access within a multi-threaded environment.
This does not necessarily mean that applications written using languages such as Java and C# are free of any safety or security issues, just that they tend to be less likely to contain fundamental issues. Of course, it is worth noting that few applications are written from scratch these days; third-party libraries are often employed to make the job easier. These libraries are an additional source of concern, and they can introduce issues into an application even though the basic language is considered secure. For example, back in December 2021 it was discovered that a vulnerability within Log4J, an incredibly widely-used open source logging library for Java had a critical weakness. Thus, merely adopting a safe and secure language does not guarantee safety and security.
This of course raises the question about probably one of the most widely-used programming languages across the world – JavaScript. Take a look at the StackOverflow survey of 2023 which shows over 65% of all professional developers using JavaScript.
JavaScript has several issues associated with safety and security which at first glance might suggest it’s not a great choice for modern, critical applications. Whilst there may be some truth to that, it is not a very practical idea, as so many software systems rely on JavaScript. These are some of the issues that developers need to consider:
Let us start off with the first issue here – JavaScript is an untyped language. There are two approaches that can be adopted to ameliorate the situation though; the first is to use static software analysis tools to look for issues associated with type safety (for example such as JSHint, ESLint and PMD). These tools have come a long way since their inception and are now very good at identifying potential issues. They can often be integrated into the development environment used by developers and the Continuous Integration (CI) tooling often used in organisations (such as Jenkins, Circle CI and Azure DevOps).
However, it would be even better to just eliminate the potential for type safety issues altogether and this is what is provide in TypeScript. TypeScript is essentially JavaScript with strong type checking. That is, it is a strongly typed programming language that builds on top of JavaScript. In many cases when you ‘compile’ your TypeScript the output is plain old JavaScript, but you are now sure that the resulting code is type safe.
So, it is relatively straightforward to migrate over to using typescript from plain JavaScript and ensure that any new code still works with existing JavaScript code.
The next issue is that JavaScript runs within browsers all over the world! This is certainly true but it’s not the only way to execute JavaScript applications.
Node.js is a very well-established runtime environment for JavaScript applications. It can be used to create stand-alone applications, desktop applications or sever applications. This does not directly address the issue of client-side JavaScript, but it does give another option regarding how to run JavaScript. As such an application running within an organisation’s server side (or cloud based) is fundamentally less secure than one running in an end user’s browser somewhere on the web. Of course, the benefit of running in the client’s browser is that its local whereas if the application runs within the could then data must be sent back and forth etc. However, with today’s internet speeds and processing power this is becoming less and less of an issue.
In addition, Node.js is a well understood environment with well documented approaches to ensure additional safety and security as illustrated by this Secure Node Development course.
Finally, JavaScript has an automatic memory management model, so it is already something that is handled by the language. This represents a lot of heavy lifting that developers don’t have to worry about (at least from a coding perspective).
Does this mean you should abandon your existing programming language and jump to TypeScript, Java, Kotlin or C#? Probably not. But it does highlight an issue to be considered going forward. Even Python, which is one of the classic dynamically-typed languages, has an option for specifying type information and getting reports on whether the type safety has been broken or not – it’s just not enforced.
Choosing a programming language to use is no easy task; different languages have different pros and cons that need to be traded off against each other depending on the type of application, its projected lifetime, safety level and distribution etc. C and C++ are inherently unsafe it just that it is easy to really mess things up in those languages; in turn Java and C# aren't inherently safe it’s just that it is much harder to really get things wrong.
Therefore, it is probably appropriate to take into account the requirements and needs of new projects, along with the knowledge and skills of your developers, when selecting the next program language or languages to adopt within a project or organisation. Training and support are then the next important steps in migrating to your new development environment.
Take a look at our Instructor-led Technical Training Courses or get in touch to find out how we can build a tailored training programme to help your team build world-class software.
