top | item 42483929

(no title)

m0zzie | 1 year ago

The value in the conversion of existing code in this particular case isn't 100% clear to me either, but I think calling Kotlin a weaker choice than Java at this time is naive, particularly when preceding that with "there are a mountain of tools" that you can bolt on to Java to give it features that are built in to Kotlin.

What makes Kotlin such a strong choice for many orgs today is its batteries-included multiplatform capability. We are able to write data models, validation logic, business logic, etc just once and compile to JVM, WASM, and native targets. For orgs with very large codebases and frontend applications (web + iOS + Android) this is an attractive capability because we can have a single codebase for a ton of core functionality, and have each frontend import a library which is native to its own platform.

Of course many technologies with this promise have come and gone over the years, but this is the first one with a strong backing that has allowed us to _natively_ interoperate with each target platform.

I believe these are all driving factors that have been pushing well known companies, that were previously Java shops, toward Kotlin. If you speak to a broad range of people in the industry you'll find many more orgs moving from Java to Kotlin than from Kotlin back to Java. We can simply get more work done with less code and ship to all our frontend platforms, and unless Java can do the same, I don't see the industry moving in that direction.

discuss

order

hinkley|1 year ago

It’s like marriage. Yes there are tools that can give you most of the same rights and privileges as marriage, or you could just get married and get all of that for the cost of writing one check and signing some papers. No lawyers. Done. Move on with your life.

The question of optional things is always laid out as if the choices of my coworkers do not exist. Are you expecting me to work solo, or to be a bloody tyrant who pushes through all of my own ideas over the objections of an entire team? These are some of the most antisocial people in any debate on software. No I don’t get to just chose to use or ignore a tool in an ecosystem. That’s why picking a system with batteries included is a simpler transaction. I can go to a new company and have expectations, not arguments.

wiseowise|1 year ago

You forgot that you need to have a whole infra team that is going to maintain all the shitty Gradle configuration KMP requires.

sebazzz|1 year ago

> What makes Kotlin such a strong choice for many orgs today is its batteries-included multiplatform capability. We are able to write data models, validation logic, business logic, etc just once and compile to JVM, WASM, and native targets.

Not familiar with Kotlin but how does that work? Does it come included with a PAL? Because it you want to be platform agnostic, you can't for instance use a Java RegularExpression in your platform agnostic code.

rnentjes|1 year ago

The PAL (Platform Abstraction Layer I assume) is just the stdlib that is provided. The stdlib is not the same for all platforms, as can be seen in the documentation. A regex implementation is provided for all platforms, but is not quite the same on all platforms: https://kotlinlang.org/api/core/kotlin-stdlib/kotlin.text/-r...

In shared code you can define interfaces that have to be implemented by any platform you use.