Typelevel Scala and the future of the Scala ecosystem

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Typelevel Scala and the future of the Scala ecosystem

Simon Ochsenreither-3

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Typelevel Scala and the future of the Scala ecosystem

Ruslan Shevchenko-2
It's depends from policy.  If will exists clear policy for adding and maintaining external language extensions in community-supported compiler, which will actually work [unlike existing SIP process], that this will be  good for both commercial and non-commercial ecosystems.

Potential problems:  diversion.  (are 'co-scala' and 'scala'  will be the same language ?)  and resource constraints (which will depend from popularity of 'co-scala') 


On Tuesday, September 2, 2014 7:23:55 PM UTC+3, Simon Ochsenreither wrote:
<a href="http://typelevel.org/blog/2014/09/02/typelevel-scala.html" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Ftypelevel.org%2Fblog%2F2014%2F09%2F02%2Ftypelevel-scala.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFQygtPHhEC15Fd8O5yJW4agGu7eQ';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Ftypelevel.org%2Fblog%2F2014%2F09%2F02%2Ftypelevel-scala.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFQygtPHhEC15Fd8O5yJW4agGu7eQ';return true;">http://typelevel.org/blog/2014/09/02/typelevel-scala.html

Opinions?

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Typelevel Scala and the future of the Scala ecosystem

Daniel Armak
Before language diversion, consider binary compatibility. It's both hard and limiting to add compiler features and still guarantee binary compatibility of the artifacts. But if you don't, then people using the community compiler won't be able to use all the scala library artifacts published on maven. Later on, as the new compiler becomes more popular, library writers will feel extra pressure to publish another set of artifacts for the community compiler. 

It's bad enough when I have to cross compile, test and publish with scala 2.10 and 2.11 X akka 2.2 and 2.3. I use lots of libraries and a single one (reactivemongo) has no published akka 2.3 build and so I have to build it myself. Maven Central publishes source artifacts, but I can't use sbt to automatically pull and compile them, because the customizable build procedure itself is not published (e.g. some projects need a compiler plugin).

If the set of widely used compilers (and compiler versions, plugins, etc.) is going to grow a lot, it would be great to have a better story for automatically pulling and building published source artifacts.

-- 
Daniel Armak


On Tue, Sep 2, 2014 at 9:07 PM, Ruslan Shevchenko <[hidden email]> wrote:
It's depends from policy.  If will exists clear policy for adding and maintaining external language extensions in community-supported compiler, which will actually work [unlike existing SIP process], that this will be  good for both commercial and non-commercial ecosystems.

Potential problems:  diversion.  (are 'co-scala' and 'scala'  will be the same language ?)  and resource constraints (which will depend from popularity of 'co-scala') 


On Tuesday, September 2, 2014 7:23:55 PM UTC+3, Simon Ochsenreither wrote:

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Typelevel Scala and the future of the Scala ecosystem

Paul Hudson
Before language diversion, consider binary compatibility.

They have. Quoting from the page:

  • That we underestimate the difficulty of maintaining binary and/or merge compatibility.

    No, we really don't. We fully expect this to be the most challenging part of the whole exercise. That said, we have the benefit of years of experience of Scala binary compatibility issues, and we know now that a combination of a community-build style model along with effective use of the Migration Manager (already a component of the Typelevel SBT plugin) is enormously helpful in keeping on top of the issue.

    There is a real risk here, and care will be needed. One thing is for sure though – if we don't try, we'll never know if it's possible.



On 2 September 2014 20:13, Daniel Armak <[hidden email]> wrote:
Before language diversion, consider binary compatibility. It's both hard and limiting to add compiler features and still guarantee binary compatibility of the artifacts. But if you don't, then people using the community compiler won't be able to use all the scala library artifacts published on maven. Later on, as the new compiler becomes more popular, library writers will feel extra pressure to publish another set of artifacts for the community compiler. 

