Scala on Track to Support Java 9 Module System | Hacker News Reader

Scala on Track to Support Java 9 Module System

github.com

Not a lot of progress in the last year.

The hype is gone, now there are other languages on the spotlight.

Longterm, languages that own platforms are always a safer bet.

They only go away when the platform dies, while guest languages come and go.

And best of all, you don't need to wait for supporting platform features, having additional idiomatic wrappers, more IDE plugins, debugging support, build tools, etc.

We're a scala shop, we get a functional language with features such as parser combinators (packrat parsers) - super useful for building DSLs. Functional-Relational-Mapping (for comprehensions) for SQL. We're able to get good web services with play, with easy to write asynchronous code. Plus all of it runs on robust JVM. We love it, we'd not change it for us, hype or no hype.

>> super useful for building DSLs

This is exactly the reason we do not use Scala anymore. Tired of learning new DSLs for every single problem.

isn't the alternative to a dsl just constructing classes, giving them to each other, and using a bunch of stringy typed arguments?

>> just constructing classes

I usually do not want to construct classes, it does not help me achieving what I want in my day to day duties.

>> using a bunch of stringy typed arguments?

I usually have all sorts of typed arguments.

hard to have a safer bet than the JVM as your platform. not like changes like Jigsaw come around that often

We are a scala shop as well, but more and more things are being built in Kotlin. I love scala but the lack of a future is downhearting.

I used to work at a Scala shop and to me, the future looks great. 2.13 is nice, and 3.0 should be very nice. The language is a joy to work with and insanely powerful. I wouldn’t say there’s a better practical language out there (OCaml could be in the future though).

What kinds of things are you guys doing in Kotlin? Anything server-side?

Not sure how anyone can say Scala has no future when Scala 3 is around the corner:

https://medium.com/@sinisalouc/whats-new-in-scala-3-28d9c11e...

I am not that much interested in what versioning scheme a language used and very curious about what is new in Scala that makes it a more attractive platform tomorrow than it is today.

I just read that post and so far there is nothing really that interesting. Maybe it is just me.

I don't see a future with Kotlin either.

Android has turned into Kotlin's platform.

Outside Android I predict Kotlin will be feeling like Scala is nowadays.

Too much dependent on JetBrains tooling, leaving other Java tools as 2nd class, trying to spread too wide with Kotlin/Native having specific memory semantics, sequences and co-routines are their own thing, distinct from JVM ones.

Does anyone use Scala on Android?

I’m sure it requires more resources than Kotlin but phone hardware has greatly improved in the last 5 years.

I bet someone does, but good luck fighting all the missing tooling and SDK support.

Scala seems to be chugging along.

Twitter still uses it heavily.

I recently watched a few Scala Days 2019 videos:

https://www.youtube.com/channel/UCOHg8YCiyMVRRxb3mJT_0Mg

It seems to have a healthy community. 3.0 comes out next year.

If you want a functional gateway drug, Scala appears to be the answer:

https://typelevel.org/cats/

