Null Safe Networking

Type “null pointer” into the search field on Git and you will find 116M mentions in code, 72M commits, and 224K (presumably) current issues. That is just the open source repository. Sir Anthony Hoare, a man with an otherwise noteworthy career, publicly flogged himself in 2009 over what he called his billion-dollar mistake, the invention of “null”. Such is life…

50+ years later, the industry is still looking for an answer. The basic idea of a strongly typed language is the compiler checks correct usage/references at compile time, to avoid runtime errors/crashes. That is what Tony Hoare was attempting to do in 1965, but according to his own account, he could not resist the temptation to put the concept of “null” into Algol, because it was so easy to put in. In doing so, the purpose of strongly typed languages have, through a modern lens, been compromised.

What is the modern response to this problem? There are three that immediately come to mind. Boatloads of code that does nothing but checking for null, boatloads of testing, and new languages that are eliminating the concept of null.

This is on my mind at the moment primarily because I am playing with Flutter/Dart on a personal project, and Google is preparing a Null Safe release. Fundamentally, the ability to have variables that cannot be null. The big upside is the reduction of code for null checking, which becomes irrelevant for a variable that cannot be null. It has been observed, a great deal of complexity comes simply from the pursuit of robustness “we argue that complexity in highly organized systems arises primarily from design strategies intended to create robustness.” Doyle, Anderson “Contrasting Views of Complexity and Their Implications For Network-Centric Infrastructures”. The ultimate goal with null safe languages is of course the reduction of null based errors at runtime.

Google claims in a Null Safe Dart video, that Swift is the only other “soundly” null safe language. Swift is of course a Flutter/Dart competitor, as the Apple recommended/developed language for IOS programming. The assertion may simply have been a contextual reference lost in translation. Proponents of the programming language Rust, would also “assert” Rust is soundly null safe. There is one Rust-based implementation of a routing stack I am aware of, from Flock Networks.

I mention Rust because I am seeing more references to it from people I interact with. Java has always been a fun language to play with because it provides a high-level of safety, but it came with a performance tax. Languages like Rust are pushing into the systems programming domain with high levels of safety.

Dart, like Rust, will give the programmer an override. Damn it compiler, I know what I am doing, trust me. A way of indicating to the compiler to disregard normal safety checks. Does this get us back to square one, programmers systematically turning off safety checks? I have no idea. The future will reveal the answer to that question. Presumably programmers will know that this override is to only be used judicially and when they really know it is ok to use it. The reason for an override is there are some circumstances, especially in systems programming, where the programmer does know better than the compiler.

Over the last few years, most of the major networking vendors have released new Linux-based network operating systems. This means they are bringing forward all of the challenges with historical systems programming languages like C, but also all of the advantages of code that has been tested, debugged, and made operational in production networks. They are also bringing forward some highish level of functionality, though often not all capabilities.

I do not expect the major routing suppliers to rewrite their routing stacks in Rust anytime soon, and definitely not Java, Swift, or Dart. I’m not sure their existing customers would perceive much upside from that. OTOH, to the extent that there is opportunity for a new entrant in routing, which is always hard to forecast because it requires opportunity, execution, and innovation, Rust may indeed be an interesting language choice.

I do not expect networks to suddenly be flooded with null safe software anytime soon. So programmers will be checking for nulls, perhaps even checking twice at this time of year, and testers will be doing as much, optimally highly automated, testing as possible. These will be the mainstays of dealing with “null” for many years to come. Don’t get me wrong, testing is always going to be needed for many different reasons, but there is for sure a null tax in networking software on many levels: code writing, code testing, code fixing, runtime errors,..Null safe networking is an interesting future to contemplate, even if it is not immediately obvious what the path from here to there will be.