[tutfbhuf]

I do not wonder about the double productivity increase compared between Rust and C++. But what really makes me wonder is the comparable productivity of Rust vs. Go. I thought Go is much easier than Rust and that people could write applications much faster in Rust. I would expect that Rust takes at least 2-3 times more time to write an application, compared to Go, but then I would also expect it to run at least 2-3 times faster than the Go version, hence it is a fair trade-off.

[ttfkam]

If you write Rust where you copy all the time instead of borrow, it can save you enormous amounts of time with arguably minimal performance degradation. This can make up a lot of the perceived time disparity between Go and Rust, and leave C++ in the dust. (Yes, I know C++ can copy as well, but in my experience, it can be very difficult to teach old C++ devs new habits.)

After you've profiled your working code, you can go back and optimize with less copying, more borrowing, and other optimizations where it matters.

Go has the same issue. After it's working, you go back to profile, and those optimization steps can often take longer than original development. (Which is why you profile before optimizing.)

With C++ you must add on time to catch all the memory access bugs and fix them, which is time you don't have to take in Rust and Go due to the borrow checker and garbage collector respectively.

In Go you have to find all the spots where you didn't check the error return code or other unhandled branches, hopefully before deploying to prod. This is time you don't have to take in Rust since it catches these errors during compile.

The advantage of Go is that the typical path is easier, the learning curve is much shallower, and its orders of magnitude faster to compile leading to faster dev feedback loops. On the Rust side, you've got a longer learning curve, and you really have to actively resist the urge to prematurely optimize.

[steveklabnik]

I don’t mean this post to be about Go; I have never written significant amounts of Go and have no opinion on its productivity.

Productivity in Rust is difficult to talk about, because of differences in opinion and what I like to call “the TCO problem.”

Because Rust is hard to learn, a lot of folks assume it’s that hard all the time. Which means they assume things take just as long for a new Rustacean as they do an experienced one. This is generally not the case. Once things click and you’re over that hump, it feels like programming in any other language. If there are similar libraries available and I don’t need to create the world from scratch, I am just as productive in Rust as in other languages that also have those libraries, generally.

But that kinda leads into the other thing I alluded to; a lot of people think of “productivity” as “whatever lets me see something quickly.” But this doesn’t capture real prodctivity, in my mind, which includes the total development time, aka, how many bugs do I have to deal with later. Rust moves a lot (but not all, of course!) of this up front. Which can feel like it slows you down (but again, with experience, I find this is actually kinda minimal), but then you save time on the back end by needing to debug less. This means that robust features end up being developed more quickly than in some other “productive” languages I’ve used in the past.

TL;DR things aren’t simple, and “fast to get going” doesn’t inherently mean “productive.”

[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." :)