
Typesafe’s Commitment to the Scala Ecosystem - SanderMak
http://typesafe.com/blog/typesafes-commitment-to-the-scala-ecosystem
======
virtualwhys
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.

~~~
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!

~~~
jroesch
I think this will be great for the community. I didn't realize that you were
involved as well Jon, should be interesting to see what comes out of it.

------
flurdy
For reference this is a response to Typelevel's announcement yesterday:
[http://typelevel.org/blog/2014/09/02/typelevel-
scala.html](http://typelevel.org/blog/2014/09/02/typelevel-scala.html)
[https://news.ycombinator.com/item?id=8258255](https://news.ycombinator.com/item?id=8258255)

~~~
theboywho
Typesafe apparently knew about the fork and agreed on the direction before
Typelevel's annoucement.

So it seems to me more like a "joint" announcement than a response.

------
programminggeek
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.

------
DCKing
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.

~~~
bad_user
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.

~~~
DCKing
> Scala.js is not a fork

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.

------
thescrewdriver
The bleeding edge fork/branch isn't all that interesting to those of us using
Scala in production, but it might be useful for experimentation.

~~~
lmm
I'm using Scala in production right now and partial type application could
really simplify some of my code.

------
CmonDev
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.

~~~
gilbertw1
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.

Edit:

This link has some good info in it:
[http://visualstudio.uservoice.com/forums/121579-visual-
studi...](http://visualstudio.uservoice.com/forums/121579-visual-
studio/suggestions/2228766-add-higher-order-generics-to-f-type-classes)

Looks like the CLR can't represent higher kinded types at runtime using the
reified type system.

~~~
seanmcdirmid
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.

------
qwerta
I had some small exposure to ScalaC and IDE. Miles is great developer, I think
scala can only benefit from this.

