Hacker News new | past | comments | ask | show | jobs | submit login

> iOS compatibility-ish

I don’t know how well it works, but we have seen these kinds of projects, and they seldom work as is. Not sure how well Scala Native works, even though it predates Kotlin’s try. (Though scala.js is surprisingly good!)

But do you really think that a relatively young language like Kotlin with minuscule adoption (compared to java) will be better at this game then Java?

Java has a very good compiler to Js maintained and used heavily by Google (j2cl, part of their closure compiler toolkit), which can also output obj-c code. These are/were used heavily for porting their shared libs between basically all platforms.

For native, Graal is a very cool way forward benefiting all JVM languages (as well as scripting languages, its polyglot features are insane).

> Java is still very slow to evolve

Is it a problem? The majority of developers don’t like running after the language, even though it may seem so based on online hype circles.




>I don’t know how well it works,

Well enough, provided you stay within the known bounds. Hell, some people at Touchlab even went as far as porting Jetpack Compose to work on iOS (which, uh, I would not recommend in its current state), and it technically works. I probably wouldn't recommend writing all of your app logic in Kotlin, but being able to share the data layer is amazing.

>But do you really think that a relatively young language like Kotlin with minuscule adoption (compared to java) will be better at this game then Java?

It depends on where you're looking. Most modern android development will most likely be done in Kotlin. Backend work, for things started relatively recently, Kotlin is not surprising. But mostly, Java does not make iOS compatibility a goal. Java tell you "get a JVM and run our shit" (or get GraalVM and have basically an embedded JVM). Kotlin has two sides, and Kotlin/Native does not depend on the JVM.

>Java has a very good compiler to Js maintained and used heavily by Google (j2cl, part of their closure compiler toolkit), which can also output obj-c code. These are/were used heavily for porting their shared libs between basically all platforms.

j2cl still brings in a light JVM to the Web. Kotlin does not. It provides interop to the JS APIs as well as its own tech, but it's not meant to take your Kotlin code and immediately run it on the web (which is an awful, awful idea). You're still meant to write your browser specific code, your android specific code, your x86 specific code, etc. In any language you want, even! Write it in Kotlin/JS, or let your typescript consume the Kotlin/JS bindings. However, you can have a common base that'll work everywhere.

> For native, Graal is a very cool way forward benefiting all JVM languages (as well as scripting languages, its polyglot features are insane).

Graal is an extremely cool project, but with different goals. Write once, run everywhere is a lofty goal, but it only works on very similar platforms (Windows/Linux/OSX). Kotlin has taken a Write once, specialize what is needed approach.


> even went as far as porting Jetpack Compose to work on iOS

Well, Gluon promises the same for JavaFX apps and there is a sample app actually downloadable from the AppStore.

> j2cl still brings in a light JVM to the Web

Not at all, it compiles to very optimized Javascript. Oh, and I forgot to mention that there is also teavm, which is not a VM contrary to its name -- this latter transforms java byte code so it works with guest languages as well.


  > but being able to share the data layer is amazing.
why not just use swagger/openapi + auto generated models?

adding kotlin native adds huge depenencies relative to the tiny benefit of a datamodel that can be auto generated to native code imo


Swagger + OpenAPI generates data classes for you, and maybe a Retrofit/Ktor/Whatever interface. It does not handle repositories, data fetching, caching and combining, it does not handle a SQLite database.

Which dependencies ? If you already have Android devs, on the iOS side it adds a single swift package, and similarly so on Android.


  > It does not handle repositories, data fetching, caching and combining, it does not handle a SQLite database.
right, but you can use that to autogenerate all those things (have done it before) with a few additional tools (code templates) and have it all (repositories, fetching, caching etc) automated (there is a limit of course, combining might be a bit hard in that case)

this is really useful though because now you can deploy to more platforms in their native languages using idiomatic code, and switching to newer techniques, e.g async/await can be done instantly just by updating the source template which any team can download and compile themselves

  > Which dependencies ? If you already have Android devs, on the iOS side it adds a single swift package, and similarly so on Android.
for ios, its including basically the whole kotlin runtime and additional support (kotlinx-datetime, etc) in that single package (xcframework), then add a lot of data classes and things start to add up... for us its one of the biggest single dependencies on our ios app




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: