12 ms·

Unfortunately it looks like Java is going to evolve enough to take the wind out of the sails of Kotlin and Scala for most dev shops. I guess the positive take i

• jayd16 5y ago
  Kotlin is still run by the company that makes the best Java ide, no? I don't expect kotlin to get pushed out so easily.
• Waterluvian 5y ago
  I don’t follow why this is unfortunate?
  • tablespoon 5y ago
    > I don’t follow why this is unfortunate? I'm guessing Java hate, which is kind of fashionable. If Java evolves to stay relevant, it won't be usurped and fade away.
  • CuriousCosmic 5y ago
    A lot of people have migrated away from Java to better JVM languages. If Java actually keeps improving, there's a reasonable likelihood that people will stop migrating and those that have may come back to Java from these other langs. Long term this could lead to a loss of maintenance for tools and libraries for these languages which could kill them and leave those that migrated with a dead & decaying ecosystem. Of course this is a bit of a stretch but it's not unheard of.
    • pjmlp 5y ago
      A tiny drop, an endless collection of guest language that goes back to Beanshell, many of which now forgotten.
    • ISL 5y ago
      If people left Java for other language(s), wouldn't that leave Java with a decaying ecosystem?
      • spockz 5y ago
        Most of them stayed somewhere on the jvm though. Still in the ecosystem.
      • Sevaris 5y ago
        Maybe worry about leveling the playing field first? There's so much money and research and development going into Java that there's no possible way for Java to end up with a "decaying ecosystem" inside the next twenty years. It's like pointing out DuckDuckGo and worrying about Google.
    • tunesmith 5y ago
      Over the last short while I've seen Lightbend announce ceasing support for Play, others express that Slick is likely abandonware, and also seen my chosen Play authentication library, silhouette, get archived on github. All of this has impacted my favorite side project that I've been slowly plugging away on. Silhouette is probably just because of one guy's schedule, but Play/Slick seems like after-effects of lightbend's layoffs many months ago, and while I don't know the cause of those it seems plausible it's because of the kind of thing you describe above.
  • atomicnumber3 5y ago
    I assume OP prefers Kotlin or Scala. Personally, I think one of my favorite things about Java is that, all things considered, it's a small-ish language. So I'm glad that Java is both willing to evolve (slowly, letting other people try stuff out first) but also clearly focused on a curated feature set and resistant to letting new stuff in to bloat it. I am very happy to deal with minor things like no multiline string support if it means we get to avoid being a terrible mess of language features that ruby, scala, python, etc have accrued in a relatively quicker timescale. I was fairly sad around the java 6-7 days where we went quite a long time with no visibly major new language features (diamond inference was 7's big thing, lol). So it is nice that we're moving a bit faster than that, now.
    • pooya72 5y ago
      By multiline strings are you referring to text blocks? Those have been added to the language in Java 15: https://docs.oracle.com/en/java/javase/15/text-blocks/index.html https://docs.oracle.com/en/java/javase/15/text-blocks/index.... .
      • atomicnumber3 5y ago
        Oh, sorry, I know, I mentioned it specifically because it was "only" just added in Java 15 (which is basically "now" in Java timescales heh, and has only literally just now (with 17) made it into LTS AdoptOpenJDK releases, which also haven't quite landed on many distros package repositories, etc etc.). So for some weird value of "right now" Java still doesn't quite have multi line strings due to its newness.
      • EdwardDiego 5y ago
        Tbh I still crave Kotlins inline string interpolation.
        • kaba0 5y ago
          A “superior” implementation is in the works with templated strings. It will look something like this: STR.”text with \\{variable}”, but anything implementing the TemplatedString interface can change the behavior of interpolation. There is not even a requirement to produce strings only!
  • cageface 5y ago
    What I don't want to see happen is innovation stop in JVM languages and then Java, no longer under threat, also stops innovating.
    • kaba0 5y ago
      Java has basically no threat from Kotlin and the like. The reason it innovates now is simply Oracle’s increased pouring of money into the platform, which is especially visible now compared to the stagnation of the end of the Sun era.
• jmfldn 5y ago
  This is great not unfortunate. If Java improves because of Scala and Kotlin then so much the better, this is how languages evolve. If it really does evolve to remove the need for a better Java then it would be nice if people switched away from Kotlin and back to it. Scala can then carry on cementing its niche as a powerful commercial FP language. No hate for Kotlin at all but it seems like in that world, there might be no need for it. Scala is better for FP and if Java 17 is the better Java then great.
  • cutler 5y ago
    Android will always be Kotlin-first. That's a pretty huge market.
    • jpgvm 5y ago
      I think people underestimate how deep this integration is going. Compose relies on extensions to the Kotlin compiler. The future of Android and Kotlin are pretty much tied together at this point.
    • jayd16 5y ago
      Android used to be always Java first. It could change again.
      • vbezhenar 5y ago
        Most likely to Flutter. When Google will be ready to ditch Android API.
        • hota_mazi 5y ago
          Android is based on the JVM, it will never switch to Flutter (and an aggravating factor is that Dart is an inferior version of Kotlin).
          • pjmlp 5y ago
            If you want some fun watching Jake Wartorn's opinion on it, https://youtu.be/VX6nAvRWQg4 https://youtu.be/VX6nAvRWQg4
• Smaug123 5y ago
  I think one could argue exactly the same thing for the same reasons about C# vs F# on .NET, which is my area of expertise - but honestly I'm not so sure it's true. C# has grown into an enormous language as it tries (consciously or not) to subsume F#, and F# is always going to remain so much cleaner just because you aren't having to ignore 90% of the language features when you code in it.
  • throw868788 5y ago
    Agree with this. What's more interesting is on the feature level languages do borrow/converge on each other in order to try to secure a position in the market. I note that as an example Java is consdering a .NET like Span feature (https://openjdk.java.net/jeps/412 https://openjdk.java.net/jeps/412) as an example probably to close the gap w.r.t performance. There are others. What matters more in all honesty, and what's hard to change IMO is: - The base of the language (is it verbose, how the base features interact with each other) vs being "tacked on". A language with these features initially. e.g. you mention F# and I know it uses HM type inference, immutability by null, makes null hard to express by default, etc. - Anything that breaks backwards compatibility (e.g. Java's generic implementation) for example including existing API's. Adding Async afterwards takes time, and changing the underlying model of the language (e.g. Python's GIL, OcAML multithreading) takes time and needs a lot more consideration. Its code, anything can change, its just harder and maybe easier to take something that was designed for that case initially. Being a polygot isn't a bad thing per se I think if it can be justified tech wise.
• pjmlp 5y ago
  Except without Java they are meaningless.
• 5e92cb50239222b 5y ago
  This happens all the time with "guest" languages. A few old salts have been prophesying this right here on HN since Kotlin first came out. I think it'll still be used on Android though, it's hard to see Google pushing Android development back to Java.
• mavelikara 5y ago
  Java's implementation of generics was heavily influenced by a language called Pizza. Sun hired the author of the language, Martin Odersky, to write the compiler for Java. Odersky later went on to develop Scala. Java improving borrowing ideas from other JVM languages had happened in the past, and that has made the ecosystem stronger. Nothing unfortunate about it.
• 66fm472tjy7 5y ago
  I don't think this is going to happen with Brian Goetz as language architect. He refuses to add many features that would address everyday pain points such as: * null safe navigation operator * properties * mutable records * a way to ignore checked exceptions (or at least having the stream API take functional interfaces that can throw exceptions) * adding functional methods like .filter()/.map() directly to collections instead of having to .stream().map(..).collect(toList())
  • nikeee 5y ago
    IMHO safe navigation only makes sense when the compiler is able to reason about nullability, meaning nullability is rooted in the type system. That's the case for Kotlin and not for Java. Otherwise, you've got a high risk of developers inserting a ? to fix a bug, which only fixes the symptoms. As of now, Optional#map seems to be the way to go.
  • bestinterest 5y ago
    Is that true though? nullability is a area I've heard /u/pron mention may be tackled in the future, mutable records seem like they will be tackled with the 'withers' concept in the future. Checked exceptions + changing the sugar of .stream().map I don't see ever changing. Properties I am unsure of.
    • cogman10 5y ago
      AFAIK, the fate of nullability is tied pretty directly to Valhalla. It's constantly being brought up there.
    • laurent92 5y ago
      Why should it be in the future. The syntax of .stream() has been awfully verbose since Java 8: in the middle of “.stream()….collect(toList())”, you need to squint to find the actual function name being applied between the flood of polluting calls, which loses the appeal of functional programming. In my company we have f(list).map(…), which is a wrapper for the streams. But newcomers don’t like it because it’s not the standard.
  • 5y ago
• hocuspocus 5y ago
  Scala is fine. People understood it's not really worth it as a "better Java". Companies that choose Scala in 2021 are using either big data frameworks (where Python bindings are the most common alternative to Scala, not Java), or functional ecosystems (Typelevel, Zio). Scala 3 has taken an interesting direction and to me it seems that Odersky wants to win Python developers over rather than Java shops using Spring. New features in Java and the JVM (records, loom, valhalla, ...) are directly going to benefit Scala and make it even better. On the contrary, Kotlin's essence has always been threatened by the fact it's nothing more than a better Java. I assume there's still a big demand for that on Android, but if you're running on a recent JVM, I would certainly consider Java over Kotlin.
  • tunesmith 5y ago
    Which is a bummer for folks that loves the cleanliness and power of "basic Scala" (pure functions, immutability) without wanting to get into deep FP theory (typelevel, zio). That has been a really nice pocket to be in for teams that have the discipline to not get clever with it. Same with teams wanting to integrate with Akka on scala.
    • Zababa 5y ago
      I think between Scala 3 and the Li Hayoi ecosystem, there is a path to simplicity. But that usually means you lose part of the appeal of the language, since you can't use some parts of the ecosystem.
    • hocuspocus 5y ago
      Zio is pretty much what you want. No need to understand category theory, no over-reliance on implicit resolution, ... That said you don't need to understand that much to use high-level libraries in the Typelevel ecosystem. And when I do need to reach for low-level constructs, I find nice that everything is built upon clean and composable abstractions. You mention Akka, it's kind of its own beast. The inner workings go definitely way beyond "better Java", yet Lightbend needs to provide a surface API that plays nice with Java interop. It's not an ecosystem easy to navigate in my opinion.
  • 5y ago
• leroman 5y ago
  Scala still has a better design at its base, which is missing from Java and I don’t see how Java can retro-fit it into the language, Immutability is a big part of being functional and doing safe multi-threading stuff, java is doing all the good syntactic stuff (case class, switches with guards etc) but without immutability it’s a far cry from the same facility in Scala land. Having said that, this trend is welcome for every time I have to write Java and makes it feel more natural to me as an old time Scala developer.
  • kaba0 5y ago
    With records, Java does try to embrace immutability to a certain degree, but of course it will never be completely immutable.
• pron 5y ago
  The cause and effect are quite right, though. The reason Kotlin was designed in 2009-2010 was because Java became stagnant, not by choice, but due to Sun's demise. After the acquisition and an adjustment period, Oracle gradually increased investment, and the evolution pace got back to it's "normal" course. So Java's "revival" and Kotlin's existence are, indeed, related, but one did not cause the other; rather, they both have a common cause.
• whyenot 5y ago
  I don't see it as unfortunate. It shows that Java is a living language that continues to improve and change to match the needs of its users. Compare this to Common Lisp, which has not change in any meaningful way since 1984. A lisp-er would probably say that CL is so malleable that it hasn't needed to change, but I'm not so sure about that.
• armchairhacker 5y ago
  Kotlin is still way ahead of Java with IMO essential features like: - Explicit null - Extension methods - Getters/setters which use property syntax - == instead of Object.equals confusion Also Kotlin's this-scoping and delegated properties, while they take a while to get used to, can be incredibly useful. They make it possible for to write typesafe DSLs like kotlin-html. Moreover, Kotlin is usually very easy to integrate with existing Java projects. Setting up Kotlin in Gradle is just adding a plugin, and Kotlin automatically imports and exports java code. And it runs on the JVM so it will support most platforms that also support Java. And one of the top Java IDEs and contributors (JetBrains) maintains and prioritizes Kotlin.