Kotlin: A Language with a Bright Future
As a Scala programmer, Kotlin always feels like a language that frustratingly <i>almost</i> gets it, but is infuriatingly unwilling to listen to experience of what works in large codebases. Look at the examples on <a href="https:&#x2F;&#x2F;philipnilsson.github.io&#x2F;Badness10k&#x2F;escaping-hell-with-monads&#x2F;" rel="nofollow">https:&#x2F;&#x2F;philipnilsson.github.io&#x2F;Badness10k&#x2F;escaping-hell-wit...</a> - I think Kotlin has literally every one of those ad hoc solutions built into the language, but stubbornly avoids making the generalisation. In small examples ad hoc solutions look great, but to succeed in large codebases a language needs a generality and consistency that Kotlin lacks.<p>E.g. already there&#x27;s no way to reuse logic between code paths that operate on Kotlin nullable types, Java Options (needed for compatibility with Java streams or more generally other JVM libraries), or rust-style Result types (for which there are several Kotlin libraries already, because it&#x27;s a very useful concept and the language mostly has the facilities to support it), even though all three behave almost identically and you would often want to do the same thing in all three cases. But since the language won&#x27;t let you represent what these types have in common, your only option is to copy&#x2F;paste the code.