I've honestly never heard anyone say that. Since Spring 5 it's pretty clear there's some interest in server-side Kotlin; there are several heavy-weights behind that.

However, it's fair to make a distinction between the slowly evolving Android runtime and the JVM. Java language features are catching up with Kotlin, and might even surpass it (I believe pattern matching might land in Java sooner than in Kotlin). Also Kotlin might get stuck for a while when big breaking changes finally come to Java (like Valhalla). I understand why some companies/teams think it's not worth it.

Still lots of kotlin-features I don't see land in java soon. My favorite is passing a lambda in brackets when it's the last argument to a function. Makes it easy to make semi-dsls and nice-looking code. So instead of

  myFun(someVar, { it.something() }) 

it can be written like

  myFun(someVar) {
    it.something()
  }

or if no parameters to the function other than the lambda like

  myFun {
   it.something()
  } 

making the function almost look and behave like a language keyword. I also use extension-functions a lot. Especially for libraries or legacy-java code we wont touch. Where I work we now use Kotlin for all new backend code. And we don't do any Android.

I abuse the hell out of this and @DSLMarker. Such a small but amazing feature.

I do that too, but a real macro facility would be a lot nicer. There are a lot of things that cannot nicely be implemented using the existing syntax.

Yep, wish we had that. I had to satisfy myself with annotations and kotlinpoet for now.

Very Groovy.

is that modeled on ruby ?

This is a very common idiom in Scala. Function definition is slightly different, but usage is the same.

Any example ? or an idiom name I can google ?

Groovy also does it. I have no idea what the name is though: https://mrhaki.blogspot.com/2009/11/groovy-goodness-passing-...

Not sure about the exact name. But kotlin also has "function with receiver" that together with this makes it very easy to write almost a custom domain language on top of kotlin.

Can't edit, but here's an explanation https://kotlinlang.org/docs/reference/type-safe-builders.htm...

Swift calls it trailing closure syntax

Ok so it's an explicit parameter, the function is just ~curried so you can just write it nicely.

Not at all, it is very common in ML languages, Smalltalk, and even Groovy already had it.

I never saw that idiom in any ml classes.. I'm honestly surprised

It is a common idiom for dealing with deterministic resource management, and takes advantage that in ML all functions are single parameter actually.

So you can partially specialize, and then the lambda gets the already allocated/opened resource, thus acting as region/arena resource allocator.

And you can combine it with currying to apply the concept to multiple kind of parameters.

I don't know, but you can do the exact same thing in Swift.

Spring sells to everyone, I am old enough to have seen that playbook with Groovy as main actor.

Groovy was good in what it set out to do, i.e. bringing Python freshness into the vast Java ecosystem.

I loved Grape for single-file scripts. Does any language have similar single-file dependency manager? I guess Go, but then, you have to compile Go, so it might not be as useful, because you distribute binaries anyways.

Scala does, thanks to Ammonite:

https://ammonite.io/#import$ivy

>I believe pattern matching might land in Java sooner than in Kotlin

Depends on what you call pattern matching. Kotlin had pattern matching from day one, but it's just one level, Java might have it recursive by java 19

Calling Kotlin's when pattern matching is a stretch. Even the official documentation doesn't call it like that anywhere.

Well, fr sealed classes it's quite good, but yeah, nothing like the scalas and haskells of this life

Because Android is Kotlin's selling platform, on the JVM it will be as relevant as Beanshell, jtcl, jython, clojure, scala, and many other guest languages.

Guest languages relevance always fades away as the platform language improves and the FFI gets out of touch with that old version of the language.

C18 on UNIX vs C++, JavaScript vs Typescript (see private members), and when time comes inline classes/reiffed generics/SIMD types vs being able to target both Android and JVM on Kotlin's case.

Old men are always trying to discount progress as reiteration of what they already saw to fail.

But in reality, it's not the same thing, it's not the same time, not the same market environment.

Kotlin can succeed where others failed before because just about everything about it is incomparable with sorts like Beanshell.

Young men are always trying to count progress as the reiteration of what has already come before them.

In reality, while the differences are minor, they are the same thing. Time fades away, and market dynamics operate the same as they did 10,20..100 years ago.

Yes, that happens with young people as well.

The hubris is in using absolute statements ("platform languages always win") instead of being a little bit more humble with their projections. Old men should know better that history rarely unfolds as expected.

Old wise men know that young people forget history too soon, and we all know what happens when history gets forgotten.

Indeed, bare my words, in about 10 years time, Kotlin will only be a thing on Android, assuming Fuchsia wasn't brought into the market as Android's successor.

I’ll second this prediction.

Kotlin has made too many promises that it can't keep.

Care to remind us ?

Relevant for who? I will always strive for using the language that fits my needs regardless of what the majority thinks

Can you explain what the difference is between C18 and C++ on Unix?

C++ copy-paste compatibility with C is based on C89, since then C has introduced many features that won't compile under a C++ compiler.

ISO C++ has kept upgrading the support regarding ISO C libraries, as long as new grammar features aren't required.

Even ISO C++20 has finally added support for structure member initialisation, it is just a subset of what is possible in C.

So while UNIX vendors are free to use all C features, due to their symbiotic relationship, ISO C++ applications can only safely compile C89 code.

No full structure member initialisation, restrict, VLA,...