Obj-C anyone? Seems to meet all their requirements - OO, exception-handling, memory management via either ref counting or GC, and it's a C-superset so C-based optimizations would be easy. Maybe the run-time is to large and/or complicated? Although how it could be more complicated than a C++ runtime I don't know. Would Apple being the primary driving force behind it's development be a problem?
Why is BIND 10 written in C++ and Python?
101–110 of 136 posts
Re: Why is BIND 10 written in C++ and Python?
#102Quoting from the article, with my replies: > String manipulation in C is a tedious chore. Use a dynamic strings library, like Postfix for instance, and everything else. > C lacks good memory management. So strange that you went for C++ for most of your code that is not immune of problems from this point of view. I could understand that point if you were opting for a language with GC support. With C you can easily get…
Does anyone know of large projects where C++ handles memory allocation failures gracefully? For services that need to stay up and never crash under memory pressure, I would think C is the way to go. It's too hard to reason about control flow with exceptions.
Re: Why is BIND 10 written in C++ and Python?
#103Earlier quoted context omitted.
Consider realloc. Seems like a sensible function, with its ability to extend memory blocks in-place. Except, you can't try to extend a memory block in-place, but not move it if it can't be extended. malloc and friends really are a quite poor way of managing a memory space if you want to do even slightly clever things I find, unfortunatly
There are plenty of malloc alternatives (tcmalloc,jemalloc, etc)— and yet I'm not aware of any that has bothered with a realloc_only_if_you_dont_need_to_move(). I'm not aware of any higher level language construct that reduces to that— where your program flow changes depending on details of the systems memory management. If this were an interesting case, I would have thought someone would have implemented it somewher…
This isn't a detail of systems memory management, this is "all my pointers just moved to a different place". You can't really get something more major!
You can't use realloc on C++ types (which typically need their constructors/destructors running without their memory address moving underneath them). I've written C types which had similar behaviour, and were not happy about being moved. Of course you can (and people do) write code which will after the move go through and do fix-ups, but it is often move pleasant to do the move yourself, if an in-place move isn't going to work.
Re: Why is BIND 10 written in C++ and Python?
#104Earlier quoted context omitted.
Why doesn't it look good for python? As far as I'm aware, Python has never been advertised as a top-performance language, and part of the advantage has always been that you can rewrite performance-critical paths in c. Adding to this, the fact that BIND is something pretty performance-intensive, I don't think this makes it look bad at all.
>Why doesn't it look good for python? Because it directly contradicts the "only 20% of your code is performance sensitive and the other 80% can be scripting language X" nonsense that scripting language apologists constantly parrot with no evidence. This is a good example of how scripting languages are in fact not well suited to application development, and should instead be used for scripting.
I would argue that BIND isn't "merely" an application: it's almost kernel-level in what it needs to do and how it needs to respond. At a minimum, it's system-level—but definitely not application-level.
Re: Why is BIND 10 written in C++ and Python?
#105Quoting from the article, with my replies: > String manipulation in C is a tedious chore. Use a dynamic strings library, like Postfix for instance, and everything else. > C lacks good memory management. So strange that you went for C++ for most of your code that is not immune of problems from this point of view. I could understand that point if you were opting for a language with GC support. With C you can easily get…
So I used to agree with you, but I've done extensive performance critical C development at Facebook (memcached, a new thing we are about to talk about) and I have also done extensive performance critical c++11 development (our layer 7 load balancer for http) and I'd have to say that c++11 is the far superior option if you really, truly understand what the compiler is doing to your code (a huge caveat).
Unique_ptrs are a total game changer, and the ability to use closures and lambdas when you want to set a callback function instead of a function pointer with a context pointer you have to cast and decode is absolutely huge for readability. maybe we aren't getting every last bit of performance out of it that we could with C, but it works at our pretty ridiculous scale, so I think C might have been a premature optimization for us.
Re: Why is BIND 10 written in C++ and Python?
#106Quoting from the article, with my replies: > String manipulation in C is a tedious chore. Use a dynamic strings library, like Postfix for instance, and everything else. > C lacks good memory management. So strange that you went for C++ for most of your code that is not immune of problems from this point of view. I could understand that point if you were opting for a language with GC support. With C you can easily get…
Does anyone know of large projects where C++ handles memory allocation failures gracefully? For services that need to stay up and never crash under memory pressure, I would think C is the way to go. It's too hard to reason about control flow with exceptions.
You don't have to use exceptions in C++. You can do stuff the same way as in C by checking the return pointer.
I've worked on C++ apps that had built-in garbage collection (basically asset (geometry) paging) for huge amounts of data that would allocate/free/page on demand based on what was going on.
Re: Why is BIND 10 written in C++ and Python?
#107A good overview of BIND 10's architecture: http://jpmens.net/2012/12/21/completely-different-bind-10/ It seems that all apart from the performance critical parts are written in Python 3.1
Wow! Someone at the ISC has finally learned what Unix means. I've not used Bind for years after being burned by it's security issues back in the 90's. The 'one big monolithic' program was a terrible idea. I had used DJB dns for years, even with its shortcomings in areas, the modular design caused a bug or security issue in one area not to kill the entire system. Hopefully with bind 10 we'll be able to use user separa…
BIND 10 is not the Unix way. In BIND 10, the use of separate processes is just an implementation detail. The Unix way is about presenting small programs to the user that can be composed. To the user, BIND 10 is actually more monolithic than BIND 9 because it needlessly includes a DHCP server. The Unix way is also about human-editable text files - SQLite zone files and icky JSON config files are the antithesis of that.
I'm not saying the separate-process design of BIND 10 is bad (to the contrary it's good for security), but using multiple processes internally is only Unix-y in a superficial way.
Re: Why is BIND 10 written in C++ and Python?
#108Quoting from the article, with my replies: > String manipulation in C is a tedious chore. Use a dynamic strings library, like Postfix for instance, and everything else. > C lacks good memory management. So strange that you went for C++ for most of your code that is not immune of problems from this point of view. I could understand that point if you were opting for a language with GC support. With C you can easily get…
So I used to agree with you, but I've done extensive performance critical C development at Facebook (memcached, a new thing we are about to talk about) and I have also done extensive performance critical c++11 development (our layer 7 load balancer for http) and I'd have to say that c++11 is the far superior option if you really, truly understand what the compiler is doing to your code (a huge caveat). Unique_ptrs ar…
First you are saying c++11 is the far superior option (with that one caveat) and in the last sentence you imply that C would still be faster.
Can you clarify?
I'll add my opinion too:
I think all the readability you can get out of c++, will be wasted in layers upon layers of object oriented design and C compiles much faster, so there is that.
Re: Why is BIND 10 written in C++ and Python?
#109Earlier quoted context omitted.
Does anyone know of large projects where C++ handles memory allocation failures gracefully? For services that need to stay up and never crash under memory pressure, I would think C is the way to go. It's too hard to reason about control flow with exceptions.
You don't have to use exceptions in C++. You can do stuff the same way as in C by checking the return pointer. I've worked on C++ apps that had built-in garbage collection (basically asset (geometry) paging) for huge amounts of data that would allocate/free/page on demand based on what was going on.
Sure, but then you can't use the standard library or any other libraries. Even a single exception sneaking into the codebase breaks everything.
Re: Why is BIND 10 written in C++ and Python?
#110Earlier quoted context omitted.
>Why doesn't it look good for python? Because it directly contradicts the "only 20% of your code is performance sensitive and the other 80% can be scripting language X" nonsense that scripting language apologists constantly parrot with no evidence. This is a good example of how scripting languages are in fact not well suited to application development, and should instead be used for scripting.
I would argue that BIND isn't "merely" an application: it's almost kernel-level in what it needs to do and how it needs to respond. At a minimum, it's system-level—but definitely not application-level.
There is nothing almost kernel-level about it. It is an application. You seem to be trying to draw a very arbitrary distinction between applications and applications that you want to consider special for no particular reason.