Hmmn. I think there's a fundamental advantage in any rewrite that's allowed to drop functionality - even a C++ to C++ rewrite.
It's not just the language. It's the fact that (a) you already have an instantiation of the idea to look at as a reference and (b) you're happily cutting bits off the original. The latter suggests that you're not only not supporting all of the original use cases, you're probably in a nice state of organization where you're free from the temptation to "astronaut" up a more general system than you really need.
It's always nice to have this power, but it shouldn't be confused with the wonderfulness of the language.
ironically, that's not the common experience; the term 'second system syndrome' was coined for a reason.
"allowed to drop functionality", as used by you, is a strawman -- the team _added_ functionality to the part they were rewriting without incurring the wrath of the second system. sure, the line counts are off, but your argument does not stand in the general.
If I remember Brooks correctly, second system syndrome does not refer to all successor systems, and frequently complex/over-built systems spawn elegant ones in turn (oversimplifying a bit, but MULTICS -> UNIX springs to mind). I seem to recall Brooks regarding this as cyclical, with leaner third systems spawning bloated fourth systems, and so on.
i was referring to recent examples such as python 3.0, perl 6, or even, say, apache 2.0. eventually they were usable, but the blood sweat and tears involved did not make for cute blog posts such as the one we're commenting on.
I think a component in a service oriented architecture would lend itself more cleanly to reimplementation, with less chance for "Second System Syndrome", because you still have an api contract you are responsible for.
I think a "released" software, like those you mentioned, would be somewhat more likely to become a stereotypical "second system".
It's not just the language. It's the fact that (a) you already have an instantiation of the idea to look at as a reference and (b) you're happily cutting bits off the original. The latter suggests that you're not only not supporting all of the original use cases, you're probably in a nice state of organization where you're free from the temptation to "astronaut" up a more general system than you really need.
It's always nice to have this power, but it shouldn't be confused with the wonderfulness of the language.