Skip to content
This repository was archived by the owner on Sep 1, 2020. It is now read-only.

The future of Typelevel Scala #186

Closed
milessabin opened this issue Jul 1, 2019 · 18 comments
Closed

The future of Typelevel Scala #186

milessabin opened this issue Jul 1, 2019 · 18 comments
Assignees
Labels

Comments

@milessabin
Copy link
Member

Typelevel Scala has largely delivered on its roadmap of features for improving the functional programming experience in Scala: almost all of the features which were prototyped or proposed here have since landed in Scala 2.12, 2.13 or in Dotty. Indeed, some features (eg. by-name implicits), which I had planned to prototype here, I took straight to Lightbend Scala and Dotty instead.

I think this has been a great success for community contribution to the language, and I have been hugely impressed and gratified by Lightbend and EPFLs openness to dialogue with the Scala functional programming community.

I think there's now a much clearer understanding that Scala and Dotty are FLOSS projects like any other, and that community contributions via PRs to scala/scala and lampepfl/dotty are both possible and welcome. There is now a much larger pool of active contributors to both of those repos than there was when this fork was initially created and I believe that the existence and activity of this repo played an important part in encouraging that growth.

But this now leaves us with a question: is Typelevel Scala redundant now? Do we declare it successfully completed, archive it and move on? Or is there still work to do here, and if so, what?

I'm aware that there are a few projects which target Typelevel Scala (Libra, singleton-ops and Pine to name a few). As far as I can make out, this is almost exclusively motivated by literal types. Is the conclusion to draw from this that any residual role that Typelevel Scala has is to provide backports of 2.13.x features to 2.12.x? Or is that actively harmful, and should we instead be encouraging people to move to 2.13+?

@milessabin milessabin self-assigned this Jul 1, 2019
@soronpo
Copy link

soronpo commented Jul 1, 2019

IMO, it is better to encourage people to migrate to 2.13.x.
The only reason I haven't migrated to 2.13.x is that there is still a regression (scala/bug#11397) that prevents me from doing so, so I'm still dependent on TLS.
(FWIW, singleton-ops works in regular 2.12, but of course it is best to have literal-types).

As for the future of TLS, I think there may still be one, but on the dotty/Scala 3 playground.

@travisbrown
Copy link

I've never used Typelevel Scala outside of a couple of little toy projects, but I've used literal types many times on mainline 2.11 and 2.12, in both library and application development, either via Shapeless's Witness or my own macros. The syntax in 2.13 and TLS is definitely nice, but you don't need it to use literal types effectively. I'm 👍 on retiring TLS now and letting the syntax serve as a motivation to move to 2.13.

For what it's worth my current plan for circe is to introduce instances for literal types in circe-core on Scala 2.13 in the next release, but also to continue providing the old macro-powered literal type instances in circe-literal for all supported Scala versions. This requires some version-specific code and some redundancy, but it's not that bad.

@tindzk
Copy link

tindzk commented Jul 1, 2019

The only feature I am using from TLS are literal types and finally they are available in mainline Scala with 2.13. Unfortunately, I am still stuck with TLS 2.12 in most of my projects and even use TLS 2.11 whenever Scala Native is involved. But as soon as Bloop, Scala Native and a few libraries have added 2.13 support, I do not see any reason not to switch. Since TLS 2.11 and 2.12 are both quite stable, I agree with retiring it and encouraging developers to move on to 2.13.

By the way, I just merged a pull request in Pine to add support for 2.13 and a new version should go out soon. I am still planning to support TLS in Pine and Seed for as long as it remains practical.

@tpolecat
Copy link
Member

tpolecat commented Jul 1, 2019

Yep 👍 shut it down, I think this project is done.

@smarter
Copy link

smarter commented Jul 1, 2019

#166 means that publishing a library using TLS is potentially dangerous for the ecosystem, so I'm all for encouraging people to move back to the regular distribution.

@zainab-ali
Copy link

Libra will soon upgrade to 2.13, and no longer makes use of Typelevel Scala.

TLS was helpful in making a case for literal types, and there may be a need for a similar playground in the future. At present, I support focusing community contributions to scala/scala and encouraging people to upgrade.

@gvolpe
Copy link
Member

gvolpe commented Jul 3, 2019

This is the experimental project I mentioned on Twitter it's using -Ykind-polymorphism (I said poly kinds): https://github.com/sellout/cheshire

But anyway it's experimental, nothing being used in production AFAIK. Thanks again for TLS :)

@odersky
Copy link

odersky commented Jul 3, 2019

The way I see it, the TypeLevel compiler was very useful for trying out and refining features that have found their way into the mainline compiler afterwards. Now that the most important features are released in scalac (yay!) I don't see much value in maintaining the separate fork. If a new topic for experimentation arises it looks better to fork off the current Scala 2 or 3 compiler at that time.

@sellout
Copy link

sellout commented Jul 3, 2019

@gvolpe Thanks for looking out for me 😁 Yeah, I don’t mind moving Cheshire to Dotty.

To me, the thing I’d be saddest about losing when switching from TLS to LBS is the improved exhaustiveness checking (my name is on the PR, but it’s largely @retronym’s work). I think the only unresolved issue with that is that it expects catch blocks to be exhaustive, but the discussion includes a reference to a PR from @som-snytt that would ostensibly fix that.

@SethTisue
Copy link
Member

correct link to "improved exhaustiveness checker": scala#5617

@clhodapp
Copy link

clhodapp commented Jul 3, 2019

Selfishly, I would love to see one last Typelevel Scala release happen against 2.12.8. There have been a lot of improvements (especially with respect to compile time) within the 2.12 series that have been locked away for Typelevel Scala users. I know it would probably take a lot of annoying work to make it happen, though, and the need will decrease rapidly as libraries bump to support 2.13. Going forward, I think that mainline Lightbend Scala 2.13 has the most-critical stuff from Typelevel Scala so I don't think there's a compelling reason to keep the fork around going forward.

To me, it seems like right now we are in a special time for Scala language progression. In a lot of ways, Dotty is serving the purpose for the community that Typelevel Scala was intended to (and it's doing it even better than Typelevel Scala was able to!). Maybe someday after Dotty stabilizes into Scala 3 we will need something like Typelevel Scala again but that is likely to be so far down the road that it's probably not worth worrying about yet.

@kevinwright
Copy link

kevinwright commented Jul 9, 2019

Migrating to 2.13 right now simply isn't an option for anybody who wants to target scala-native.

What's the possibility of going the other way... Can we get literal-types backported into a future point release of the 2.11 and 2.12 versions of the Lightbend compiler, still behind the flag?

@smarter
Copy link

smarter commented Jul 9, 2019

Helping out scala-native to move to newer scala releases seems like a better long-term solution.

@milessabin
Copy link
Member Author

I agree with @smarter. I was open to persuasion on 2.12.x, but I really have no interest in supporting 2.11.x ... scala-native really need to get themselves onto a current Scala version.

@kevinwright
Copy link

kevinwright commented Jul 9, 2019

For reference... scala-native/scala-native#233
First opened July 2016!

@soronpo
Copy link

soronpo commented Jul 9, 2019

IMO native should just wait for a Scala 2 Tasty representation and create a new backend from that, but I have no idea if the time-table for that suits their needs.

@diesalbla
Copy link

@milessabin It seems this has been quiet for a year now... with no open branches, should we close this down?

@milessabin
Copy link
Member Author

Yes we should.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests