6 ms·

One of the goals of Project Amber [1][2] is to move the language towards a more data-oriented programming model. With Records, patterns, sealed classes, etc., i

One of the goals of Project Amber [1][2] is to move the language towards a more data-oriented programming model. With Records, patterns, sealed classes, etc., it should feel much less verbose over time. And unrelated to your concern but addressing some of the learning overhead, see Paving the Onramp. [3] [1] https://openjdk.org/projects/amber/ https://openjdk.org/projects/amber/ [2] https://inside.java/tag/amber https://inside.java/tag/amber [3] https://openjdk.org/projects/amber/design-notes/on-ramp https://openjdk.org/projects/amber/design-notes/on-ramp

halfmatthalfcat 4y ago
So...Scala?
- carimura 4y ago
  Sure, but you could refer to the lineage of a dozen languages. Most of the world runs Java and evolving it takes care and consideration not to alienate a massive user base and ensuring that it evolves in the right way, not quick responses to fashions and trends.
  - eternalban 4y ago
    Isn't there natural interop between Java and Scala? Why needlessly enlarge the language.
    - vips7L 4y ago
      Scala is super complex, introduces breaking changes all the time, is super slow to compile, multi-language projects are also complex, and the decisions that are right for Scala may not be right for Java.
      - oweiler 4y ago
        Scala is also on the way out, adoption is steadily decreasing.
        halfmatthalfcat 4y ago
        I'm not sure I would characterize it as "steadily". I think it's leveled off but I would agree it's not gaining any market share currently.
        hf_twink 4y ago
        Yep, we’re migrating away from it at work too, too many problems, too slow to work with, and too much breaking.
      - bcrosby95 4y ago
        I wish Scala leaned into being a Haskell-like (opinionated statically typed functional language) for the JVM rather than a kitchen sink.
        suresk 4y ago
        There was definitely a large and vocal part of the community that wanted that, but I think early on there was a lot of tension between Scala being "better Java" and "Haskell for the JVM", and that probably hindered a lot of adoption.
        gigatexal 4y ago
        Hmm I was thinking of learning Scala. Good to know it’s on the down trend.
        kaba0 4y ago
        I wouldn’t take these trends too seriously - scala is still huge, and the recent revamp (scala 3) might turn that “trend” around. Also, learning a language with new idioms is always worth it, regardless of whether you end up using it.
      - ebruchez 4y ago
        The "super complex" and "introduces breaking changes all the time" comments are unsubstantiated FUD. Scala has evolved a lot in the last few years, particularly in the area of binary compatibility. It's a wonderful language and I can only recommend others try it. This from a programmer very happy with Scala.
        vips7L 4y ago
        And this is from a programmer that is not happy with Scala. Every single time I've upgraded the compiler there is a breaking change. They don't strictly follow semver. Most recently upgrading from the 2.11 to 2.13 compiler they made breaking serial version uid changes (I know don't use java serialization, but that wasn't my decision) and none of it was noted in the release notes. When it comes to super complex just look at any of the type signatures of the standard library for collections: def ++[B >: A, That](that: GenTraversableOnce[B])(implicit bf: CanBuildFrom[IndexedSeq[A], B, That]): That Comparing this to Java it is "super complex". IntelliJ can't even figure out the types sometimes.
        suresk 4y ago
        And then when a dependency of one of your dependencies is broken agains the latest version. I know some of this has been cleaned up, but it is one of the main reasons I no longer use Scala - I have a rule about how long I'm willing to spend on build issues vs actually writing code, and Scala was always on the wrong side of that. re: Complexity - At least the signatures for the core collections have been cleaned up a fair amount. That said, the richness of the type system and the prevalence of operator overloading always made it feel like a language you could be really productive in once you knew the language and the current codebase really well, but was really hard to just read through unfamiliar code and know what is going on.
        kagakuninja 4y ago
        > And then when a dependency of one of your dependencies is broken agains the latest version How is this any worse than Java? My most vexing dependency-hell issues have involved breaking API changes to Hamcrest matchers and Apache Http Client; more recently Jackson-databind. All of those are Java libraries, brought in via transitive dependencies, usually from Java libraries.
    - halfmatthalfcat 4y ago
      Yes, and you can (via SBT) slowly introduce Scala into an existing Java codebase quite easily.
      - vips7L 4y ago
        I wouldn't wish SBT on my worst enemies.
        halfmatthalfcat 4y ago
        Surely with GPT, it can't be that bad anymore ;p
        vips7L 4y ago
        We just updated our version and sometimes it'll get stuck in an infinite compile recursion loop. I dream of maven.
        therealdrag0 4y ago
        It’s terrible. But at least I rarely have to touch the config. I guess the silver lining is it’s so bad we don’t use it for anything besides dependency management so configs are simple and just copy pasted between projects and rarely touched.
        dxxvi 4y ago
        A java project never uses sbt. Both maven and gradle have plugins for Scala.
      - lmm 4y ago
        SBT is the worst thing about the Scala ecosystem. Just stick with Maven (or Gradle, if that's what you're using), enable the Scala plugin, and start trying Scala in more flexible leaf areas of your program (e.g. integration tests, ancillary tools, data migrations). See if it feels right for you.
      - hf_twink 4y ago
        Mixed compilation is absolutely terrible (slow) with Gradle, is it faster with SBT?
    - snuxoll 4y ago
      Sure, but what about when you want to pull a Kotlin library into a Scala application? It works, but usually only works well if the library author limited themselves to the subset of the language that interops with Java (the language). More features in Java (the language) gives other JVM languages a larger set of tools to design interop support around, while letting them remain a place for these features to incubate without the headache of the JEP. Sometimes these language-level changes may come with modifications to the JVM to support them as well, letting other languages clean up their implementations. The whole situation works pretty well IMO.
