Your language can improve correctness

Last Update: 2024-04-10

A/N: Unlike other articles on this blog, it isn't continuously updated. Because this is a matter of opinion.

Yes, you read right: the programming language of your choice can actually improve the correctness of your program. Not everything you choose is made equal. Tooling choices actually matter.

Example

Imagine two programs written in programming language A and another written in B:

• A is a statically typed programming language
  (simplified example: let x: int = 0)
• B is a dynamically typed programming language, i.e. no types
  (simplified example: let x = 0)

Both programming languages have the following equal conditions:

• Latency to executing the program (e.g. compilation step, startup of the interpreter)
• Runtime speed
• Automated testing

And no, this is not an article against dynamically typed programming languages.

How do you improve correctness?

First of, correctness in this context means the following:

• your program does fullfill perceived (by the developer) initial requirements
• your program works in real-world deployments

For program written in A you can do the following:

1. Let others critique your code
2. Write automated tests
3. Do tests by hand
4. Use the forced upon you type system

For program written in B you can do the following:

1. Do the above 1-3

The frequency of automated tests and manual tests can be improved with a smaller latency to executing the program and faster runtime performance, which most likely leads to increased program correctness.

There's also a trade-off between a more strict type system and a vastly improved testing story.

Comparision

Programming language A does provide a mechanism to improve the correctness of your code: a static type system. B doesn't have that advantage and looses on that point. Due to all other features being equal, A is better at improving program correctness, because B cannot easily replace the need for better correctness with more tests.

Of course, if it's too time-consuming for you to use said statically typed language due to skill issues or comfort, you may be better off programming in B.

In practice Go vs. TypeScript

First of, a collection of features in both languages, that could drive correctness.

Summarizing Go:

• A static type system
• Fast compilation speed, even faster startup time of compiled programs
• Built-in support for writing unit tests

Summarizing TypeScript:

• A static type system
• No built-in support for writing unit tests
• Hot module replacement (in some cases)

Go's type system is superior in correctness, because TypeScript's any can at any time break your beautifully (painfully) typed world.

Due to Go's built-in unit tests, small applications can more easily be tested.

In small projects, Go's compilation speed and amazing runtime speed, increases the frequency of automated and manual tests, which is less likely with TypeScript.

On the other hand in bigger web dev projects, I would rate both languages equal, though my experience is lacking in this area (professional PHP, C#, JavaScript, small-time TypeScript programmer here).

Other bigger TypeScript applications cannot profit as much from the likes of HMR, meaning you're better of writing them in Go, notwithstanding other trade-offs.

Use the right to tool for the job. Not the DX tool. (DX as in = the thing you are already the most comfortable with, before you used it). When you're not on the job, maybe this just helps you to explain some of your tooling problems.

Closing words

It was a hard decision to include HMR to 'TypeScript's features', but it offsets compile time in (complicated) web dev environments. I didn't add testing frameworks, because simple console applications can't really use a built-in language feature for testing.

This article btw. only cares about language features, which (may) improve program correctness.

This article was written with the help of Lume, a 11ty-like Deno static webpage generator, and yes some TypeScript.