It's bad enough when I have to cross compile, test and publish with scala 2.10 and 2.11 X akka 2.2 and 2.3. I use lots of libraries and a single one (reactivemongo) has no published akka 2.3 build and so I have to build it myself. Maven Central publishes source artifacts, but I can't use sbt to automatically pull and compile them, because the customizable build procedure itself is not published (e.g. some projects need a compiler plugin).

If the set of widely used compilers (and compiler versions, plugins, etc.) is going to grow a lot, it would be great to have a better story for automatically pulling and building published source artifacts.

-- 
Daniel Armak


On Tue, Sep 2, 2014 at 9:07 PM, Ruslan Shevchenko <[hidden email]> wrote:
It's depends from policy.  If will exists clear policy for adding and maintaining external language extensions in community-supported compiler, which will actually work [unlike existing SIP process], that this will be  good for both commercial and non-commercial ecosystems.

Potential problems:  diversion.  (are 'co-scala' and 'scala'  will be the same language ?)  and resource constraints (which will depend from popularity of 'co-scala') 


On Tuesday, September 2, 2014 7:23:55 PM UTC+3, Simon Ochsenreither wrote:

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Typelevel Scala and the future of the Scala ecosystem

Daniel Armak
I saw that part. It wasn't clear to me if they guarantee binary compatibility or not. It's mentioned here in the "potential objections" section, but the main part doesn't mention it, it only talks about merge compatibility with the typesafe compiler. 

Daniel Armak


On Tue, Sep 2, 2014 at 10:28 PM, Paul Hudson <[hidden email]> wrote:
Before language diversion, consider binary compatibility.

They have. Quoting from the page:

  • That we underestimate the difficulty of maintaining binary and/or merge compatibility.

    No, we really don't. We fully expect this to be the most challenging part of the whole exercise. That said, we have the benefit of years of experience of Scala binary compatibility issues, and we know now that a combination of a community-build style model along with effective use of the Migration Manager (already a component of the Typelevel SBT plugin) is enormously helpful in keeping on top of the issue.

    There is a real risk here, and care will be needed. One thing is for sure though – if we don't try, we'll never know if it's possible.



On 2 September 2014 20:13, Daniel Armak <[hidden email]> wrote:
Before language diversion, consider binary compatibility. It's both hard and limiting to add compiler features and still guarantee binary compatibility of the artifacts. But if you don't, then people using the community compiler won't be able to use all the scala library artifacts published on maven. Later on, as the new compiler becomes more popular, library writers will feel extra pressure to publish another set of artifacts for the community compiler. 

It's bad enough when I have to cross compile, test and publish with scala 2.10 and 2.11 X akka 2.2 and 2.3. I use lots of libraries and a single one (reactivemongo) has no published akka 2.3 build and so I have to build it myself. Maven Central publishes source artifacts, but I can't use sbt to automatically pull and compile them, because the customizable build procedure itself is not published (e.g. some projects need a compiler plugin).

If the set of widely used compilers (and compiler versions, plugins, etc.) is going to grow a lot, it would be great to have a better story for automatically pulling and building published source artifacts.

-- 
Daniel Armak


On Tue, Sep 2, 2014 at 9:07 PM, Ruslan Shevchenko <[hidden email]> wrote:
It's depends from policy.  If will exists clear policy for adding and maintaining external language extensions in community-supported compiler, which will actually work [unlike existing SIP process], that this will be  good for both commercial and non-commercial ecosystems.

Potential problems:  diversion.  (are 'co-scala' and 'scala'  will be the same language ?)  and resource constraints (which will depend from popularity of 'co-scala') 


On Tuesday, September 2, 2014 7:23:55 PM UTC+3, Simon Ochsenreither wrote:

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Typelevel Scala and the future of the Scala ecosystem

Naftoli Gugenheim
In reply to this post by Simon Ochsenreither-3
...the community around the Typelevel projects contains many of the most able Scala programmers on the planet. Between us we have a deep understanding of Scala's type system and other semantics (both as specified and as implemented), of compiler construction in general and of Typesafe Scala compiler internals in particular. 

