Were Martin and Typesafe as a whole consulted before making this announcement? I would strongly recommend it if it has not already been done. It's just a matter of principle. They have done a lot for Scala - initiatives like this may have a negative effect on them and their vision. They are good guys, and should be consulted as such.

I know that your intentions are good, but this is a terrible idea. Your stated reasoning in no way justifies the pain you are about to inflict on the Scala community.

- As if scala version incompatibilities were not enough, now when shopping for third party libraries we must also determine which fork of scala the library was written against. If it's your fork, and I'm using mainline scala, I am out of luck.
- As if a relative lack of third party scala libraries was not enough, now we have to bifurcate them even further based on which fork the library maintainer decided to go with.
- As if Scala training and on-boarding were difficult enough in an enterprise environment, now there are two variations of the language to explain.

Either be patient and work with TypeSafe, or do a full-break and create your own language. This forking business will kill both of you.

Have you heard of natural selection? Either what he's doing is right (helpful for community and PL advancement in general), or not.

if( miles.isRight && community.writesForHisFork ) { assume( numLibVersions.isLarge ); println( "I would be stupid to not do the right thing just because there is a large number of forks specially if there are people behind this" ); }

if( miles.isRight && !community.writesForHisFork ){ assume( !numLibVersions.isLarge ); println( "well no problem" ); }

if( miles.isWrong ){ assume( !community.writesForHisFork );

I don't see the problem here. If he's write and libraries are compiled for this fork, then pain for developers is not an excuse. Its like holding back going to moon because now people can no longer tell their kids its made of cheese so they have to learn some new distractions for their kids.

Who owns the "Scala" name? Will you still be able to brand your fork as "Scala"? Frankly, if I was the commercial entity / trademark owner I'd prefer to avoid any and all confusion in the marketplace and request the fork to not share the Scala brand name.

This is the first I'm seeing of this, but here are my 2c: as much as I complain about certain aspects of Scala, I personally don't have much interest in spending my free time working on the compiler. I pretty much want to just continue what I have been doing, which is writing code in Scala, and occasionally blogging about it. :) I wonder how other people feel.

Even though I'd like to see some of my complaints about Scala addressed, if a fork is to be successful, it needs a critical mass of people with capacity and willingness to commit serious time working on it. Does that critical mass exist?

Hi Paul,
I guess the thing is how to determine when and if critical mass can be reached.

Why a compiler fork rather than a compiler plugin?

A compiler plugin is very constrained in what it can actually do, for example he can not do anything about the syntax.

There exists already some compiler plugin (like kind projection from Erik) to solve some issues, but they are quite limited.

A fork of the compiler will allow such syntax improvement to be implemented.

Just for the record, it's possible to both change syntax and the type system from within compiler plugins. It's just not pretty. However, if there are real use cases, then there's good probability that the compiler plugin interface might change from requiring non-pretty hacks for these things to having something available naturally: https://github.com/typeleve....

Syntax changes

De-javaize it, and at the same time make it purer? I applaud. My personal request: Set should not have head (neither should List).

"In this context it should be easy to see that for them [Typesafe] an emphasis on Scala as a complement to Java, rather as its successor, is paramount."

It seems like you are implying that there is a conflict between being complement to Java and strive to be successor of Java. I don't think this is the case,
I think that if you want to be the successor of Java in the long term, you have to be a complement to and be interoperable with Java in the short term.
I don't know if Typesafe have the long term goal of succeding Java, but if they have I think they are doing the right thing with focusing on the JVM and maintaining strong interoperability with Java.

