4 ms·

Well, let's look at the JVM landscape. First of all Oracle has (finally) picked up the pace in terms of evolving Java and the JVM. This is a bit of a double ed

Well, let's look at the JVM landscape. First of all Oracle has (finally) picked up the pace in terms of evolving Java and the JVM. This is a bit of a double edged sword for alternative JVM languages since on the one hand JVM improvements (like current SAMs and value types in Java 10) are a big win for all involved, but on the other, Java's evolution is very much a threat to Scala, Kotlin, and Ceylon in particular* Why is Java's evolution a threat? As Java cherry picks functional idioms from, for example, Scala, the motivation for Java teams to pick up Scala is reduced. Arguably Kotlin is in a worse position as its main "problem" is being too similar to Java. Already Java has deprecated the `_` character so shouldn't be any surprise to see `roster.stream().filter(_.getGender() == Person.Sex.MALE)`, land in the language [1]...getting pretty Scala-like o_O Kotlin's window of opportunity is in the next 2-3 years, basically before Java 10 lands. If an ecosystem develops around it (likely one of the reasons adoption rates are so low at present) and their 1.0 comes on the scene soon, they can steal some limelight from Scala, and maybe put Ceylon in the rear view mirror. * Clojure and JRuby are probably safe given their non-Java roots, and Groovy, not sure where it would be without Gradle. [1] https://docs.oracle.com/javase/tutorial/collections/streams/ https://docs.oracle.com/javase/tutorial/collections/streams/

