5 ms·
Scala on Track to Support Java 9 Module System
- joneholland 7y agoNot a lot of progress in the last year.
- pjmlp 7y agoThe 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.
- joneholland 7y agoWe 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.
- mruts 7y agoI 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).
- solidsnack9000 7y agoWhat kinds of things are you guys doing in Kotlin? Anything server-side?
- threeseed 7y agoNot 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-28d9c11eec30 https://medium.com/@sinisalouc/whats-new-in-scala-3-28d9c11e...
- StreamBright 7y agoI 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.
- pjmlp 7y agoI 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.
- melling 7y agoScala 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 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/ https://typelevel.org/cats/
- threeseed 7y agoIf you really want to see the future of Scala look at ZIO (http://zio.dev 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 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 https://slinky.dev)
- pjmlp 7y agoHeather Miller's recent talk at JuliaConf kind of pointed out a couple of issues.
- ibains 7y agoWe'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.
- StreamBright 7y ago>> 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.
- ferzul 7y agoisn't the alternative to a dsl just constructing classes, giving them to each other, and using a bunch of stringy typed arguments?
- StreamBright 7y ago>> 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.
- dionian 7y agohard to have a safer bet than the JVM as your platform. not like changes like Jigsaw come around that often
- twblalock 7y agoI 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.
- pjmlp 7y agoThat 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.
- jxi 7y agoBesides 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?
- dmit 7y agoBackend 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.
- mruts 7y agoScala is significantly more powerful than both Kotlin or Java 11. Why would you want to use either instead of Scala?
- solidsnack9000 7y agoInteroperability and default non-nullability are both advantages of Kotlin.
- pjmlp 7y agoInteroperability leaves a bit to be desired though. Try to use Kotlin sequences, co-routines, lambdas (not SAM types) or operators from Java code.
- mckinney 7y agoQuite 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.
- mruts 7y agoYou probably are better off not hiring those developers, then.
- mckinney 7y agoThe 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.
- stingraycharles 7y agoDoes #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?
- mckinney 7y agoEssentially 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.
- kasperni 7y ago> #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.