Programming Languages for BIND 10 | Blogs by Internet Systems Consortium

This blog post comes in response to a question that arrived via Twitter:

When I started working on the BIND 10 project the only decision made was which languages to use, after the expected bikeshed discussion. The important thing at that point was to get on with the project, not re-start a possibly endless discussion about which programming language(s) to use.

Having said that, I was very happy with the languages that were chosen. In fact, I would have picked the same languages if the decision was up to me to begin with.

BIND 9 was written in C. At the time it was designed and written – at the end of the 20th century – that was really the only logical choice. C is relatively simple to read and write, is supported everywhere, and can be used to produce very fast code. It is also completely lacking in any language features to support software engineering, and is totally unsafe.

So when ISC started seriously thinking about BIND 10 – around 2006 or so – the question of what language to use for the new project came up.

The first question is of course, “Why not C?” Some answers are:

• String manipulation in C is a tedious chore
• C lacks good memory management
• Error handling is optional and cumbersome
• Encapsulation and other object-oriented features must be emulated

Everyone agreed that we could do better. The question was “how, exactly?”

There were of course some requirements for choosing a new language:

• The language had to be relatively mainstream.
  The Wikipedia page on programming languages has more than 600 languages, and is not complete. However, BIND 10 has a goal of being something that is relatively straightforward to hack on, and while using something like Eiffel or Prolog would attract some developers because of the novelty, it would be a hurdle for most programmers.As a second goal, ISC wanted to make sure that it could find experienced developers in whatever language it picked.
• The language had to address most of the problems with C.
  Ideally this meant something with good string handling, garbage collection, exceptions, and that was object oriented.
• The language had to be very fast for CPU-intensive operations.
  A modern DNS server is largely CPU-bound, both for authoritative and recursive resolver cases. DNS servers use specialized data structures and algorithms, so we cannot rely on lower-level libraries written in C or C++ to boost our speed.This requirement basically eliminates any interpreted language from the running.

The approach that we ended up choosing in the end is to use a mix of two languages:

• Python
  Whenever possible, we use Python. Python is a very popular language, usually the most popular of the scripting languages on most surveys (possibly excepting PHP). It has all of the features that we were looking for… except performance.
• C++
  When necessary, we use C++.
  C++ is also a very popular language, and also has all of the features we are looking for. However, C++ is by no means an easy language to work with, so the idea is that we will avoid its complexity when possible.

If you learned C++ a while ago, but haven’t worked with a modern C++ environment, you probably have the wrong idea about programming with it. We use the Boost library, which gives you things like shared pointers providing a sort of reference-counting on your dynamically-allocated objects. In fact, adoption of resource acquisition is initialization (RAII) can resolve a huge number of problems with both locking and leaks.

As of right now, it ends up that about 75% of our code is C++ and 17% is Python (link) since it turns out that a lot of BIND 10 is performance-critical.

Other projects will have different factors to consider when choosing a language, so even though C++ and Python are good choices for BIND 10, they won’t be for every project.

But in general think the motivations and decisions regarding the language choice for BIND 10 made sense when we started, and I think that they still make sense.

One thing we might have done differently is to choose to write our code in a way that works with both Python 2 and Python 3, instead of requiring Python 3. Over time this will be less of an issue since the future of Python is Python 3, but it has caused a lot of hand-wringing as people get very upset about having to install a new interpreter to get their software working. I hope that in 2 or 3 years we can laugh about those concerns, and Python 2 is a fading memory.