propensive

We discussed this with Typesafe and Martin in advance of the announcement for exactly that reason. Notwithstanding the reasons for forking the compiler, the last thing we want to do is fork the community too. This is a community project, and Typesafe are a large part of that community!

I think there is a lot of Scala usage you perhaps don't see. As an example from the corporate world, at least six major international banks (probably more) are doing a significant amount of their development in Scala, some with teams in the hundreds. That's a solid market for Typesafe right there, which isn't going to go away overnight, and won't be stirred by the existence of the Typelevel fork of Scala. Furthermore, they should benefit from its existence because it represents a means for more people to be able to contribute to and enhance the language, without negatively impacting the stable, reliable releases from Typesafe.

Don't focus too much on the relevance of the Typelevel fork to the Typelevel libraries. The people involved (myself excepted) work on the Typelevel libraries, and consequently have particular interest in the features they benefit most from. But the fork, and the infrastructure around it, is for the benefit of the entire community, not just Typelevel. We'll happily entertain PRs for any useful language feature, provided it meets the compatibility requirements.

We've tried to avoid creating a "drama"; that's not the intention at all. But we want to attract other developers to our experimental fork, so that if you want to use new and exciting features, or contribute your own, you don't have the entire burden of maintaining your own fork. The hope is that the Typelevel fork will gain enough critical mass to encourage people to develop new language features where they previously wouldn't have bothered, due to the high costs involved (in terms of maintenance) and limited returns. It really is meant to be a community effort.

Compiler plugins are powerful, but still too limited. We can't change parsing rules with a compiler plugin, for example. There are also potential compatibility issues with using some set of compiler plugins, and there's a performance penalty of implementing new features with plugins (which, by their very nature, are optional), rather than in the core compiler.

I don't understand what features they want to add beyond type lambda's, singleton types, and literals for bytes / shorts.

We have more ideas on the table beyond these three, but Miles will go into more detail about these in his next blog post.