Programming Languages for BIND 10

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

@nodakai: WHY BIND10 had to be written in C++?? I think supporters of managed languages have much to learn from this unfortunate incident

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. 🙂

9 Comments

Peter ChastainFebruary 27, 2013

Wondering out loud if Obj-C was given consideration. I know it’s primarily an Apple-driven language at this point, but it does seem to meet your requirements – it’s OO, has modern memory management features like ref counting and garbage collection, low-level memory management/performance tuning is possible since it’s a superset of C, and it has exceptions.

“C lacks good memory management”. Really? C’s memory management is basically an extension of the OS exposed memory management and is many cases is modeled after POSIX which is includes various standards and expected behaviors. And let’s not forget that many high level languages and libraries are themselves written or descended from C.

Sounds like a good choice. If you aren’t so concerned with speed but want flexibility, you might find RubyDNS an interesting project. It might also serve as an interesting model for how you design your Python interfaces.

Eric Brunner-WilliamsFebruary 27, 2013

i made the same choices in ’09 when setting up a dns registrar client development project, modulo the version of python, which i let track 2.x (5 < x).

Author

Shane KerrFebruary 28, 2013

We didn’t look at Objective C, since at the time we made the choice the iPhone had not yet pushed it from the realm of fringe languages to a more-or-less mainstream choice. To be honest, I’m also not convinced that it will stay popular as Android returns Apple products to the hipster outskirts of the tech world. 😉

Author

Shane KerrFebruary 28, 2013

As far as C lacking memory management, in both BIND 9 and ISC DHCP we have our own tools for insuring that we don’t have memory leaks. Plus you have to worry about double-free, use-after-free, and so on. It’s a hassle.

C++ also has sexy features so that you can use the standard new/delete commands on arbitrary memory blocks (like shared memory or locked pages). We intend to use the Boost offset_ptr to support data structures in shared memory.

Remember, anything you can do in C++ you can do in C, but anything you can do in C you can do in assembly. 😉

1) Some would argue that C++ is not a better language than C99 for building services only better than K&R C,
think you are trading one set of known issues for another that might not be so well known.
2) The term Software Engineering is abstract, there are Software Engineering Methods one can follow (Yourdon, Beck, …)
3) In practice I find many more qualified C programmers than I do C++. And for all the productivity increases that
C++ promises I see as much time wasted as team members argue for one C++ programming style/library B
vs another C++ programming style/library B in code reviews.
So good luck and look forward to seeing a successful Bind10 and look forward to reading ISC C++ Programming
Style/Guidelines (ala http://www.gotw.ca/publications/c++cs.htm)