5 ms·

What's the history behind this fork and what is it likely to mean in terms of fragmentation? In particular what are the irreconcilable beliefs on each side that

What's the history behind this fork and what is it likely to mean in terms of fragmentation? In particular what are the irreconcilable beliefs on each side that have led to this? I haven't tried Scala yet, but my gut reaction is I should stick with Clojure until the dust settles. A fragmented community around a relatively niche language is never good.

pkinsky 12y ago
It's not a niche language. Household names including Twitter, Meetup, Foursquare, and Coursera run on Scala.
- willismichael 12y ago
  According to Cedric Beust, it's still a language that "pretty much hardly anyone uses". http://beust.com/weblog/2014/05/11/more-about-language-popularity/#comments http://beust.com/weblog/2014/05/11/more-about-language-popul...
  - frowaway001 12y ago
    Yes, let's cite this guy who is "so uninterested in Scala" that he spends an considerable amount of time maintaining multiple user accounts to spread FUD about the langauge in various places and makes up stories about how "his team/group/company/... was trying to use Scala but abandoned it due to all the horrible issues with it". You know that he is really persistent (despite claiming that he doesn't care about Scala) when the community starts maintaining a list of his sockpuppet accounts.
  - jroesch 12y ago
    Anyone who tries to make the claim that "pretty much hardly anyone uses" is standing on shaky ground. It definitely has not surpassed Java in popularity but it seems to be quickly gaining traction at lots of large companies and is being used more and more. I was recently at Scala by the Bay in San Fransisco and it seems each year more and more companies are on board. If LinkedIn, Twitter, PayPal, Cisco, Verizon, and more are all using Scala I would hardly call it a niche language anymore.
  - pkolaczk 12y ago
    There are a few really big and impactful things already implemented in Scala, and some companies may be using it without even actually writing any Scala code (for they provide Java APIs): Play, Kafka, Spark, Akka.