srparish 4y ago
Any word on when some of project amber features will come out of preview? I get excited each JVM release for some of those features, but it seems like most of the releases the preview count just gets bumped, and a few more get added to the preview holding pattern.
- pron 4y ago
  Text blocks, var, records, sealed classes, and pattern matching in instanceof have been out of preview for some time, but two more features -- record patterns (https://openjdk.org/jeps/440 https://openjdk.org/jeps/440) and pattern matching in switch (https://openjdk.org/jeps/441 https://openjdk.org/jeps/441) -- are about to come out of preview.
gigatexal 4y ago
Very cool!
marwis 4y ago
Is there any work to make records actually usable out of the box? Things like copying or creating derived records are a huge pain (or slight pain with code generators) while other languages have solved this long ago (even JS and C#).
- kaba0 4y ago
  https://github.com/openjdk/amber-docs/blob/master/eg-drafts/reconstruction-records-and-classes.md https://github.com/openjdk/amber-docs/blob/master/eg-drafts/... This is the vague plan.

halfmatthalfcat 4y ago

So...Scala?

carimura 4y ago
Sure, but you could refer to the lineage of a dozen languages. Most of the world runs Java and evolving it takes care and consideration not to alienate a massive user base and ensuring that it evolves in the right way, not quick responses to fashions and trends.
- eternalban 4y ago
  Isn't there natural interop between Java and Scala? Why needlessly enlarge the language.
  - vips7L 4y ago
    Scala is super complex, introduces breaking changes all the time, is super slow to compile, multi-language projects are also complex, and the decisions that are right for Scala may not be right for Java.
    - oweiler 4y ago
      Scala is also on the way out, adoption is steadily decreasing.
      - halfmatthalfcat 4y ago
        I'm not sure I would characterize it as "steadily". I think it's leveled off but I would agree it's not gaining any market share currently.
      - hf_twink 4y ago
        Yep, we’re migrating away from it at work too, too many problems, too slow to work with, and too much breaking.
    - bcrosby95 4y ago
      I wish Scala leaned into being a Haskell-like (opinionated statically typed functional language) for the JVM rather than a kitchen sink.
      - suresk 4y ago
        There was definitely a large and vocal part of the community that wanted that, but I think early on there was a lot of tension between Scala being "better Java" and "Haskell for the JVM", and that probably hindered a lot of adoption.
      - gigatexal 4y ago
        Hmm I was thinking of learning Scala. Good to know it’s on the down trend.
        kaba0 4y ago
        I wouldn’t take these trends too seriously - scala is still huge, and the recent revamp (scala 3) might turn that “trend” around. Also, learning a language with new idioms is always worth it, regardless of whether you end up using it.
    - ebruchez 4y ago
      The "super complex" and "introduces breaking changes all the time" comments are unsubstantiated FUD. Scala has evolved a lot in the last few years, particularly in the area of binary compatibility. It's a wonderful language and I can only recommend others try it. This from a programmer very happy with Scala.
      - vips7L 4y ago
        And this is from a programmer that is not happy with Scala. Every single time I've upgraded the compiler there is a breaking change. They don't strictly follow semver. Most recently upgrading from the 2.11 to 2.13 compiler they made breaking serial version uid changes (I know don't use java serialization, but that wasn't my decision) and none of it was noted in the release notes. When it comes to super complex just look at any of the type signatures of the standard library for collections: def ++[B >: A, That](that: GenTraversableOnce[B])(implicit bf: CanBuildFrom[IndexedSeq[A], B, That]): That Comparing this to Java it is "super complex". IntelliJ can't even figure out the types sometimes.
        suresk 4y ago
        And then when a dependency of one of your dependencies is broken agains the latest version. I know some of this has been cleaned up, but it is one of the main reasons I no longer use Scala - I have a rule about how long I'm willing to spend on build issues vs actually writing code, and Scala was always on the wrong side of that. re: Complexity - At least the signatures for the core collections have been cleaned up a fair amount. That said, the richness of the type system and the prevalence of operator overloading always made it feel like a language you could be really productive in once you knew the language and the current codebase really well, but was really hard to just read through unfamiliar code and know what is going on.
        kagakuninja 4y ago
        > And then when a dependency of one of your dependencies is broken agains the latest version How is this any worse than Java? My most vexing dependency-hell issues have involved breaking API changes to Hamcrest matchers and Apache Http Client; more recently Jackson-databind. All of those are Java libraries, brought in via transitive dependencies, usually from Java libraries.
  - halfmatthalfcat 4y ago
    Yes, and you can (via SBT) slowly introduce Scala into an existing Java codebase quite easily.
    - vips7L 4y ago
      I wouldn't wish SBT on my worst enemies.
      - halfmatthalfcat 4y ago
        Surely with GPT, it can't be that bad anymore ;p
        vips7L 4y ago
        We just updated our version and sometimes it'll get stuck in an infinite compile recursion loop. I dream of maven.
      - therealdrag0 4y ago
        It’s terrible. But at least I rarely have to touch the config. I guess the silver lining is it’s so bad we don’t use it for anything besides dependency management so configs are simple and just copy pasted between projects and rarely touched.
      - dxxvi 4y ago
        A java project never uses sbt. Both maven and gradle have plugins for Scala.
    - lmm 4y ago
      SBT is the worst thing about the Scala ecosystem. Just stick with Maven (or Gradle, if that's what you're using), enable the Scala plugin, and start trying Scala in more flexible leaf areas of your program (e.g. integration tests, ancillary tools, data migrations). See if it feels right for you.
    - hf_twink 4y ago
      Mixed compilation is absolutely terrible (slow) with Gradle, is it faster with SBT?
  - snuxoll 4y ago
    Sure, but what about when you want to pull a Kotlin library into a Scala application? It works, but usually only works well if the library author limited themselves to the subset of the language that interops with Java (the language). More features in Java (the language) gives other JVM languages a larger set of tools to design interop support around, while letting them remain a place for these features to incubate without the headache of the JEP. Sometimes these language-level changes may come with modifications to the JVM to support them as well, letting other languages clean up their implementations. The whole situation works pretty well IMO.

srparish 4y ago

Any word on when some of project amber features will come out of preview? I get excited each JVM release for some of those features, but it seems like most of the releases the preview count just gets bumped, and a few more get added to the preview holding pattern.

pron 4y ago
Text blocks, var, records, sealed classes, and pattern matching in instanceof have been out of preview for some time, but two more features -- record patterns (https://openjdk.org/jeps/440 https://openjdk.org/jeps/440) and pattern matching in switch (https://openjdk.org/jeps/441 https://openjdk.org/jeps/441) -- are about to come out of preview.

gigatexal 4y ago

Very cool!

marwis 4y ago

Is there any work to make records actually usable out of the box? Things like copying or creating derived records are a huge pain (or slight pain with code generators) while other languages have solved this long ago (even JS and C#).

kaba0 4y ago
https://github.com/openjdk/amber-docs/blob/master/eg-drafts/reconstruction-records-and-classes.md https://github.com/openjdk/amber-docs/blob/master/eg-drafts/... This is the vague plan.