ABSTRACT
This report compares 3 different languages (D, Odin and Zig) and analyzes their suitability for building a Human Embodied Autonomous Thermostat (HEAT) system that uses the face temperature of human occupants to control the buildings’ air temperatures. Performance, reliability and security are emphasized, and a conclusion is given to suggest which language is more favorable.
INTRODUCTION
As described on their official websites, D is a general-purpose programming language with static typing, systems-level access, and C-like syntax. The Odin programming language is designed with the intent of creating an alternative to C with the goals of simplicity, high performance, built for modern systems and joy of programming. Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
PERFORMANCE
Performance is one of the key aspects we need to consider, as the sensor nodes with cameras typically have limited CPU and RAM sources as compared with the central server. The D language markets itself as “write fast, read fast and run fast”. It offers inline assemble, direct access to hardware, explicit memory allocation control and direct native code generation. Odin has a big highlight on performance. For example, procedure parameters are considered to be immutable. This allows Odin to automatically optimize how procedure values are passed. If it is more efficient to pass them by value or more efficient to pass them as an immutable pointer internally, and it does not matter from a user perspective. Zig claims to be “faster than C”. For example, the reference implementation uses LLVM as a backend for state of the art optimizations, and “Link Time Optimization” is enabled by default. For native targets, advanced CPU features are enabled. Zig also directly exposes a SIMD vector type, making it easy to write portable vectorized code.
RELIABILITY
As a system which runs 24-hour, we expect great reliability on the language, and hope it is able to handle runtime errors without breaking the system. C, for example, suffers a lot on this, as an undefined dereference of a pointer can easily crash the program. Thus, we are interested in how well these languages handle exceptions. In D language, exception handling is done with the try-catch-finally statement. One thing worth mentioning is that, in contrast to most other programming languages, even if an exception is raised in the finally statement and is not caught, it will be automatically chained to the previous exception, so that it can be caught eventually. This brings a big reliability advantage over other languages. However, Odin couples exceptions to a control structure, since it believes try-catch finally complicates the understanding of the program. Odin uses plain error handling through the use of multiple return values. And, it is clear to check which procedure the error value is from. In Zig, pointers cannot be null, so there is no chance at all of null references which are the source of many runtime exceptions. Errors are values which may not be ignored, and must be handled by a single catch statement.
EASY TO AUDIT
Simplicity and readability are important, since big customers such as prisons and intelligent offices may want to audit our program prior to deployment. Zig promotes code maintenance and readability by making all control flow managed exclusively with language keywords and function calls. Zig’s entire syntax is specified with a 500-line grammar file. There is no hidden control flow, no hidden memory allocations, no preprocessor, and no macros. Most importantly, this implies that calls to functions are guaranteed, and if the code does not look like it is jumping away to call a function, then it is not, without needing to know the types of anything. This is a huge advantage over the other two languages, as though both D and Odin brings readability and simplicity to C in terms of syntax, they do not have those kind of features.
FREE-STANDING
The language must be able to run on the hardware natively, without the help of third-party libraries or operating systems as they may introduce additional safety concerns. D language, as stated by the official, keeps standalone in mind at design time and enables programmers to build efficient, lightweight and standalone programs, which is ideal for our needs. Unfortunately, no information about Odin or Zig on their feasibility of writing standalone programs is found, so the only option left is D on this aspect.
IOT FRIENDLY
We are interested in whether or not the language is optimized for running on embedded systems at design time, so it may be adopted in commercial field. D is a high level language, but retains the ability to write high performance code and interface directly with hardware. This allows us to interact with devices such as sensors and cameras directly. Odin offers high control over memory layout which allows more direct hardware access. Neither Odin nor Zig provides clear indication on their support on direct hardware access, in contrast to D. Also, no information on all three languages about the existence of their application on IoT and embedded devices are found through Internet search, so it is difficult to make a conclusion here.
CONCLUSION
The D language may be the best option for building our system, at least based on our short-time Internet research. All 3 languages claim superior performance, but D has a reliability advantage due to its unique exception handling. D is also the only language which claims to be able to build standalone softwares and allows programmers to write interfaces for interacting with hardwares such as sensors and cameras directly, which satisfies our requirement. Odin and Zig, unfortunately, does not meet our needs for building a commercial embedded system, though they have some other advantages such as code simplicity.