I'll read your article first, thanks!

It's not as elegant as cats because Kotlin's type system isn't as strong as Scala's, but it affords with much of the same utility around being able to express effects in the type system

Sorry back on topic:

A risk with using obscure languages is that they might not stick around

This is a concern that came up here as well, but more so because that there was some anxiety around Kotlin not being endorsed by Google in any major way, and the chance that support might dwindle further because Google might be pushing e.g. Dart or other languages in the future

But maybe it was being overly defensive

We drew a lot of comparisons to Apple and Swift, where Apple is heavily pushing its own language

Good read, thanks again.

So if Google ignores it, that doesn't change much about the original value calculation. It was never a bet on getting Google's support. I worked for Google for nearly 8 years and understand the internal culture there quite well: I would not expect Google to ever formally endorse a technology they haven't built themselves unless they have no real choice.

But if developers end up picking up Kotlin anyway, then I doubt they'll make a fuss about it either. They don't have a language that can credibly compete with Kotlin. Go and Dart are rather not helpful to Android devs.

WRT functional style, what I meant by that is that we pretty frequently write calculations as chains of maps/filters/folds/groupBys/etc, and there are very few mutable objects in our codebase. Stuff like cats and scalaz is a whole other level. I admit to being somewhat skeptical of scalaz at least: I'm not a huge fan of library code that liberally uses untypeable unicode characters in its source 😞 that seems to indicate a worryingly low interest in practicality. I don't know much about cats, and obviously I'll give you some pinches of salt for free here, as I haven't written any code that uses scalaz or cats

Outside of defining DSLs with interpreters, I've kept a lid on Haskell-style code in our codebase. Unfortunately many of the bank devs that turn up on our doorstep are frequently flummoxed even by things like generics, so we have to keep the API we expose as simple as possible. Just using something that isn't Java at all is pushing it 😞

so, you don't have to resort to

\/

to say you want an

Either

🙂

I also didn't adopt any of that in my Kotlin port

well, let us know when the port is available, I'll be interested in checking it out!