[throwaway894345]

> It's better to have something slow and correct to optimize, so writing it first time round in a slower language isn't a bad thing.

It's better to have something that's fast and correct the first time. Rewrites are typically prohibitively expensive, and we're not getting anything from using a slow language (negligible productivity gains vs Go, for example). Moreover, there isn't much room to optimize with Python for many applications--you can't always subprocess or rewrite in C because the de/serialization costs will eat any savings from parallelism or C. Not to mention increased complexity.

[dragonwriter]

> Rewrites are typically prohibitively expensive,

Big bang rewrites are (and, moreover, tend to lose correctness from the source), Ship of Theseus ones are not and do not have that tendency. If you can do component-wise replacement, then fast-to-develop and correct but suboptimal performance is a better deal than anything which trades off either of the others for performance.

[throwaway894345]

It's feasible, but it's still very costly. And again, there's no reason to pick a language that is going to force you to do a rewrite (incremental or not) when there are languages that offer good performance and good iteration velocity.

[mercer]

In practice 'good iteration velocity' is often dependent on using a language/stack that you and/or your team is comfortable with and proficient in.

When one can choose between multiple equally-mastered stacks, then choosing the most appropriate/performant one is perhaps a good choice. But even then there are other things to consider.

For example, I worked for a startup where my ideal choice would've been a performant stack that I'm pretty good with (Elixir/Phoenix), but we ended up going for Python/Django because the founders felt that 1) it would be easier to find more programmers locally, and 2) apparently some investors do care about this. Both seemed like valid reasons to me.

[throwaway894345]

> In practice 'good iteration velocity' is often dependent on using a language/stack that you and/or your team is comfortable with and proficient in.

This is true, but some stacks impose such a high cost that the costs exceed gains from familiarity. Basically you need to evaluate the savings of switching to a better stack and how long it's going to take before that savings equals the cost of switching to the new, less-familiar stack. For greenfield projects, the cost of switching is just the opportunity cost of slower initial development velocity while the team learns the new stack; for existing projects, there may also be the cost of rewriting in the new stack, which quickly becomes prohibitive.

[dragonwriter]

Every maintained project is a continuous Ship of Theseus rewrite, but yes, if there's a language your team is more productive at writing correct code in and that provides better performance, there's an easy choice to make. That's very often not the case, though, and as well as team it's often project scale dependent, and projects often start at a scale where the calculus is very different from where it might be years down the road.