ssmoot 12y ago
As someone who's been using Scala for the better part of a couple years: This seems more like a more ambitious version of the Shapeless and ScalaZ libraries (with some of the same crowd/authors). I (and I suspect most people who program in Scala for a living) don't use those libraries. Not because they're in any way bad. But there are trade-offs using them IME. The biggest being compile-time. So I get by fine without. I think this is probably generally good news. In the same way that (I believe) JRuby pushed MRI forward and popularized the case for a multi-threading VM, more advanced type features in this fork probably benefit the Scala community as a whole. I certainly don't see how it could be harmful. Typesafe isn't going away. The vast majority of businesses will still use their compiler. If you didn't use the advanced-type-based-libraries before, this news probably isn't going to impact you anyway. So from where I'm standing, having made a late 2.9 to 2.10 transition, and now having made several 2.10 to 2.11 transitions, Scala seems a very mature language/platform to me. Libraries are generally upgraded fairly quickly, and source wise, those releases broke very little (2.11 being the biggest culprit just because of the modularization effort, but that's pretty trivial to resolve). I dunno. It's not Java. But it's not Ruby either. It's gotten new features since 2.9, but it's broken or changed very little. I find working with it, even working through upgrades, very stable and mostly frustration free.
- runT1ME 12y ago
  As someone involved in the scala community (and scalaz) community, I'd say about 60% of the companies I talk to at the various meetups use at the very least #scalaz. I was pleasantly surprised.
  - jghn 12y ago
    Could this be a biased sample though? Not saying this is the case but it seems logical that the people at the scala meetups are cut from a cloth that would make them more likely to be using things such as scalaz. I know that my local scala meetup seems to be more heavily oriented towards the functional end of things than the bulk of the scala developers I interact with. OTOH, perhaps the bias is with my sample.
Shamanmuni 12y ago
The fork means nothing dramatic. I'll make a short summary of both positions: Typesafe: we need to offer our clients a good guarantee on stability and compatibility with Java 8 or they won't take Scala seriously. So, for the moment we won't introduce new features or make big changes in the compiler. Typelevel: we are OK with compatibility and stability, but there are some features that we really want which either don't exist or are a bit quirky with the current compiler. So we will make a fork in which we can add these things while staying binary and merge compatible with yours. If they make it work, this is great news. There wouldn't be fragmentation as "bleeding edge Scala" would be binary and merge compatible with "stable Scala". And nobody should have hurt feelings, both positions are completely sensible.
VLM 12y ago
By analogy its not terribly far off from Debian issuing a "testing" branch off "unstable" a couple years or decade ago. Its a little more extreme than that, but not much. Usually forks are more dramatic. This isn't MariaDB or something like that. For PR reasons they probably should have stolen the Debian "testing" vs "unstable" names instead of getting all forky which is scarier sounding.
lmm 12y ago
> What's the history behind this fork and what is it likely to mean in terms of fragmentation? In particular what are the irreconcilable beliefs on each side that have led to this? What I've managed to put together, corrections welcome: Typesafe has been moving to stabilize Scala, primarily to make it more attractive to enterprise clients. Prior to 2.10, even point releases broke binary compatibility; now compatibility is maintained for those and they're making efforts to make minor releases binary compatible. The tooling they've produced and the testing framework that builds all the major libraries in the ecosystem and checks for binary compatibility means they now have quite possibly the best binary compatibility regime of any language. Typesafe recently published a roadmap for the next few releases, saying that the next release would focus exclusively on Java 8 support and remain compatible with the current release. This means work to merge any new features won't even start until January 2016, and those features are unlikely to be in an official release until 2017. Less frequent and more compatible releases are what a lot of people have been asking for, and it would be very awkward to maintain Java 8 and pre-Java 8 releases of Scala. So the typesafe position that there can be no new features in the release that introduces Java 8 (so that people will definitely be able to switch to Java 8 without making any code changes) makes a certain amount of sense. At the same time it's meant Scala's getting "frozen" in a bit of a weird state; macros were a recently-introduced experimental feature and the official version is kind of half-finished (there's a branch with a more complete version). And there are a couple of features that are quite small and simple but would be a tremendous help for the kind of code the typelevel guys work on (e.g. partial application of types would be a very simple syntactic rewrite, and there's already an implementation as a compiler plugin), and there's long been a feeling that they were coming as soon as we figured out the little details - so to then be told that we won't see these features until 2017 at the earliest was a bit upsetting. So there was a bit of consternation among the typelevel folks - a group who maintain some quite abstract and powerful libraries that tend to push the type system a bit further than most user code. Some of them started seriously talking about porting their libraries to one of the smaller, more experimental languages with a more elegant type system (Idris, Ermine, or I forget the other option). At the same time, the Scala community now has a lot of expertise in maintaining binary compatibility across quite complex changes, so at some point Miles came up with this idea. I don't think a fork would have happened otherwise - most of the goals can be achieved by compiler plugins (at the cost of being harder to maintain), and if they were going to break compatibility they might as well have jumped all the way to another language. But if the typelevel guys can pull off this "conservative fork", where they'll use their own compiler to compile their libraries but those libraries will then be binary compatible with "vanilla" scala and usable by ordinary scala users, then they get the best of both worlds. It's ambitious, but I hope it works out. > I haven't tried Scala yet, but my gut reaction is I should stick with Clojure until the dust settles. A fragmented community around a relatively niche language is never good. If they're maintaining binary compatibility then that should keep fragmentation to a minimum. Honestly I don't think this changes much compared to how it was with compiler plugins - if you're building some super-duper-typey project with these advanced features then maybe you'll muck around and use this forked compiler, but if you're a normal user then you can ignore it and carry on using their libraries without noticing any different. Plus even if the Scala community were to split in two, I think either half would be bigger than the Clojure community.
kamaal 12y ago
>>In particular what are the irreconcilable beliefs on each side that have led to this? I'm not familiar with this one. But in general most of these forks are generally out of personality clashes where one person just refuses to take another as the boss. Scala is still not among the top languages used in the industry. This kind of my way or the highway attitude will only fragment the already fragile ecosystem. Imagine any serious software shop wanting to use Scala reading this. If I want to be writing an enterprise application which I plan to keep running for the next decade, should I be choosing a language which isn't just not widely adopted, but the existing ecosystem itself has forks because a few members don't give two hoots about stability(Which is far more important to 99% of the software shops out there, than adding new features). Instead of doing something like this, and putting your broader community of users in perpetual confusion as to which ecosystem to use, you could rather contribute to something meaningful.
- frowaway001 12y ago
  Sometimes it's useful to read the blog post before commenting.
  - kamaal 12y ago
    I did, and its the same template story always. We don't agree with technical decisions made by Set A people to be in best interests of the community, therefore we plan to fork Y, with intelligent Set B people. The actual story is always about control and ego.
    - frowaway001 12y ago
      You really didn't read it.

pkinsky 12y ago

It's not a niche language. Household names including Twitter, Meetup, Foursquare, and Coursera run on Scala.

willismichael 12y ago
According to Cedric Beust, it's still a language that "pretty much hardly anyone uses". http://beust.com/weblog/2014/05/11/more-about-language-popularity/#comments http://beust.com/weblog/2014/05/11/more-about-language-popul...
- frowaway001 12y ago
  Yes, let's cite this guy who is "so uninterested in Scala" that he spends an considerable amount of time maintaining multiple user accounts to spread FUD about the langauge in various places and makes up stories about how "his team/group/company/... was trying to use Scala but abandoned it due to all the horrible issues with it". You know that he is really persistent (despite claiming that he doesn't care about Scala) when the community starts maintaining a list of his sockpuppet accounts.