(I don't see any good reason for having Java support in Akka and Play though, other than the commercial interest from Typesafe.)

For me, as developer and software architect in a small company which has been using Scala for our main product for three years, Java compatibility is essential. We want to be able to run on the JVM, since it is an excellent runtime no matter which language you use. And we want to leverage the vast ecosystem of 3rd party libaraies and frameworks which exist for Java. Mixing Java and Scala source code in the same project is less important, but we really want to be able to smoothly use 3rd party Java libraries and frameworks from our Scala project.

It would be great to send the representatives of the major user groups, such as SF Scala and Spark Users, to the steering committee. Since Martin welcomes this, a holistic and democratic approach is needed... A foundation will probably need physical meetings and a standing body to work. Meetings can be timed with conferences, an office may or may not be needed. Budget, volunteers, forums, etc. A very timely move, thanks Miles!

On the one hand I'm nervous about the impact of the split on the community. On the other, it's very encouraging that the community has grown large enough to support a fork, and it sounds like you have the issues well in hand. Something that might be helpful to write is a sense of what the commitment to the non-profit foundation would be -- I imagine there are many people with a deep vested interest in the future of Scala who have never been part of a foundation before. (Though hopefully there are also people with experience of running such things involved.)

Does this mean that scalaz will depend on the typelevel compiler or that there will be two different versions of scalaz?

Will there be binary compatability with Scala compiled against the typesafe compiler?

I would really worry that the 'scalac' branch would stagnate while the other would flourish, and that's a huge bummer. I'm seeing more companies using scalaz right off the bat with scala adoption, (including the company I'm consulting at), I don't want to give the naysayers any more amo of why scala/scalaz shouldn't be used.

This sounds like a nightmare to maintain. Scalaz could use source-level extensions (say type lambdas) without needing to fork, couldn't it?

Problem description:

" we continually find ourselves running up against limitations of current Scala. Sometimes these limitations are minor and amenable to simple workarounds, many of which have passed into Scala folklore. Other limitations are more serious and can only be worked around with cumbersome encodings or otherwise elaborate and confusing hacks. These have the unfortunate consequence that elegant solutions to important problems are obscured..."

so the solution is to continue doing that on one branch, and also to have an additional, more elegantly coded branch? Are you trying to give people less work or more work?

Why just not come up with different name? Not using Scala one?

any chance of replace hotspot for avian vm??..avian seems more suitable for functional programming and needs smart people like you

The usual concerns about bifurcating the ecosystem seem less worrisome to me in this case since the Typesafe folks have already declared that in a few years they are going to put out a new release that breaks some things. DOT is a playground for that work. OK, so now we have *another* playground for some more bright folks with their own itches to scratch. If the two camps can get along well enough, I could see that future release taking the best ideas from both playgrounds. So hey, have a better way to do a collections library, or some other improvement? Awesome -- now is the time to showcase it! No?

I'd be happy with this if you think that the scala community will not dichotomise completely into java and pure FP camps. I'm not too bothered about syntactic sugar for type lambdas but I am very bothered about the fact that monads are either slow via trampolining or they don't scale (discussed by Ed Kmett - http://www.reddit.com/r/sca.... This seems to me to be fundamental. Can anything at all be done about this given the current state of the JVM? If not, is it worth the effort?

If this can take scala towards a naturally dependently typed language (a la idris) which can be used for actual running code, it would be very welcome.

Am I correct when I say the following?

===
This fork is an alternative to forking the Scala compiler individually. We can collaborate on improvements to the Scala compiler from the Typelevel standpoint. This fork allows us to focus on fixing problems / annoyances that Typelevel developers run into. Once changes become stable and feel like an improvement to the language we can, with more confidence, provide pull requests for the Scala compiler.

A great benefit of doing it like this is that we represent a sub-set of Scala stakeholders and as such can more easily prioritize. Instead of doing this individually, we form a group with shared goals.
===

After writing the above (assuming it's correct) one of the most important things Typelevel should do is outline their vision and their most important goals. That allows individuals to determine if this is the fork they want to collaborate on. I can imagine a future where like-minded groups create their forks for the Scala compiler to work on issues they collectively find most important.

News of this effort is nothing but great for Scala (and, in my opinion, for Typesafe). Merge compatibility is enough to allay my fears that this will result in my having to make an across-the-board, irreversible decision to use the Typesafe vs Typelevel toolchain at the start of a new project, or that the practical effect on my use of Scala in general will be drastically different given either decision. I'm very excited to follow the effort, and to participate if there's an opportunity for a mere Scala mortal.