People using Rust will pay a productivity tax

Nah!<p>Using Rust at first was hard, but now I move faster than using F#, Python, Swift, Kotlin. I know, with apples-to-apples, I use the SAME project that I have moved to Rust and still keep parts on that languages (for UI or utilities).<p>The same things that make Rust hard at first, become a &quot;base layer&quot; and a force multiplier.<p>Each time you compile (and lint with clippy for example) your code stay and continue to be robust.<p>Each time more people use Rust, better and more crates with functionality emerge, reducing the surface area of things that need to go elsewhere.<p>And you can refactor, remove crates and add others, even with a totally different API surface, with more confidence and speed that most languages.<p>And more info, and more tutorials, and more SOLUTIONS, with great docs! and tests! and benchmarks! and cross-compiled! that are far easier to apply than most languages.<p>Rust is a force multiplier and the cost pay off and more and more with time.<p>BTW: I&#x27;m a solo developer that support a medium size niche eCommerce app, that need turn-overs measures on minutes&#x2F;hours and at most, days. I mean: 10:00 am a problem, 10:30 am ship code to CI. Repeat all the time.<p>I CAN&#x27;T afford anything that go against productivity and that is the reason I move lang&#x2F;tech each time I see anything, whatever, that give any advantage. ---

The tweet has an arguable assumption, but on the other hand, an important truth:<p>&gt; The future will solve this automagically: people using Rust massively will pay a productivity tax that if not counter balanced by the safety wins will turn into a competitive issue. And most folks are now using Rust where more productive garbage-collected language would be better<p>The core is &quot;most folks are now using Rust where more productive garbage-collected language would be better&quot;. This is very true: GC&#x27;ed languages are nowadays fast and expressive enough that they may covert the vast majority of use cases. Use cases for low-level languages are shrinking.<p>What I find arguable about this tweet is:<p>&gt; people using Rust massively will pay a productivity tax that if not counter balanced by the safety wins will turn into a competitive issue<p>This assumes that there is a significant amount of teams who choose Rust lightly, without assessing its complexity. I think this is not the case, as it&#x27;s a notoriously hard language, and it&#x27;s not an obvious choice (although there is people who suggest it for webdev, which I think it&#x27;s not appropriate, in general). But on the other hand, I don&#x27;t have statistics on this.

This is based on the assumption that Rust will make you move more slowly — anecdotally, it does at times — and that this is a constant slow down.<p>I disagree with that premise. Rust is imperfect, and can seem obtuse when you begin using it. But the payoff is moving faster. It compiles, it works; modulo logic bugs. Less painful refactoring, less time spent chasing memory leaks, none of the bullshit memory bugs, no data races.<p>This isn&#x27;t trivial stuff, and pays off day to day.<p>I also have to object to any argument that says something will be &#x27;automagically&#x27; fixed in the future. It&#x27;s a weak position based on something that _might_ happen.

&quot;The future will solve this automagically: people using Rust massively will pay a productivity tax that if not counter balanced by the safety wins will turn into a competitive issue. And most folks are now using Rust where more productive garbage-collected language would be better&quot;