So why can't these improvements be contributed directly to Scala? I think that's the important question.

As an aside, I don't understand this:

Other fixes, whilst affecting semantics, would do so only in a conservative way – programs which are valid when compiled with the Typesafe Scala compiler would have the same meaning 

So... they will fix the semantics without affecting the code's meaning?
 


On Tue, Sep 2, 2014 at 12:23 PM, Simon Ochsenreither <[hidden email]> wrote:

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Typelevel Scala and the future of the Scala ecosystem

Simon Ochsenreither-3
Typesafe’s Commitment to the Scala Ecosystem
Typesafe’s Commitment to the Scala Ecosystem
Typesafe’s Commitment to the Scala Ecosystem
Typesafe’s Commitment to the Scala Ecosystem
Typesafe’s Commitment to the Scala Ecosystem

Typesafe’s Commitment to the Scala Ecosystem: http://typesafe.com/blog/typesafes-commitment-to-the-scala-ecosystem

Typesafe’s Commitment to the Scala Ecosystem

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Typelevel Scala and the future of the Scala ecosystem

Simon Ochsenreither-3
In reply to this post by Naftoli Gugenheim

Typesafe’s Commitment to the Scala Ecosystem: http://typesafe.com/blog/typesafes-commitment-to-the-scala-ecosystem

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Typelevel Scala and the future of the Scala ecosystem

Rex Kerr-2
In reply to this post by Simon Ochsenreither-3
Best case?  It provides
  (1) A nice collection of features for power-users of certain aspects of the language (e.g. type inference), plus
  (2) An alternative to SIPs for making global changes to the language.  The SIP is: look, we implemented it, it works, people use it, and it's great (plus here's a small formal document that describes it)!
  (3) A cooperative process where Scala as a whole gains benefits of improvements delivered via processes with different constraints (where growing pains unacceptable in one process can be worked through in the other)

Worst case?  It inflicts
  (1) Fragmentation of libaries and code bases, reducing source compatibility
  (2) Divides attention, causing multiple problems to be solved poorly twice instead of well once
  (3) Fighting and bad feelings among key people in different "camps"

Hopefully everyone (Typelevel especially) will try to nudge things towards the best-case as much as possible.  I like how cooperative and positive the initial blog sounds, and the Typesafe blog by Martin Odersky reinforces that we're in good position to steer more towards the best case than the worst.

  --Rex



On Tue, Sep 2, 2014 at 9:23 AM, Simon Ochsenreither <[hidden email]> wrote:

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Typelevel Scala and the future of the Scala ecosystem

Alexandru Nedelcu
In reply to this post by Simon Ochsenreither-3
My 2 cents ... Personally I do not like the rationalization given - stability isn't important only for middleware in an enterprise space, but it's also important for startups targeting consumers or for any software shop that are doing development of any significance or for any open-source project for that matter.

Of course, stagnation is not good - I'm thrilled every time the Scala developers decide to do bold things, like upgrading the requirement to Java 8 - which speaking of the enterprise space, it's very cutting edge and will remain cutting edge even in 2016. And Scala is basically dropping compatibility with Android in the hope that somehow the Android toolchain will catch up. And I do wish for more bold things to happen, so I understand the frustrations of some, but I only have trust in such bold moves if I can trust that the people in charge will do so responsibly. So I understand Typesafe's newly found commitment to a healthy migration path in case of bold changes and it's something that I personally need too.

To compare the current situation with a competitor, the difference is striking when you can take a library that was written for Clojure 1.1 years ago and that still works for Clojure 1.6. Even as an open-source author, you can publish a library on GitHub and then you don't have to constantly upgrade it to the latest version.

