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.
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).
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.
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.
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)
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.
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.
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.
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.
Slow compilation and build tools (scalac and sbt), buggy/overlycomplex standard lib, interoperability, better IDE support in alternatives, academia oriented.
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.
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)
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.
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.
41 comments
[ 3.4 ms ] story [ 94.7 ms ] threadLongterm, 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.
This is exactly the reason we do not use Scala anymore. Tired of learning new DSLs for every single problem.
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.
https://medium.com/@sinisalouc/whats-new-in-scala-3-28d9c11e...
I just read that post and so far there is nothing really that interesting. Maybe it is just me.
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.
I’m sure it requires more resources than Kotlin but phone hardware has greatly improved in the last 5 years.
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/
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)
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.
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.
Try to use Kotlin sequences, co-routines, lambdas (not SAM types) or operators from Java code.
I don't want to bother with extra layers or be bound to JetBrains tooling.
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.
This is incredibly useful when you pair it with RPC and a shared domain model.
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.
* 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
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.
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.
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.