If you really want to see the future of Scala look at ZIO (http://zio.dev)

By far the most interesting library I've seen on any platform in decades. It handles the most complex concurrency issues with ease. In my current project is has meant an order of magnitude less code to write. And the way you explicitly have to list what your function returns under every situation e.g. success and error is a real improvement in how Java/Scala works e.g. https://zio.dev/docs/datatypes/datatypes_io

And for web developer look at Slinky one of the nicest React implementations on any platform (https://slinky.dev)

Heather Miller's recent talk at JuliaConf kind of pointed out a couple of issues.

I remember a lot of people saying "Now I don't need to learn Scala" after Java 8 came out.

Java 8 took a lot of the wind out of Scala's sails not by being better, but by showing enough improvement that the benefits of learning Scala looked less attractive than before.

That is part of it.

Platform languages take slowly the best features of guest languages.

Additionally, type inference, value classes and pattern matching might not be at Kotlin, Scala, Clojure level, but they are good enough for most devs without having to deal with all the extra stuff.

The JPMS represents what is probably the largest single change in Java's history. It significantly impacts the entire stack: language, libraries, and runtime/VM. In my experience the host of incompatibilities resulting from modules are not worth the trouble -- there's not much to gain from using them.

Generally the JPMS provide two benefits:

1. Since the JRE is restructured to use modules, it can be used piecemeal, which is great for embedded systems.

2. A module controls exposed packages -- only explicitly exported packages are accessible to dependent modules.

With this in mind it's difficult to justify the JPMS fallout: Why should #1 impact the much larger market of Java SE? #2 is nice, however we already have this feature with IDEs like IntelliJ IDEA, which provide robust compile-time module systems. And the runtime aspect of JPMS access control is hardly worthwhile; it's not security (reflection can always bypass that), so what is it providing exactly? Surely it doesn't fix the notorious "JAR hell" issue, you still need to shade jars or use OSGi.

Does #2 mean that you could, say, for Google Cloud’s SDK which heavily relies on Netty, avoid it exports Netty to the rest of your application, avoiding dependency hell?

Essentially since the JPMS prohibits two modules from defining the same package (aka package splitting), you can't avoid any kind of package-related hell. So if a project depends on the Google Cloud SDK it can NOT have its own version of Netty due to the package splitting restriction.

> #2 is nice, however we already have this feature with IDEs like IntelliJ IDEA

This hardly sounds like a standardized feature.

> and the runtime aspect of JPMS access control is hardly worthwhile; it's not security (reflection can always bypass that)

That is not true, access control is enforced both at compile time and at runtime.

> so what is it providing exactly?

Copied from the the Jigsaw requirements:

* Reliable configuration, to replace the brittle, error-prone class-path mechanism with a means for program components to declare explicit dependences upon one another;

* Strong encapsulation, to allow a component to declare which of its APIs are accessible by other components, and which are not;

* A scalable Java SE Platform, whose components can be assembled by developers into custom configurations that contain only the functionality actually required by an application;

* Greater platform integrity, to ensure that code that is internal to a platform implementation is not accessible from outside the implementation; and

* Improved performance, by applying whole-program optimization techniques to complete configurations of platform, library, and application components.

> This hardly sounds like a standardized feature.

IDE module systems reflect the standard module system used by standard build tooling such as Maven and Gradle.

> That is not true, access control is enforced both at compile time and at runtime.

Right... As I stated: the runtime aspect of JPMS access control is hardly worthwhile; it's not security (reflection can always bypass that). The compile-time module system already in place (maven/gradle) is already supported with IDEs.

> Jigsaw requirements

Reread my original comment.

Besides Spark, is there still a niche that Scala fills? Why wouldn’t you just use Kotlin or Java 11? I guess I should ask the inverse question too: why wouldn’t you just use Scala for everything?

Backend web services. Scala has top notch tools to model domain objects, handle a high volume of incoming requests, process transactions (including async ones). tl;dr: like the JVM and dislike root causing NPEs? Scala might be for you.

Scala is significantly more powerful than both Kotlin or Java 11. Why would you want to use either instead of Scala?

Interoperability and default non-nullability are both advantages of Kotlin.

Interoperability leaves a bit to be desired though.

Try to use Kotlin sequences, co-routines, lambdas (not SAM types) or operators from Java code.

Quite a lot of shops choose not to use Scala because of the power. For instance, I can easily write Haskell-like code with Scala and build DSLs galore, which for me is great. But what happens when you need to hire more developers? That's the rub.

You probably are better off not hiring those developers, then.

Slow compilation and build tools (scalac and sbt), buggy/overlycomplex standard lib, interoperability, better IDE support in alternatives, academia oriented.

Because Java is the systems language of the platform.

I don't want to bother with extra layers or be bound to JetBrains tooling.

Scala isn’t another layer, it compiles to JVM bytecode. Also, what does Scala have to do with JetBrains?

Try to use Scala from Java to see how those bytecodes look like.

It is another layer exactly because you need to translate back those bytecodes into Scala semantics when debugging, when everyone wraps Java libraries into Scala idiomatic wrappers.

I was referring to Kotlin regarding JetBrains.

Scala is one of the few languages where you can write an entire web app in the same language (ScalaJS + Scala).

This is incredibly useful when you pair it with RPC and a shared domain model.

I'd use Scala or Rust for everything.

In Java, one creates a 55 lines getter-setter class with concurrency bugs and accidental mutation risks, and maybe plus a 55 lines Builder too.

Whilst in Scala I create a 5 lines case class, immutable and thread safe, all that's needed.

Java is getting data classes (case classes in Scala), as well as value types.

Data classes are nice, but they are not a general substitution for Properties, which address the greater getter/setter boilerplate concern. That said, you can use project Lombok for that pretty straightforwardly. You can also use project Manifold[1] to add useful features many of which Scala lacks:

* Type-safe metaprogramming (like F# type providers)

* Structural Typing

* Extension methods

* String interpolation

* Templates

* Type-safe reflection

* [Un]Checked exceptions

[1]: https://github.com/manifold-systems/manifold

Interesting, I didn't know, thanks for mentioning.

Reply on news.ycombinator.com