4 ms·

I am excited about Scala 3. Scala is a powerful tool that can make teams hyperproductive. Here are the tooling shifts that can broaden the Scala 3 userbase:

I am excited about Scala 3. Scala is a powerful tool that can make teams hyperproductive. Here are the tooling shifts that can broaden the Scala 3 userbase: * Community switching from SBT to Mill * Community agreeing on automated code formatting and everyone using the same scalafmt settings. After using automated code formatting tools like black for Python and gofmt, programmers really don't want to talk about whitespace formatting on every PR. Scala has a lot of syntax, so this is more important than you might imagine. They need to change from this detailed style guide (https://docs.scala-lang.org/style/ https://docs.scala-lang.org/style/) to "use these scalafmt settings and don't talk about code formatting anymore" * Make it clear what libraries are recommended for certain tasks. If you search for "scala json libraries" you'll arrive at these 16 options: https://stackoverflow.com/a/14442630 https://stackoverflow.com/a/14442630. Devs don't want to do an extensive research project to figure out what JSON lib to use. * Shift from Scalatest to utest / munit for the reasons outlined here: https://github.com/com-lihaoyi/utest#why-utest https://github.com/com-lihaoyi/utest#why-utest * Fill in "obvious library gaps" with good solutions. Scala needs a graph library that's usable like networkx for example. Li's libs are so popular cause he exposes beautiful Python-like interfaces (with crazy, performant Scala implementations under the hood). * Embracing devs that want to use Scala as a "better Python" rather than giving them the message "if you use Scala, you need to do it the Scala-way". Scala is a multi-paradigm language and using the language in different ways should be encouraged. * Getting the community to use the Principle of Least power is perhaps the hardest: https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLeastPower.html https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofL.... I find the doc to be cut-and-dry, but have found it less useful than I originally thought for resolving technical disputes. The hard work has been done to build Mill, utest/munit, scalafmt, metals, etc. Scala just needs to make some opinionated choices so the ecosystem is appealing to ppl that aren't as into programming. It'll be interesting to see if Spark is able to upgrade to Scala 3 or if they get stuck on Scala 2.13.

acjohnson55 5y ago
Speaking of Li's work, he's also done a lot to improve the REPL and scripting experiences for Scala. Combined with Scala 3, this is great for rapid prototypes, simple tools, and glue.
dkarl 5y ago
> Getting the community to use the Principle of Least power is perhaps the hardest This hurts so much. The nerd in me wants to gush over the improvements in Scala 3, but that pleasure has been ruined by observing in my own coworkers that the people who are the most excited about Scala are terribly self-indulgent in their work. I know when my coworker says he's excited about @inline that our first Scala 3 service (which I'm guessing he will roll out next month) will have more than one use of @inline, for no other reason than his desire to learn it. I am a huge fan of Scala, but I am developing a knee-jerk Grinchiness about any kind of excitement about it. I hate the way my feelings have changed, but still, I think we have to wrestle with the fact that in many if not most software organizations, the Scala advocates are people who enjoy having fun with technology and leveling up their skills and who cultivate an intentionally and stubbornly unexamined assumption that continually adding new programming powers to their skillset is the best way to serve the needs of the business and the needs of their coworkers. If I could wish for one impossible thing for Scala, it would be widespread top-down forced adoption, so that lots of people who aren't particularly enthusiastic about Scala are forced to use it. I think people who are less enthusiastic about Scala write better code in Scala. I think they could improve Scala (and Scala could improve their programming as well.) What I'm seeing now in practice is Scala being avoided by those people who have the skepticism and discipline to use it well, and embraced by people whose engineering decisions are determined by their feelings of curiosity and boredom.
amw-zero 5y ago
> Make it clear what libraries are recommended for certain tasks I think no community has this problem solved, and I also think it is unsolvable unfortunately. The need to experiment seems to be human nature, and we are still really terrible at designing for code reuse, so small, subtle feature differences often require a totally different interface / library. I don't disagree with the desire to solve this problem, I just think it's completely unrealistic and not rooted in reality. It reminds me of when people say "we should make this simpler." Yes, that's a great goal, and one that is easy to say but not easy to achieve.

acjohnson55 5y ago

Speaking of Li's work, he's also done a lot to improve the REPL and scripting experiences for Scala. Combined with Scala 3, this is great for rapid prototypes, simple tools, and glue.

dkarl 5y ago

> Getting the community to use the Principle of Least power is perhaps the hardest This hurts so much. The nerd in me wants to gush over the improvements in Scala 3, but that pleasure has been ruined by observing in my own coworkers that the people who are the most excited about Scala are terribly self-indulgent in their work. I know when my coworker says he's excited about @inline that our first Scala 3 service (which I'm guessing he will roll out next month) will have more than one use of @inline, for no other reason than his desire to learn it. I am a huge fan of Scala, but I am developing a knee-jerk Grinchiness about any kind of excitement about it. I hate the way my feelings have changed, but still, I think we have to wrestle with the fact that in many if not most software organizations, the Scala advocates are people who enjoy having fun with technology and leveling up their skills and who cultivate an intentionally and stubbornly unexamined assumption that continually adding new programming powers to their skillset is the best way to serve the needs of the business and the needs of their coworkers. If I could wish for one impossible thing for Scala, it would be widespread top-down forced adoption, so that lots of people who aren't particularly enthusiastic about Scala are forced to use it. I think people who are less enthusiastic about Scala write better code in Scala. I think they could improve Scala (and Scala could improve their programming as well.) What I'm seeing now in practice is Scala being avoided by those people who have the skepticism and discipline to use it well, and embraced by people whose engineering decisions are determined by their feelings of curiosity and boredom.

amw-zero 5y ago

> Make it clear what libraries are recommended for certain tasks I think no community has this problem solved, and I also think it is unsolvable unfortunately. The need to experiment seems to be human nature, and we are still really terrible at designing for code reuse, so small, subtle feature differences often require a totally different interface / library. I don't disagree with the desire to solve this problem, I just think it's completely unrealistic and not rooted in reality. It reminds me of when people say "we should make this simpler." Yes, that's a great goal, and one that is easy to say but not easy to achieve.