I'm also pretty sure that if it were up to the Typelevel folks, then macros wouldn't have happened. Macros are one of my favorite traits of the language - maybe I'm wrong, maybe I haven't see the same light, but I love a language on top of which one can build Scala-Async and LINQ as a library. This is why I do not believe in languages designed by communities, as I fail to see how such a design process is better than the usual design by committee. Personally if I cannot identify my needs or values with a language, I simply switch languages - worked great thus far, as in if you want Haskell, just use Haskell and be done with it.

That said, I could see this going into a good direction - after all, the ability to fork is what open-source is about, being a prerequisite for merging and it can potentially lead to more contributions making their way into Scala and a win-win for everybody. But only if the goals stated in that announcement will hold - i.e. binary compatibility / merge compatibility.




On Tue, Sep 2, 2014 at 7:23 PM, Simon Ochsenreither <[hidden email]> wrote:

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.



--
Alexandru Nedelcu
www.bionicspirit.com

PGP Public Key:
https://bionicspirit.com/key.aexpk

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

RE: Typelevel Scala and the future of the Scala ecosystem

Razvan Cojocaru-2
In reply to this post by Simon Ochsenreither-3

Why is it either or? Why fork and fragment it all, when we have a working model?

 

Why can’t we grow by making the compiler and language itself modular? i.e. there could be a “minimal” scala subset and then, much like adding libraries such as scalaz, we could define language enhancements that plug into the different compilers (and IDEs) and extend the language itself with this or that expressivity?

 

The macros are one way this has been done so far, but perhaps incomplete?

 

Certain libraries could declare dependencies on this and that compiler extension.

 

If the compiler/language extensions are written in scala itself and compilable with the minimal subset then it could be a self-sustaining ecosystem? At worst these would be JAR files mentioned in some maven dependency list somewhere…?

 

Did we hit some theoretical limits on compiler design, that make it inflexible or does it just need re-thinking?

 

thanks,

razie,

power & simplicity @ https://www.nofolders.net

code @ https://github.com/razie

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Simon Ochsenreither
Sent: September-02-14 12:24 PM
To: [hidden email]
Subject: [scala-debate] Typelevel Scala and the future of the Scala ecosystem

 

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Razvan Cojocaru,
Work: http://www.sigma-systems.com
Playground: http://wiki.homecloud.ca
Latest cool toys: Scripster and Gremlins
Follow me: RSS Feed, Twitter, GitHub.
Reply | Threaded
Open this post in threaded view
|

Re: Typelevel Scala and the future of the Scala ecosystem

Tom Switzer
In reply to this post by Alexandru Nedelcu
I'm also pretty sure that if it were up to the Typelevel folks, then macros wouldn't have happened. Macros are one of my favorite traits of the language - maybe I'm wrong, maybe I haven't see the same light, but I love a language on top of which one can build Scala-Async and LINQ as a library.

Several of the typelevel projects make use of macros. I've definitely made use of them many times. For instance, behold Macro City: https://github.com/non/spire/blob/master/core/src/main/scala/spire/math/FpFilter.scala

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Typelevel Scala and the future of the Scala ecosystem

Simon Ochsenreither-3

https://github.com/paulp/policy: a fork of the scala compiler

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Typelevel Scala and the future of the Scala ecosystem

som-snytt
I see from the chart at the bottom that Paul still owes Scala about 25K LOC.

Most of that is probably shuffled commas, of course.

It ought to be spelled Paulie's c.

And I hope for Typelevelc we can write TLC for short.




On Fri, Sep 5, 2014 at 2:05 PM, Simon Ochsenreither <[hidden email]> wrote:

https://github.com/paulp/policy: a fork of the scala compiler

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Typelevel Scala and the future of the Scala ecosystem

atomly

On Fri, Sep 5, 2014 at 7:32 PM, Som Snytt <[hidden email]> wrote:
I see from the chart at the bottom that Paul still owes Scala about 25K LOC.

Hahaha

:: atomly ::

[ [hidden email] : www.atomly.com  : http://blog.atomly.com/ ...
[ atomiq records : new york city : +1.347.692.8661 ...
[ e-mail [hidden email] for atomly info and updates ...

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.