這篇博文是對來自Twitter的這個問題的答覆：
@nodakai: 為什麼BIND10非要用C++編寫?? 我認為從這個不幸的事件中，託管語言的支持者們有許多需要學習瞭解的地方
當我開始進行BIND 10的專案工作時，唯一已經做的決定就是要使用哪種程式語言，恰逢預料之中的關於自行車棚的那次討論之後。 那時最重要的問題是要讓專案繼續進行，而不是去重啟一場可能永無休止的爭論，一直討論到底要使用哪種（或哪些）程式設計。
話說到這了，我對所選語言感到非常滿意。實際上，如果開頭就要做這個決定的人是我，我選擇的也是同樣這些語言。
BIND 9 是用C語言編寫的。在它設計和編寫之時 —— 在20世紀末 —— 這真是一個唯一合乎邏輯的選擇。C語言在閱讀和編寫方面相對簡單，很多平臺都支援它，並且還能生成執行速度飛快的程式碼。 此外，C缺乏能夠支援軟體工程的語言特性，而且完全不安全。
於是，當ISC開始正式考慮BIND 10時 ——大約是2006年左右 —— 就提出了新專案要使用哪種語言的問題。
第一個很顯然的問題是，“為什麼不用C？” 下面給出部分答案：
- C中的字串操作實在是個乏味的苦差事
- C缺乏很好的記憶體管理機制
- 錯誤處理有隨意性且難弄
- 封裝和其它物件導向的特性只能通過模仿才能實現
大家都一致認為，我們可以做得更好。問題是“怎樣才能準確的做到這一點？”
要選擇一門新的語言，當然要滿足一些要求：
- 該語言必須處於相對主流的位置。
Wikipedia上關於程式語言的頁面 中列出了600多種語言，而且還沒有列完。然而，BIND 10有一個目標是，要讓大家很簡單就能上手。儘管使用類似Eiffel或Prolog的這類語言後，因為它們比較新奇所以有可能會吸引一些開發者，但對於大多數程式設計師來說卻是個難以逾越的障礙。還有第二個理由，ISC要保證，無論選什麼語言都必須能夠找到熟練的開發者。 - 該語言必須能夠解決C語言中的絕大多數問題。
理想情況下，這意味著，該語言必須能優雅的處理字串、記憶體垃圾回收，異常處理，並且還是物件導向的。 - 該語言在CPU密集型運算方面速度要非常快。
現代的DNS伺服器很大程度上是屬於計算密集型的，無論是在有授權還是在遞迴解析的情況下都是這樣。DNS伺服器要使用特定的資料結構和演算法，所以我們無法依賴用C或者C++編寫的底層庫。這個要求基本上排除了使用任何解釋性語言的可能性。
我們最終選擇的方式是混合使用兩種程式語言:
- Python
只要有可能, 我們都儘量使用Python。Python是一種非常流行的語言, 通常在大多數調查中都是最流行的指令碼語言（可能要除PHP之外）。它具有我們要尋找的所有特性。。。就是在效能方面有點問題。 - C++
當有必要時，我們會使用C++.
C++也是一門非常流行的語言, 而且也具有我們要尋找的所有特性。然而，C++絕不是一門很容易就能使用起來的語言，於是我們想了個主意，就是我們在可能的情況下要避免它的複雜性。
如果你在很早的時候學過C++但沒有在現在的C++程式設計環境下編過程式，你可能會對用它來程式設計有著一些錯誤的觀點。我們使用了Boost庫，這裡面有個共享指標，能提供一種對動態分配物件的引用計數的手段。實際上，採用資源獲得即初始化(RAII)後，就能夠解決大量的資源鎖定和洩露問題。
到目前為止，結果中我們程式碼的75%用到是C++，17%用的是Python (連結) ，這個結果表明，BIND 10中的大部分程式碼對效能要求都很嚴格。
在選擇語言時，其它的專案會有不同的考慮因素，所以，儘管C++和Python是BIND 10不錯的選擇，但它們可不是適合於每個專案。
但從大的思路上講，為BIND 10考慮語言選擇方面的動因和決策方式在我們的專案開始時很有意義，而且我想它們現在仍然很有意義。
有一件我們可能會以不同方式來作的事是，選擇編寫能夠同時執行於Python 2和Python 3中的程式碼，而不是必須要求Python 3。隨著時間的推移，這個問題會變得越來越小，因為Python的未來 是 Python 3，但這個決定給人們帶來很多苦惱，為了執行個軟體還不得不安裝一個新版本的直譯器，這讓人很不高興。我希望2到3年後，我們能夠笑談這些苦惱，而Python 2已成為一段退色的記憶。