Are "versatility" and "orthogonality" really expressing something different from "productivity"?

[nikomatsakis]

Is "versatility" really expressing something different from "productivity"? When could they be in tension? When does one take precedence? I think they should probably be combined.

[yoshuawuyts]

orthogonality vs productivity

I feel like about "orthogonality" specifically it describes something internal to Rust's design. Like a measure of the language itself, rather than a measure of the outcomes of using the language. I think a different way to describe "orthogonality" is as a language feeling "cohesive" or "internally consistent". These properties certainly help users become productive sooner, but I think it's different from "productivity" itself. I think "orthogonality" is a key property for evolving Rust itself, and we should think of it as something we want for that reason (design by creating consistent rules, not design by one-off special cases).

Instead I feel like "productivity" is closer to measuring the "speed at which Rust users can achieve their outcomes". "Orthogonality" can help with that, but so can IDE improvements, additions to the libraries, faster compile times, etc. I think this is also broader in a sense - where it extends from "the Rust language" to "the Rust project and all its tooling"?

precedence

In terms of precedence here, I'd probably place orthogonality over productivity because we value our ability to keep evolving Rust in a way we think is good, over short-term productivity benefits. To give an example: back in 2015 we could have chosen to just add typenum to the stdlib to effectively "bless" it. From a pure productivity perspective that might have been a fine thing to do. But we value composition of language features, so we chose to begin development of the "const generics" feature instead.

It took us four years from inception to MVP. Three years later it's still under development. And I don't think that anyone in hindsight would argue we should have just gone and stabilized typenum instead. Which I think shows we're willing to limit short-term productivity, if we believe there is an orthogonal language feature possible which will carry us much further in the long term.

[joshtriplett]

I think "productive" overlaps most strongly with your current axiom of "accessible", to the point that it probably isn't worth noting separately. "We favor APIs that where the most convenient and high-level option is also the most efficient one." and "We aren’t explicit for the sake of being explicit" are closely related to "We avoid designs that will be too complex to be used in practice.", for instance.

I submitted https://github.com/nikomatsakis/rust-design-axioms/pull/9 to help with this.

[nikomatsakis]

I opened https://github.com/nikomatsakis/rust-design-axioms/issues/12 to cover a specific thought in this direction -- basically that versatility should be removed and split into "low-level access/control" and "high-level productivity".

Josh:

I think "productive" overlaps most strongly with your current axiom of "accessible", to the point that it probably isn't worth noting separately.

I see this POV, but I wonder if it's quite right. I think a language that truly put productivity first (over all other things) would make some pretty different choices. Accessible (to me) feels different than productive. I think of accessible as more like...learnable, not too complicated, overhead is reasonable, where productive is more like actively gearing for "minimal effort for maximal results".