[quuxplusone]

For anyone like me who wondered what "TCO" is: In this context "TCO" stands for "time-cost optimization," basically the idea that time is money and so you shouldn't be scared of weighing:

- an alternative that costs a small amount of money over a long span of time, against one that costs a large amount of money for just a short span of time

- an alternative that costs money (or time) up front, against one that costs a money (or time) later on

I'm still not 100% sure what "_the_ TCO _problem_" is, specifically; but it definitely has nothing to do with tail-call optimization. :)

[steveklabnik]

Ooos sorry! I meant https://en.wikipedia.org/wiki/Total_cost_of_ownership

[quuxplusone]

Ha! I guess at least "time-cost optimization" and "total cost of ownership" aren't too terribly different. :)

But there's an interesting difference in framing or worldview between the two acronyms: My assumption of "time-cost optimization" assumed that such tasks as debugging were part of _producing_ a software artifact. Our implied goal (just like in the Rust talk's title) was to maximize _production_ of such artifacts at a reasonable level of quality. The back-loaded testing and bugfixing work might go on for a while (if you made that tradeoff), but it eventually ends in a "product" (or in project failure).

On the other hand, "total cost of ownership" emphasizes that our primary job isn't production but _ownership_ of software, which is open-ended and goes on forever. We have to think not only about "How long will it take to get it right?" but (mostly!) about "How costly will it be to maintain, year after year, even _after_ we get it right?"

[steveklabnik]

Agreed! I also was like "... that's not what I meant but that does kind of work, when I read your comment." :)