- jroesch 12y ago
  Anyone who tries to make the claim that "pretty much hardly anyone uses" is standing on shaky ground. It definitely has not surpassed Java in popularity but it seems to be quickly gaining traction at lots of large companies and is being used more and more. I was recently at Scala by the Bay in San Fransisco and it seems each year more and more companies are on board. If LinkedIn, Twitter, PayPal, Cisco, Verizon, and more are all using Scala I would hardly call it a niche language anymore.
- pkolaczk 12y ago
  There are a few really big and impactful things already implemented in Scala, and some companies may be using it without even actually writing any Scala code (for they provide Java APIs): Play, Kafka, Spark, Akka.

ssmoot 12y ago

As someone who's been using Scala for the better part of a couple years: This seems more like a more ambitious version of the Shapeless and ScalaZ libraries (with some of the same crowd/authors). I (and I suspect most people who program in Scala for a living) don't use those libraries. Not because they're in any way bad. But there are trade-offs using them IME. The biggest being compile-time. So I get by fine without. I think this is probably generally good news. In the same way that (I believe) JRuby pushed MRI forward and popularized the case for a multi-threading VM, more advanced type features in this fork probably benefit the Scala community as a whole. I certainly don't see how it could be harmful. Typesafe isn't going away. The vast majority of businesses will still use their compiler. If you didn't use the advanced-type-based-libraries before, this news probably isn't going to impact you anyway. So from where I'm standing, having made a late 2.9 to 2.10 transition, and now having made several 2.10 to 2.11 transitions, Scala seems a very mature language/platform to me. Libraries are generally upgraded fairly quickly, and source wise, those releases broke very little (2.11 being the biggest culprit just because of the modularization effort, but that's pretty trivial to resolve). I dunno. It's not Java. But it's not Ruby either. It's gotten new features since 2.9, but it's broken or changed very little. I find working with it, even working through upgrades, very stable and mostly frustration free.

runT1ME 12y ago
As someone involved in the scala community (and scalaz) community, I'd say about 60% of the companies I talk to at the various meetups use at the very least #scalaz. I was pleasantly surprised.
- jghn 12y ago
  Could this be a biased sample though? Not saying this is the case but it seems logical that the people at the scala meetups are cut from a cloth that would make them more likely to be using things such as scalaz. I know that my local scala meetup seems to be more heavily oriented towards the functional end of things than the bulk of the scala developers I interact with. OTOH, perhaps the bias is with my sample.

Shamanmuni 12y ago

The fork means nothing dramatic. I'll make a short summary of both positions: Typesafe: we need to offer our clients a good guarantee on stability and compatibility with Java 8 or they won't take Scala seriously. So, for the moment we won't introduce new features or make big changes in the compiler. Typelevel: we are OK with compatibility and stability, but there are some features that we really want which either don't exist or are a bit quirky with the current compiler. So we will make a fork in which we can add these things while staying binary and merge compatible with yours. If they make it work, this is great news. There wouldn't be fragmentation as "bleeding edge Scala" would be binary and merge compatible with "stable Scala". And nobody should have hurt feelings, both positions are completely sensible.

VLM 12y ago

By analogy its not terribly far off from Debian issuing a "testing" branch off "unstable" a couple years or decade ago. Its a little more extreme than that, but not much. Usually forks are more dramatic. This isn't MariaDB or something like that. For PR reasons they probably should have stolen the Debian "testing" vs "unstable" names instead of getting all forky which is scarier sounding.

lmm 12y ago

> What's the history behind this fork and what is it likely to mean in terms of fragmentation? In particular what are the irreconcilable beliefs on each side that have led to this? What I've managed to put together, corrections welcome: Typesafe has been moving to stabilize Scala, primarily to make it more attractive to enterprise clients. Prior to 2.10, even point releases broke binary compatibility; now compatibility is maintained for those and they're making efforts to make minor releases binary compatible. The tooling they've produced and the testing framework that builds all the major libraries in the ecosystem and checks for binary compatibility means they now have quite possibly the best binary compatibility regime of any language. Typesafe recently published a roadmap for the next few releases, saying that the next release would focus exclusively on Java 8 support and remain compatible with the current release. This means work to merge any new features won't even start until January 2016, and those features are unlikely to be in an official release until 2017. Less frequent and more compatible releases are what a lot of people have been asking for, and it would be very awkward to maintain Java 8 and pre-Java 8 releases of Scala. So the typesafe position that there can be no new features in the release that introduces Java 8 (so that people will definitely be able to switch to Java 8 without making any code changes) makes a certain amount of sense. At the same time it's meant Scala's getting "frozen" in a bit of a weird state; macros were a recently-introduced experimental feature and the official version is kind of half-finished (there's a branch with a more complete version). And there are a couple of features that are quite small and simple but would be a tremendous help for the kind of code the typelevel guys work on (e.g. partial application of types would be a very simple syntactic rewrite, and there's already an implementation as a compiler plugin), and there's long been a feeling that they were coming as soon as we figured out the little details - so to then be told that we won't see these features until 2017 at the earliest was a bit upsetting. So there was a bit of consternation among the typelevel folks - a group who maintain some quite abstract and powerful libraries that tend to push the type system a bit further than most user code. Some of them started seriously talking about porting their libraries to one of the smaller, more experimental languages with a more elegant type system (Idris, Ermine, or I forget the other option). At the same time, the Scala community now has a lot of expertise in maintaining binary compatibility across quite complex changes, so at some point Miles came up with this idea. I don't think a fork would have happened otherwise - most of the goals can be achieved by compiler plugins (at the cost of being harder to maintain), and if they were going to break compatibility they might as well have jumped all the way to another language. But if the typelevel guys can pull off this "conservative fork", where they'll use their own compiler to compile their libraries but those libraries will then be binary compatible with "vanilla" scala and usable by ordinary scala users, then they get the best of both worlds. It's ambitious, but I hope it works out. > I haven't tried Scala yet, but my gut reaction is I should stick with Clojure until the dust settles. A fragmented community around a relatively niche language is never good. If they're maintaining binary compatibility then that should keep fragmentation to a minimum. Honestly I don't think this changes much compared to how it was with compiler plugins - if you're building some super-duper-typey project with these advanced features then maybe you'll muck around and use this forked compiler, but if you're a normal user then you can ignore it and carry on using their libraries without noticing any different. Plus even if the Scala community were to split in two, I think either half would be bigger than the Clojure community.

kamaal 12y ago

>>In particular what are the irreconcilable beliefs on each side that have led to this? I'm not familiar with this one. But in general most of these forks are generally out of personality clashes where one person just refuses to take another as the boss. Scala is still not among the top languages used in the industry. This kind of my way or the highway attitude will only fragment the already fragile ecosystem. Imagine any serious software shop wanting to use Scala reading this. If I want to be writing an enterprise application which I plan to keep running for the next decade, should I be choosing a language which isn't just not widely adopted, but the existing ecosystem itself has forks because a few members don't give two hoots about stability(Which is far more important to 99% of the software shops out there, than adding new features). Instead of doing something like this, and putting your broader community of users in perpetual confusion as to which ecosystem to use, you could rather contribute to something meaningful.

frowaway001 12y ago
Sometimes it's useful to read the blog post before commenting.
- kamaal 12y ago
  I did, and its the same template story always. We don't agree with technical decisions made by Set A people to be in best interests of the community, therefore we plan to fork Y, with intelligent Set B people. The actual story is always about control and ego.
  - frowaway001 12y ago
    You really didn't read it.