adrusi 11y ago
I find it highly unlikely that java would adopt the implicit lambdas using underscores from Scala. The rules regarding precedence themselves are quite simple, but they're not always what new users expect, and cause too much confusion to be appropriate in java. Much more likely is the use of the underscore as an anonymous placeholder in pattern matching. Although even full pattern matching seems a bit much for java in the near future. Pattern matching is more useful than implicit lambdas anyway, the latter being nothing more than a terser syntax for regular lambda expressions to approach the concision of Haskell's point free style without leading to code that's too semantically dense. Pattern matching actually makes new kinds of static guarantees possible.
- virtualwhys 11y ago
  > I find it highly unlikely that java would adopt the implicit lambdas using underscores from Scala Looks like you're right [1], see Goetz's comment in linked thread. Though that was 2 years ago, the language landscape has changed (notably Swift's arrival and M$ setting up shop on *nix) so Oracle may be a bit more willing to pull the trigger on some easy syntactic sugar to give Java the impression of being somewhat up-to-date with current languages. Underscore is earmarked for something regardless, we'll see.. [1] http://mail.openjdk.java.net/pipermail/lambda-dev/2013-August/010673.html http://mail.openjdk.java.net/pipermail/lambda-dev/2013-Augus...
joesmo 11y ago
I don't think any new additions to Java will threaten Clojure. Worst comes to worst, I see Clojure moving off the JVM if the platform becomes untenable in the future, though there's nothing to indicate that it would.
mcintyre1994 11y ago
In clr land we've already seen c# adopting a fair few functional things - I think largely ahead of Java. There's this pretty interesting article from an f# (if anyone's unaware that's a Microsoft built functional language on the clr) tutorial site addressing reasons to still use f# over it. It's quite opinionated but worth a read and largely applies to Java/functional on the jvm: http://fsharpforfunandprofit.com/posts/is-your-language-unreasonable/ http://fsharpforfunandprofit.com/posts/is-your-language-unre... They take a different view to the comparison, looking at things the language enforces more than features/syntax it permits. Of course backward compatibility and plain sanity stop Java making such enforcements so the argument is that the functional languages maintain some strong advantages.
- mike_hearn 11y ago
  There is a Haskell implementation for the JVM if you want a language like F# (it's called Frege). Kotlin has some FP features. You can easily make immutable data classes (one line definitions of struct like things), you have map/filter/reduce/etc with a much more efficient approach than Java 8's streams framework, the compiler knows about tail recursion, there's some basic forms of pattern matching. I suspect Kotlin will take a breather from new features for a while now to try and stabilise what they've got. But after that, I imagine a few more FP features might materialise.
  - mcintyre1994 11y ago
    Sorry, I think I was a bit unclear. I have no doubt the jvm can support a functional language - scala isn't bad and Kotlin looks really nice. My point is more that Java is constrained in how it can compete with functional jvm languages in much the same way c# is against functional clr ones. The linked article explains those limits a lot better than I could :)
    - mike_hearn 11y ago
      Ah, I see. Yes I misunderstood you, apologies.
  - 11y ago
mike_hearn 11y ago
I doubt it. Java 10 is very, very unlikely to match even a fraction of the features Kotlin has. Oracle is very obviously continuing Sun's strategy of focusing on the JVM rather than the Java language. Their roadmap is pretty clear for the coming years, and it's all things like value types, better arrays, better APIs, modularity, performance, better ways to do "unsafe" stuff, etc. The only major change to the Java language they seem to be exploring right now is improved generics/class specialisation, and only because that's needed for the value types project. Kotlin has basic things like real properties, which Java still lacks after two decades. Along with many other features. The big competitors for Kotlin are Scala and Ceylon.
- pron 11y ago
  Plus Oracle is actively encouraging alternative JVM languages.
- mahmoudimus 11y ago
  > Oracle is very obviously continuing Sun's strategy of focusing on the JVM rather than the Java language. Absolutely. Oracle's strategy is very simple: Java should serve as the assembly language for the server side. The JVM should be the de-facto runtime. Like pron suggests, they are actively encouraging alternative JVM languages and I wouldn't be surprised if they invest in the JRuby/Jython implementations for quicker adoption. As someone watching from the side, Oracle's strategy is brilliant.
  - mike_hearn 11y ago
    Oracle has been investing significant resources in JRuby for some time via the Graal/Truffle research projects. They're quite impressive.
vorg 11y ago
> Groovy, not sure where it would be without Gradle Gradle's bound to open up its build configuration as an API that any scripting language can use soon enough, so not sure where Groovy will be then as Android Studio ships Gradle with another default build language like JRuby, Jython, or even Clojure.

adrusi 11y ago

I find it highly unlikely that java would adopt the implicit lambdas using underscores from Scala. The rules regarding precedence themselves are quite simple, but they're not always what new users expect, and cause too much confusion to be appropriate in java. Much more likely is the use of the underscore as an anonymous placeholder in pattern matching. Although even full pattern matching seems a bit much for java in the near future. Pattern matching is more useful than implicit lambdas anyway, the latter being nothing more than a terser syntax for regular lambda expressions to approach the concision of Haskell's point free style without leading to code that's too semantically dense. Pattern matching actually makes new kinds of static guarantees possible.

virtualwhys 11y ago
> I find it highly unlikely that java would adopt the implicit lambdas using underscores from Scala Looks like you're right [1], see Goetz's comment in linked thread. Though that was 2 years ago, the language landscape has changed (notably Swift's arrival and M$ setting up shop on *nix) so Oracle may be a bit more willing to pull the trigger on some easy syntactic sugar to give Java the impression of being somewhat up-to-date with current languages. Underscore is earmarked for something regardless, we'll see.. [1] http://mail.openjdk.java.net/pipermail/lambda-dev/2013-August/010673.html http://mail.openjdk.java.net/pipermail/lambda-dev/2013-Augus...

joesmo 11y ago

I don't think any new additions to Java will threaten Clojure. Worst comes to worst, I see Clojure moving off the JVM if the platform becomes untenable in the future, though there's nothing to indicate that it would.

mcintyre1994 11y ago

In clr land we've already seen c# adopting a fair few functional things - I think largely ahead of Java. There's this pretty interesting article from an f# (if anyone's unaware that's a Microsoft built functional language on the clr) tutorial site addressing reasons to still use f# over it. It's quite opinionated but worth a read and largely applies to Java/functional on the jvm: http://fsharpforfunandprofit.com/posts/is-your-language-unreasonable/ http://fsharpforfunandprofit.com/posts/is-your-language-unre... They take a different view to the comparison, looking at things the language enforces more than features/syntax it permits. Of course backward compatibility and plain sanity stop Java making such enforcements so the argument is that the functional languages maintain some strong advantages.

mike_hearn 11y ago
There is a Haskell implementation for the JVM if you want a language like F# (it's called Frege). Kotlin has some FP features. You can easily make immutable data classes (one line definitions of struct like things), you have map/filter/reduce/etc with a much more efficient approach than Java 8's streams framework, the compiler knows about tail recursion, there's some basic forms of pattern matching. I suspect Kotlin will take a breather from new features for a while now to try and stabilise what they've got. But after that, I imagine a few more FP features might materialise.
- mcintyre1994 11y ago
  Sorry, I think I was a bit unclear. I have no doubt the jvm can support a functional language - scala isn't bad and Kotlin looks really nice. My point is more that Java is constrained in how it can compete with functional jvm languages in much the same way c# is against functional clr ones. The linked article explains those limits a lot better than I could :)
  - mike_hearn 11y ago
    Ah, I see. Yes I misunderstood you, apologies.
- 11y ago

mike_hearn 11y ago

I doubt it. Java 10 is very, very unlikely to match even a fraction of the features Kotlin has. Oracle is very obviously continuing Sun's strategy of focusing on the JVM rather than the Java language. Their roadmap is pretty clear for the coming years, and it's all things like value types, better arrays, better APIs, modularity, performance, better ways to do "unsafe" stuff, etc. The only major change to the Java language they seem to be exploring right now is improved generics/class specialisation, and only because that's needed for the value types project. Kotlin has basic things like real properties, which Java still lacks after two decades. Along with many other features. The big competitors for Kotlin are Scala and Ceylon.

pron 11y ago
Plus Oracle is actively encouraging alternative JVM languages.
mahmoudimus 11y ago
> Oracle is very obviously continuing Sun's strategy of focusing on the JVM rather than the Java language. Absolutely. Oracle's strategy is very simple: Java should serve as the assembly language for the server side. The JVM should be the de-facto runtime. Like pron suggests, they are actively encouraging alternative JVM languages and I wouldn't be surprised if they invest in the JRuby/Jython implementations for quicker adoption. As someone watching from the side, Oracle's strategy is brilliant.
- mike_hearn 11y ago
  Oracle has been investing significant resources in JRuby for some time via the Graal/Truffle research projects. They're quite impressive.

vorg 11y ago

> Groovy, not sure where it would be without Gradle Gradle's bound to open up its build configuration as an API that any scripting language can use soon enough, so not sure where Groovy will be then as Android Studio ships Gradle with another default build language like JRuby, Jython, or even Clojure.