Live data from Hacker News

What's Next for Scala

lihaoyi.com

81–90 of 203 posts

Re: What's Next for Scala

#81

The Scala team pulled out all the stops with Dotty. It's a real tour de force, on a par with the sea change of C++11. Even with the plaudits he's earned, Martin Odersky is for me in the top three language designers of our time. (I'm sure I'm being unfair to other members of his team with this comment, though.) Dotty's union types are a thing of beauty, its implicits are really second to none, and _so_ damn useful. Th…

Unfortunately, I slowly got frustrated reading the what's coming for Scala 3.

* True intersections and union types -- use them sometimes, not something you can't live without though.

* Trait parameters -- slightly easier life for OOP, ok I guess.

* Function types and implicit function types -- right, will make your code even harder to read (subjective).

* Generic tuples -- again, I can't remember we ever had problems with tuples in Scala.

* Opaque types -- another small OOP improvement.

* Type lambdas -- I've never seen them used.

* Erased parameters -- probably useful if it improves performance even at the cost of readability right?

* Enums -- finally something practical, good.

And that's all about major changes in Scala 3. Ah, yes, we get a new compiler. Are you excited?

These changes look like a quarterly release than a major version shift. Now, imagine a project manager who's estimating the migration downtime for Scala 2 for the sake of the above.

Re: What's Next for Scala

#82

I very recently (about a year ago) joined a shop that is primarily into functional programming (FP) and I got my first exposure to Scala as well as F# through work projects. As a long time user of Java/OOP here are my thoughts on Scala and why it has so many things things going against it. Consider the following: 1) First, Scala is designed and developed by "ivory" tower academics primarily for research/PhD thesis pu…

Nowadays most Spark users use either PySpark or Spark SQL. Spark is designed in some sense to mimic Scala collection library. Rust is nice but its interop with other open source big data libs (Hadoop/Zookeeper/HBase) can be painful.

Re: What's Next for Scala

#83
post #25
post #9

Since the post mentions Scala Native, all these guest language projects that eschew the platform that made them famous and try to pursue the dream of being their own platform, while building an ecosystem, GC and optimising compiler from scratch (even if they build on LLVM or compile via C/C++), would be much better taking advantage of AOT and JIT caches from several JVM implementations instead of pretending they don'…

In my mind, GraalVM native compilation has superseded scala-native. GraalVM native compilation works really well. Many projects will compile to native out of the box. Many more with a bit of reflection config that's autogenerated. The native executables are slim, statically linked so they "just work", and startup instantly as one would expect. Scala is now a great choice for CLI tools.

Native image works well without dependencies. I tried to get Weld and other JEE deps running in a smaller project and it was foot gun after footgun.

I'm hoping in the future the native-image friction can be lowered, but as of now it's not trivial like other languages.

Re: What's Next for Scala

#84

I very recently (about a year ago) joined a shop that is primarily into functional programming (FP) and I got my first exposure to Scala as well as F# through work projects. As a long time user of Java/OOP here are my thoughts on Scala and why it has so many things things going against it. Consider the following: 1) First, Scala is designed and developed by "ivory" tower academics primarily for research/PhD thesis pu…

I work at a Java shop, we do ‘modern’ Java (11 or 14, some legacy 8), but I do a lot fp-style Scala dev at home.

Calling Scala an ivory tower with no interest in ‘practical’ programming is ridiculous. Scala and Java are remarkably similar in this respect (note Odersky was heavily involved with Java before Scala), albeit one is sponsored by a uni and the other a corporation. JEPs are just as likely to have actual PhD theses associated with them, and those that don’t often could have. Look at Project Valhalla or Loom or the GraalVM, these are novel programming language research projects with the end goal of bringing them to a widely used industry language in a backwards compatible and ergonomic way.

As for pure FP in production, just last week we had a brief bit of message loss in a system because some layer in an sdk swallowed a socket timeout exception and re-threw something totally unrelated and undocumented. This was hell to debug for other reasons related to imperative code, that simply wouldn’t have happened in a ZIO project.

That’s not to say you can’t make reliable software in Java, my team spends a lot of time doing just that. It just often feels like the whole ecosystem is fighting against you. Things are getting much better in Java land, but there are parts that can never catch up with Scala because of past design choices.

I agree with your other 2 points, multi-paradigm is both a blessing and a curse and probably becomes more of the latter in a large org.

Also, unrelated, but imo better Java is Java or maybe Java in 3 years, Kotlin didn’t go far enough.

