> (Which makes sense, given that Mozilla's Servo rendering engine also has the goal of being that kind of software.)

Web browsers are not that kind of software. The web is evolving much faster than any of the other things you mentioned. New features get proposed every year, and you just have to deal with it and implement them, even if they complicate the implementation of the browser. Even if you cut that off, you still have to deal with the horrific mess that is the cumulative total of past web-related decisions.

A rendering engine is not, itself, a web browser. (You might be thinking of a higher-level component, like Chromium's Embedded Framework? Not the same thing as a rendering engine.)

There's certainly a layer of a rendering engine—the part that translates a CSSOM into rendering pragmas—that changes a lot over time. But rendering the resulting pragmas itself doesn't change much, and features requiring new pragmas come about remarkably slowly.

I definitely know the difference between a browser and a browser engine; I worked on both WebKit and Servo. There's much more to a browser engine than rendering alone, and rendering isn't even the most complicated part of a browser engine. Outside of rendering and JS there's a steady stream of new DOM APIs, and that's the part that is similar to the "agile user-story kanban".

Yes? It sounds like you're agreeing with me, and disagreeing with your own GP comment. Or maybe I misunderstood the point of your GP comment—it sounded like you were trying to use some sort of metonymy to equate Firefox/browsers in general with Servo, as an implicit counterargument to my GGP post in the sense of "it'd be bad to write a browser in Rust for [reasons you gave]; a rendering engine is part of a browser; a rendering engine thus has the same lifecycle as the browser itself; and thus, a rendering engine is not actually a good example of a good use-case for Rust, despite Mozilla's ambitions. QED."

Clearly, though, you know what a rendering engine is, so I'm not sure what your argument in the GP post was. Was it just a tangential statement (i.e. "rendering engines are well and good, but it'd be silly to write the browser itself in Rust, for [reasons]"), rather than a rebuttal...?

So we're in agreement that we should reimplement Chrome in Perl, then. :)

As a Perl programmer I'm not sure whether to laugh or cry. ;)

"Why must productivity be measured in "smallest amount of time to write your feature"? Why not in "smallest Total Cost of Ownership [in man-hours] of the feature over the project lifecycle"?"

In the case of startups, their goal is to sell out way before the maintenance phase of the lifecycle. So, it doesn't really matter to them so much as quickly getting out working features. In other cases, esp long-lasting endeavors, then this is a good point to consider.

> In the case of startups, their goal is to sell out way before the maintenance phase of the lifecycle.

Or grow so quickly that replacing most the legacy code from a year or two ago is not a significant hurdle at their new size.

In this vein, I wonder if there's actually a third path that might be better than both. Using a low-level but fairly expressive and strongly typed language but very loosely, such that it allows you to iterate fact but with less performance, and you can come back later and replace chunks as needed, but with the same language. I don't have any real experience with that, and I could see it going either way for a number of reasons, but it seems like we have more languages that might fit that criteria now (or at least they are more popular now) than we have previously.