Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> For example value classes are coming and possibly generic specialization for those value classes in the next versions (like 9 or 10, so it will happen, it's on the roadmap) and there are libraries that desperately want to avoid boxing. So what then? Will we stay with Java 6?

Well, Scala already does value specialization even on Java 6, so that's less urgent. You are right of course, but I think most libraries will simply release new versions that require Java 8, rather than having an intermediate version with no changes except a Java 8 port. But I could be wrong.

> In fact I think this upgrade to Java 8 is sort of anti-enterprise. How many companies have you see with projects running on anything newer than Java 6? There are still companies running with Java 1.4 for that matter. Java 8 is bleeding edge and it will remain to be bleeding edge in 2016.

I agree - which makes the Typesafe stance rather perverse. Are there really going to be people in 2016 who want to move their Scala to 2.12 so they can call it from Java 8, but would be put off if 2.12 contained any new features? Who won't have anyone available to fix even the most minor of syntactic changes? (or not even that - Typelevel is talking about a compiler that accepts all valid Typesafe-scala programs, with all the new syntaxes being things that are currently errors). I really don't think including partially applied types, byte/short literals, or singleton types in Scala 2.12 would be a dealbreaker for anyone (though I guess Typesafe has to draw their line in the sand somewhere).

What I expect/hope will happen is that Typesafe will accept pull requests for those pieces and some fixing up of macros, which will be enough to make a Scala I'm happy using until 2017. Then this fork can either become a place for further experimentation like Meta, or quietly die; important libraries will be able to continue to support Typesafe Scala, Typesafe will have accepted the proven features that users want without opening the floodgates to every experimental piece under the sun, and the community can hang together.



Well I have those hopes too - this can be a very positive thing, since it can attract more contributions to Scala.

After all, the Scala core probably has their plate full and could use some help. It's one thing to make a proposal for a feature to a group of developers with their hands full, it's quite another to submit a pull request saying "look, this is useful, people like it" - it changes the equation.


I think the idea behind keeping 2.11/2.12 as similar as possible is to enable people to cross-build things more easily, which would drastically improve the life span of the last Java6-compatible release (2.11) until people have found better solutions.

(I can imagine that there will be generic translators from Java8 bytecode to Java6 bytecode, so why should they keep maintaining two backends, if they could maintain one and just leverage a common tool to do the rest?)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: