This was so well written that, given the timing, one wonders if it hadn't been written in advance (read: Typesafe and Typelevel discussed the issue and came up with appropriate spin to mark the occassion a positive rather than a community splitting negative).
I certainly hope it's the former: Typelevel speeds up the innovation/wart removing front while Typesafe continues on with their slow and steady roadmap, thus appeasing industry deep pockets.
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'm sure it was at least thoroughly considered in advance. I'm sure Miles Sabin's announcement of interest in forking [1] on the 25th did not escape Typesafe's notice. I'm sure Odersky's got to be a little bit anxious about a fork, but I'd bet he's pretty relieved to hear that they want to keep it significantly interoperable, and maybe even a little bit excited to gain a sandbox for faster innovation than Typesafe can achieve.
Checkout impromptu meeting of the "ScalaWags" recorded last night [1]. As usual it's a bit of a meandering, relaxed discussion, but they do manage to get on point at times re: Typelevel forking Scala and other issues pertinent to Scala's future.
I think this is what grown up open source looks like. People worry about forks and community and so on, but at the end of the day that's kind of the whole point of open source. Everyone can fork and change and experiment all they want. This is a good thing for Scala and it's a sign of a healthy project that someone would have need to fork it IMO.
I'm on the fence about whether the fork in the ecosystem is such a good idea. Their argumentation is that there already exist Scala forks which haven't divided the ecosystem at all. That is true, but if you take a look at these forks it is easy to see why they haven't. Each of them is focused on a singular purpose, such as improving DSL writing or compiling to JavaScript. They do not compete with the Typesafe compiler at all. This fork on the other hand looks like it will be far more general purpose and therefore be usable in many of the same places the Typesafe compiler is used. That means it will compete against the Typesafe compiler and will divide the ecosystem.
I don't doubt that Typelevel's fork will contain important work helping Scala forward. But I think it will divide the Scala community, and that cannot be a good thing.
Scala.js is not a fork, but a SBT plugin that reuses Scala's compiler front-end - which is brilliant because it takes much less effort to upgrade it to newer Scala versions, compared to similar efforts of other languages.
On dividing the community, well, that's always the nature of open-source, but it's a virtue - after all, the ability to fork is a prerequisite for joining. And it can be argued that the Scala community is already divided between people that want a language closer to Haskell and pragmatists coming from other languages like Java, or Ruby, or Python, or whatever (and I'm in the later camp), so a fork could mean that the people wanting more type-safety in Scala, instead of bitching and moaning about it, could put their energy towards making actual improvements that could benefit everybody and that could end up being merged.
At the very least right now the goals are to keep binary and merge compatibility and there are signs of willingness to cooperate between Typesafe and Typelevel. That's a good thing if it holds. If not - well, market forces will pick the winner.
My comment is more of a response to the original Typelevel fork announcement, which specifically mentioned Scala.js as evidence that their fork wouldn't do much harm. It's a pretty bad argument they're making in the first place, but it's even worse given that Scala.js is not a fork.
> On dividing the community, well, that's always the nature of open-source, but it's a virtue - after all, the ability to fork is a prerequisite for joining.
Yes, forkability of a project is a virtue on its own. But the act of forking a project is not necessarily virtuous, which is why I have my doubts on this.
I hope they hold true to their promises. It would be a shame if Shapeless' focus would leave Typesafe's Scala behind (intentional or not), which seems a plausible consequence.
I'm not so concerned. Because it will remain binary compatible, people will be able to choose which language version to use on a library-by-library basis (as is the case today). So it's a lot different from, say, trying to mix two versions of Python. As long as the APIs remain presentable in both forks, it may end up being fairly transparent to the end user.
Merge compatibility is an even bigger bonus, as it should actually help push along the Typesafe compiler, in parallel with the feature roadmap Typesafe is focusing on, because we'll be able to see innovations actually working in production to prove them out.
The only big question mark to me is what this foundation will look like, and whether it can meaningfully contribute to the ecosysytem.
Maybe at least they will be capable of finishing the CLR version? It would be awesome to have a C-friendly and functional-friendly language that runs on both VMs.
If I remember correctly the CLR implementation of Scala was scrapped because there were some limitations with the CLR's reified generic type system that made it impossible to express scala's type system.
I even believe that Microsoft research tried to find a solution for a while, but were unable. I'll try and find some references if I can.
It kind of worked (I actually used it), but I don't think there was enough interest in it. Java is clearly dated on the JVM, but C# isn't that bad, and there is also F#. The CLR just doesn't need Scala as bad as the JVM did (and vice versa). There was never going to be a strong ecosystem there, even if there was a perfect version of scalac working.
You can easily erase to the CLR like you can on the JVM, the only issue is interop with .net APIs that use generics, of which this mostly means LINQ.
The JVM doesn't directly support higher-kinded types either. It might be a pain to come up with a scheme that interops nicely with other .NET languages, but in principle there doesn't seem to be anything that would make it impossible to build a Scala compiler for .NET (though it might involve lots of boxing and downcasts).
I certainly hope it's the former: Typelevel speeds up the innovation/wart removing front while Typesafe continues on with their slow and steady roadmap, thus appeasing industry deep pockets.