Refactoring in a dependently typed language is hard. There's room for improvement. Scala-refactoring is a great example of community contribution.
Scala style checking is on our roadmap for 2.12. I'm procrastinating reviewing the first PR for the tool (abide) right now.
Finally, I would like to clarify we are doing everything we can think of to encourage the community to help shape the design and implementation of Scala. We publish roadmaps, review (and even rework) community PRs, do most of our team comms publicly (we are a distributed team), solicit proposals for language changes (e.g., http://docs.scala-lang.org/sips/pending/42.type.html). We spun out library modules that are now being maintained by the community. I spent last year simplifying the core build, so that we can move to a standard sbt build this year, which should also make it easier to contribute. As a first step towards updating the [spec](http://scala-lang.org/files/archive/spec/2.11/), we converted it to [markdown](https://github.com/scala/scala/tree/2.11.x/spec).
That said, I think it's only natural that the Scala committers on Typesafe's payroll are more inclined to work on customer support issues / internal Typesafe support. We always try to strike a fair balance to give back to the community.
Please let me know how we can do better, here or via contact info in my about.
First, the agreement:
Yep, structs are a VM thing. We are very excited about Project Valhalla (http://cr.openjdk.java.net/~briangoetz/valhalla/ etc).
Refactoring in a dependently typed language is hard. There's room for improvement. Scala-refactoring is a great example of community contribution.
Scala style checking is on our roadmap for 2.12. I'm procrastinating reviewing the first PR for the tool (abide) right now.
Finally, I would like to clarify we are doing everything we can think of to encourage the community to help shape the design and implementation of Scala. We publish roadmaps, review (and even rework) community PRs, do most of our team comms publicly (we are a distributed team), solicit proposals for language changes (e.g., http://docs.scala-lang.org/sips/pending/42.type.html). We spun out library modules that are now being maintained by the community. I spent last year simplifying the core build, so that we can move to a standard sbt build this year, which should also make it easier to contribute. As a first step towards updating the [spec](http://scala-lang.org/files/archive/spec/2.11/), we converted it to [markdown](https://github.com/scala/scala/tree/2.11.x/spec).
That said, I think it's only natural that the Scala committers on Typesafe's payroll are more inclined to work on customer support issues / internal Typesafe support. We always try to strike a fair balance to give back to the community.
Please let me know how we can do better, here or via contact info in my about.