Setting our vision for the 2017 cycle

[withoutboats]

I'm glad you've expressed your thoughts with so much precision; it makes it much easier to see where I disagree.

@nrc

My interpretation of Rust's value proposition is that it begins with performance (you only use Rust if you need high performance), but our distinction (once you are in the realm of high performance languages) is that you get vastly superior productivity. In particular, I think safety (whilst important) is really just one aspect of productivity. Safety means you spend less time debugging, in particular at late stages in the engineering process where debugging is very expensive (e.g., once software is released). It makes sense to me, therefore, to really concentrate on how we can make Rust users more productive, throughout their engineering processes.

(emphasis mine)

I don't agree with this at all! I think correctness - which is broader than 'safety' - is one of Rust's key selling points, and honestly should be pushed more. Rust code is performant, productive, and correct; its this whole trifecta that is so compelling. I think we should be messaging more about how Rust helps avoid bugs (not only low level safety issues, but high level bugs as well).

I also think when evaluating features we should be asking how they impact Rust's 'correctness property.' That is, is this feature going to lead users to write code with bugs, even if they aren't memory safety issues, or will it steer users away from common pitfalls? Examples of features that I think are advantageous to Rust's correctness property are - exhaustive matching, Result error handling, and the emphasis on parametric polymorphism over subtyping.

---

@nrc

More expressivity in the language (e.g, HKT, int generics)

It would certainly be nice to improve here, but there are so many more important things to work on.

I think more expressivity in and of itself is not a good goal - in fact I think expressivity has certain costs and isn't unambiguously a good thing to pursue given infinite resources - but I think enhancements in expressivity will be a good avenue toward producing the kinds of killer frameworks and libraries that will make people want to use Rust (this is especially true in the server space). I think this should be driven by what feedback from library authors shows is really badly needed, rather than just importing type system features from other languages.

I think the focus here has been pretty good - specialization is easily the most important type system extension in my experience, and its the one that's actually implemented.