I don't understand what features they want to add beyond type lambda's, singleton types, and literals for bytes / shorts.
1. I understand if you spend all day making shapeless / scalaz the lack of sugar for type lambda's is annoying. Why not make a SIP to add some sugar there?
2. Singleton types would have use in ScalaJs as well for encoding. There is already a SIP for this.
3. Byte / Short literals, seem like again, a SIP could be made for the
next release.
So all this boils down to getting SIPs into the language faster. So I think the real feature is not having to wait 3+ years for language improvements that significantly improve the QOL of some library writers.
That is a feature I would like as well. I really miss being able to open the mailing list and scan for exciting new features, Instead I know even if someone has a great idea, it'll be years before it sees the light of day. This sucks and I've moved onto to getting my neat idea -> wow I can use this in my language fix to ScalaJS[1].
I think (thought?) about Scala as ycombinator for language features. I see this enterprise mindset coming in now trying to tie down what Scala is and ultimately I fear that it will kill all the things that has made Scala popular in the first place. Pushing to a more infrequent release model might help enterprise customers but it absolutely crushes library developers in the vanguard working to make the Scala of tomorrow by fighting to get the language features of today. They need turn around on the improvements listed above and can't wait 4+ years to get them.
So does Scala take all the strength it has built up from acting as a feature incubator for the last 10 years and switch and lock down what works, it is in a prime position to do so? It has a virtual monopoly on it's space.
Or does Scala continue to act as a language feature incubator giving its coders early access to cutting edge CS idioms in a mainstream language. There are a lot of CS ideas waiting to get their shot.
Some people would see this situation and say Scala is facing a mutually exclusive set of outcomes, it must decide now. Nonsense I say! When confronted with tough choices I think of the famous Yogi Berra quote "When you see a fork in the road, take it."
I ask myself is there some way we can have our cake and eat it too? Can we go on trying out new features while still oferring stability to those willing to wait for it?
What if we moved to model of more frequently releases + less frequent releases? A controlled fork within the ecosystem, similar to what Ubuntu / Fedora does.
Publish 2 major short term releases a year that cutting edge library writers can target and build their libraries against. Vend these are properly tagged releases in maven central. Stick any old SIP in there, the enterprise overlords don't have to know about it. Rapid iteration, with rapid fall-off in support, a fun Scala for those of us that love using new features, bugs and all, for us the language is about growth.
Then have an LTS version released every other year that picks up the features that worked and everyone seems to love and that will be supported for years into the future. Relatively slow iteration with slow fall off in support, vend this Scala to enterprise users with a coherent multi-year support policy that just oozes with that 'this is rock solid and will work for eons to come' professional vibe that makes them happy.
1: I am using ScalaJS and man it feels great, it's like Scala of 6 years ago, I love opening the mailing list to see if there is a new release with some awesome new features / improvements. There is a lot of green territory over there because it's targeting a new platform and that will settle with time, but already it beats the socks off all the other competitors in the statically typed compiles to JS camp, just no one knows it yet.
+1 on ScalaJS. It's pretty amazing piece of technology (Thank's team!) using it in combination with David Barri's bindings for ReactJS[1] and Li Haoyi's uPickle[2]. It makes for elegant solutions with a shared codebase.
I ask myself is there some way we can have our cake and eat it too? Can we go on trying out new features while still oferring stability to those willing to wait for it?
Honestly, it seems like this is precisely that.
There's a general feeling in the community that the future of the Scala language and toolset is closely tied to the business goals of one specific company, at the expense of other members of the community. As long as the fork stays close to the existing mainline -- and it seems they intend to -- this seems like it should work out well for both sides: the community gets to fix some longstanding pain points with their tools, and Typesafe gets a fertile source of pre-battletested improvements to roll in to their slower-moving distribution.
Compiler plugins are powerful, but still too limited. We can't change parsing rules with a compiler plugin, for example. There are also potential compatibility issues with using some set of compiler plugins, and there's a performance penalty of implementing new features with plugins (which, by their very nature, are optional), rather than in the core compiler.
Comments
I don't understand what features they want to add beyond type lambda's, singleton types, and literals for bytes / shorts.
1. I understand if you spend all day making shapeless / scalaz the lack of sugar for type lambda's is annoying. Why not make a SIP to add some sugar there?
2. Singleton types would have use in ScalaJs as well for encoding. There is already a SIP for this.
3. Byte / Short literals, seem like again, a SIP could be made for the next release.
So all this boils down to getting SIPs into the language faster. So I think the real feature is not having to wait 3+ years for language improvements that significantly improve the QOL of some library writers.
That is a feature I would like as well. I really miss being able to open the mailing list and scan for exciting new features, Instead I know even if someone has a great idea, it'll be years before it sees the light of day. This sucks and I've moved onto to getting my neat idea -> wow I can use this in my language fix to ScalaJS[1].
I think (thought?) about Scala as ycombinator for language features. I see this enterprise mindset coming in now trying to tie down what Scala is and ultimately I fear that it will kill all the things that has made Scala popular in the first place. Pushing to a more infrequent release model might help enterprise customers but it absolutely crushes library developers in the vanguard working to make the Scala of tomorrow by fighting to get the language features of today. They need turn around on the improvements listed above and can't wait 4+ years to get them.
So does Scala take all the strength it has built up from acting as a feature incubator for the last 10 years and switch and lock down what works, it is in a prime position to do so? It has a virtual monopoly on it's space.
Or does Scala continue to act as a language feature incubator giving its coders early access to cutting edge CS idioms in a mainstream language. There are a lot of CS ideas waiting to get their shot.
Some people would see this situation and say Scala is facing a mutually exclusive set of outcomes, it must decide now. Nonsense I say! When confronted with tough choices I think of the famous Yogi Berra quote "When you see a fork in the road, take it."
I ask myself is there some way we can have our cake and eat it too? Can we go on trying out new features while still oferring stability to those willing to wait for it?
What if we moved to model of more frequently releases + less frequent releases? A controlled fork within the ecosystem, similar to what Ubuntu / Fedora does.
Publish 2 major short term releases a year that cutting edge library writers can target and build their libraries against. Vend these are properly tagged releases in maven central. Stick any old SIP in there, the enterprise overlords don't have to know about it. Rapid iteration, with rapid fall-off in support, a fun Scala for those of us that love using new features, bugs and all, for us the language is about growth.
Then have an LTS version released every other year that picks up the features that worked and everyone seems to love and that will be supported for years into the future. Relatively slow iteration with slow fall off in support, vend this Scala to enterprise users with a coherent multi-year support policy that just oozes with that 'this is rock solid and will work for eons to come' professional vibe that makes them happy.
1: I am using ScalaJS and man it feels great, it's like Scala of 6 years ago, I love opening the mailing list to see if there is a new release with some awesome new features / improvements. There is a lot of green territory over there because it's targeting a new platform and that will settle with time, but already it beats the socks off all the other competitors in the statically typed compiles to JS camp, just no one knows it yet.
+1 on ScalaJS. It's pretty amazing piece of technology (Thank's team!) using it in combination with David Barri's bindings for ReactJS[1] and Li Haoyi's uPickle[2]. It makes for elegant solutions with a shared codebase.
[1] https://github.com/japgolly/scalajs-react
[2] https://github.com/lihaoyi/upickle
do you know of any large apps using scalajs-react in production?
Speaking of byte/short literals, we can already have a syntax for them with string interpolation. In fact, that's what is already implemented in Spire: https://github.com/non/spire/blob/ac12fd02180e39d2d482217319....
Honestly, it seems like this is precisely that.
There's a general feeling in the community that the future of the Scala language and toolset is closely tied to the business goals of one specific company, at the expense of other members of the community. As long as the fork stays close to the existing mainline -- and it seems they intend to -- this seems like it should work out well for both sides: the community gets to fix some longstanding pain points with their tools, and Typesafe gets a fertile source of pre-battletested improvements to roll in to their slower-moving distribution.
Don't compiler plugins provide a way to provide a way to experiment with language changes more quickly?
Compiler plugins are powerful, but still too limited. We can't change parsing rules with a compiler plugin, for example. There are also potential compatibility issues with using some set of compiler plugins, and there's a performance penalty of implementing new features with plugins (which, by their very nature, are optional), rather than in the core compiler.
What kind of performance issues are you having in mind?
We have more ideas on the table beyond these three, but Miles will go into more detail about these in his next blog post.
How is ScalaJS's output size lately?
170 KB to a few hundred KB for typical applications. That's will full optimizations which take a few seconds to apply.
The fast dev cycle version weighs between 1 and 2.5 MB.