Re: What's Next for Scala

#85
I'm sad not because Scala is dying but because it will embolden the many loud voices who like to proclaim it as dying, while others will believe them. Meanwhile, it will continue to progress. I became a better java programmer, a better php programmer, and a better javascript programmer by studying Scala. I became better at distributed systems concepts by studying Akka. I'm sure I will become better at a lot of other things by studying Akka Typed and Dotty. It's a language that clarifies your thinking in a way that brings better practices to other spheres. It's absolutely worth learning.

I've also had the experience of using it on undisciplined teams and that sucked. One overly "clever" programmer can turn off a sufficient number of other programmers and give it a bad rep. I don't think a language being expressive is sufficient cause to blame the language for that, though.

Re: What's Next for Scala

#86

I love Scala! It's the language that enlightened me and be more productive. Now, every time I code in other languages (e.g. Dart for Flutter, or JS for web stuff), I grumble when I can't find "standard" features such as "map", pattern matching, optional and named params, implicits. Also, when I code in Scala, I frequently google and end up learning something new about the language. I know it sounds like distraction/w…

You would be enlightened the same way or even more if you started with Haskell. That is, it is not Scala you are so excited about but the functional programming.

Btw, the actual thing to be inspired with in Scala is immutability and Option/Some/None instead of null. These are the things that make you code stable and reliable.

Re: What's Next for Scala

#87

The Scala team pulled out all the stops with Dotty. It's a real tour de force, on a par with the sea change of C++11. Even with the plaudits he's earned, Martin Odersky is for me in the top three language designers of our time. (I'm sure I'm being unfair to other members of his team with this comment, though.) Dotty's union types are a thing of beauty, its implicits are really second to none, and _so_ damn useful. Th…

for the record, instantiating case classes in scala does not require "new"

Re: What's Next for Scala

#88
post #54

Author here. The full title is “The Death of Hype: What’s Next for Scala”, and the full title is significant. This article is as much about the initial hype and its decline as it is about the future prospects of the language. It very much isn’t an official or even unofficial roadmap for the language, which is what the shortened title makes it sound like.

I posted it with the original title. I don't know why the HN moderators almost always change titles. Happened to me a couple of times.

[deleted]

Re: What's Next for Scala

#89
post #81

The Scala team pulled out all the stops with Dotty. It's a real tour de force, on a par with the sea change of C++11. Even with the plaudits he's earned, Martin Odersky is for me in the top three language designers of our time. (I'm sure I'm being unfair to other members of his team with this comment, though.) Dotty's union types are a thing of beauty, its implicits are really second to none, and _so_ damn useful. Th…

Unfortunately, I slowly got frustrated reading the what's coming for Scala 3. * True intersections and union types -- use them sometimes, not something you can't live without though. * Trait parameters -- slightly easier life for OOP, ok I guess. * Function types and implicit function types -- right, will make your code even harder to read (subjective). * Generic tuples -- again, I can't remember we ever had problems…

Scala 3 could improve on 2.x struggles with supporting JDK 9 and up:

Support features of JDK 11+ https://github.com/scala/scala-dev/issues/139

Support Java Module System https://github.com/scala/scala-dev/issues/529

In comparison language features seem to attract much more attention:

Removing existential types https://contributors.scala-lang.org/t/proposal-to-remove-exi...

Significant indentation syntax https://github.com/lampepfl/dotty/pull/7083

Re: What's Next for Scala

#90
post #81

The Scala team pulled out all the stops with Dotty. It's a real tour de force, on a par with the sea change of C++11. Even with the plaudits he's earned, Martin Odersky is for me in the top three language designers of our time. (I'm sure I'm being unfair to other members of his team with this comment, though.) Dotty's union types are a thing of beauty, its implicits are really second to none, and _so_ damn useful. Th…

Unfortunately, I slowly got frustrated reading the what's coming for Scala 3. * True intersections and union types -- use them sometimes, not something you can't live without though. * Trait parameters -- slightly easier life for OOP, ok I guess. * Function types and implicit function types -- right, will make your code even harder to read (subjective). * Generic tuples -- again, I can't remember we ever had problems…

Well. You also get better binary compatibility and the possibility to do whole program analysis.

Edit: oh. And this is on top of a rewritten, faster, compiler, a unified base paradigm making it easier to learn the language, and better error messages for compile errors. I think dismissing this as as minor release is disingenuous to how much effort goes in such a large scale rewrite. Granted, most of it is under the hood but it will pay off dividend.

Post reply on HN