Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Hitchhiker's Guide to Kotlin

nathan-contino.github.io

Post reply on HN
Print view View original

21–30 of 34 posts

Re: The Hitchhiker's Guide to Kotlin

#21

Post by pjmlp »

Ologn wrote: post #20
pjmlp wrote: post #6

Earlier quoted context omitted.

On Android, it is kind of clear, Google is doubling down on Kotlin and the team is hardly motivated to move Android Java into proper Java, so long term Kotlin seems to be the only path forward. Still cherry picking features from Java 11 when Java 17 just got released, https://android-review.googlesource.com/q/project:platform%2...

I agree. Two years ago a slide at a Google I/O talk said "Coroutines first", and coroutine scopes like lifecycleScope are Kotlin only. Jetpack Compose is the future of Android UI and is Kotlin only. Insofar as bringing it into the app - from most apps I know of, new code is usually written in Kotlin, and the Java code becomes legacy (which is sometimes rewritten in Kotlin). It works well enough, compatibility with ex…

The problem with that strategy is that as the JVM gets Loom, SIMD, JNI replaced by Panama, bytecodes that don't translate to DEX,... the amount of Java libraries available to Android developers diminishes.

So doing Kotlin in Android, with an anti-Java agenda, reduces Kotlin to use pure Android libraries, or pre-history Java ones that can still be called from Android Java.

Re: The Hitchhiker's Guide to Kotlin

#22

Post by travisgriggs »

I do a bit of Kotlin on Android. Two decent sized native apps. We do no Java, but use some Java libraries.

I like Kotlin enough. But I don’t love it. Like Swift (and maybe Python yet), it’s a language that tacks on more stuff every release in interest of grabbing yet another programming model niche. It’s like a Swiss Army knife with a _lot_ of blades and gadgets and tools. It’s like a VC funded start up that throws features at the wall to see what sticks and placates.

I want my languages to be built on simple unifying principles. Kotlin’s principles often seem to be:

- we get rid of boilerplate . . . when ever we can, but not really consistently. Removing boiler plate trumps consistency in code communication

- you have a rising idea over there in your ecosystem? we will add it in ours

- by keeping our documentation very simple (nee spartan), we can claim our language is simple

This year it is coroutines, tomorrow it will be sealed classes, or who knows.

Re: The Hitchhiker's Guide to Kotlin

#23

Post by scns »

jamesfinlayson wrote: post #15
smackeyacky wrote: post #3

Has anybody switched to mixing in Kotlin code within an existing Java Android app? I'm not a huge fan of Java but I don't know whether it will be too jarring for maintenance tasks if I have both languages as code. There is a lot of XML floating around in my app (as most Android apps have) but switching between editing that and the Java is fine. I'm keen on the idea that there would be less code and my app is getting…

Not personally but it's happening in a few apps at my current company. In my job I mix Java and Groovy and at home I've mixed Java and Kotlin and it mostly just works (I don't think you can inherit Java -> other language -> Java because things get compiled in order but that has only been an issue for me once).

You can do Java -> Kotlin just fine.

Re: The Hitchhiker's Guide to Kotlin

#24

Post by bestinterest »

ParanoidShroom wrote: post #12
nassimsoftware wrote: post #2

Kotlin is a really nice language. I wish it was used more especially that now it isn't just limited to the Android and Java ecosystems. Kotlin can now compile to native binaries : https://kotlinlang.org/docs/native-overview.html#sharing-cod... Kotlin can now compile to Javascript : https://kotlinlang.org/docs/js-overview.html Edit : You can even use React with Kotlin : https://kotlinlang.org/docs/js-get-started.html…

I do kotlin daily, almost exclusively including side projects. Kotlin native has been rocky personally, I'll check back in a year. Kotlin on Android is a must compared to Java, else you're a fool. Haven't seen any exceptions in the industry. Kotless is okay, works, but early days. I've seen decent backends on quarkus and kotlin. It's a fun language, the couroutine development is pretty nice. Flow is a lot easier than…

Coroutine stuff worries me in Kotlin, what happens the minute Project Loom comes out? Even more fracturing of styles?

Re: The Hitchhiker's Guide to Kotlin

#25

Post by pjmlp »

smallerfish wrote: post #13
pjmlp wrote: post #7

Earlier quoted context omitted.

Ecosystem, tooling, libraries.

It's actually very good - debugging from the IDE now even works. I'd recommend building around KVision rather than raw KotlinJs ( https://kvision.gitbook.io/kvision-guide/ ). The main thing that can be annoying is figuring out module exports from a js library that you want to use (which is probably easy enough if you have a modern javascript background). I haven't found a library that's stumped me yet, but some are m…

Except the platform is JavaScript, and TypeScript is basically Web IDL aware compiler on steroids, no need to use anything that adds even more layers.

Re: The Hitchhiker's Guide to Kotlin

#26

Post by smallerfish »

pjmlp wrote: post #25
smallerfish wrote: post #13

Earlier quoted context omitted.

It's actually very good - debugging from the IDE now even works. I'd recommend building around KVision rather than raw KotlinJs ( https://kvision.gitbook.io/kvision-guide/ ). The main thing that can be annoying is figuring out module exports from a js library that you want to use (which is probably easy enough if you have a modern javascript background). I haven't found a library that's stumped me yet, but some are m…

Except the platform is JavaScript, and TypeScript is basically Web IDL aware compiler on steroids, no need to use anything that adds even more layers.

That depends. If the rest of your application is in Kotlin, you're reducing cognitive overhead. Same language, same compile, same distribution. You can share view models between frontend and backend. It's much closer to what GWT promised to be than GWT ever was.

Re: The Hitchhiker's Guide to Kotlin

#27

Post by BoxOfRain »

nassimsoftware wrote: post #2

Kotlin is a really nice language. I wish it was used more especially that now it isn't just limited to the Android and Java ecosystems. Kotlin can now compile to native binaries : https://kotlinlang.org/docs/native-overview.html#sharing-cod... Kotlin can now compile to Javascript : https://kotlinlang.org/docs/js-overview.html Edit : You can even use React with Kotlin : https://kotlinlang.org/docs/js-get-started.html…

I absolutely love Kotlin for backend web dev, I started using it as "Java but without the things in Java that piss me off" but the more I used its non-Java features the more I grew to love it. Sadly I've moved jobs so I'm not using it professionally any more but it powers my side project so I'm keeping my skills fresh.

I'd recommend it to anyone where they'd traditionally use Java or another similar language.

Re: The Hitchhiker's Guide to Kotlin

#28

Post by pjmlp »

smallerfish wrote: post #26
pjmlp wrote: post #25

Earlier quoted context omitted.

Except the platform is JavaScript, and TypeScript is basically Web IDL aware compiler on steroids, no need to use anything that adds even more layers.

That depends. If the rest of your application is in Kotlin, you're reducing cognitive overhead. Same language, same compile, same distribution. You can share view models between frontend and backend. It's much closer to what GWT promised to be than GWT ever was.

Guest languages are always an impedance mismatch with the underlying platform.

I don't buy into sharing source files instead of clean separation via Web APIs, the additional tooling complexity isn't worth the pain.

I did vote against stuff like GWT already several times, and every time it has been proven to have been the right decision, when things went hot.

Re: The Hitchhiker's Guide to Kotlin

#29

Post by smallerfish »

pjmlp wrote: post #28
smallerfish wrote: post #26

Earlier quoted context omitted.

That depends. If the rest of your application is in Kotlin, you're reducing cognitive overhead. Same language, same compile, same distribution. You can share view models between frontend and backend. It's much closer to what GWT promised to be than GWT ever was.

Guest languages are always an impedance mismatch with the underlying platform. I don't buy into sharing source files instead of clean separation via Web APIs, the additional tooling complexity isn't worth the pain. I did vote against stuff like GWT already several times, and every time it has been proven to have been the right decision, when things went hot.

> I don't buy into sharing source files instead of clean separation via Web APIs, the additional tooling complexity isn't worth the pain.

Fair enough, that's a different argument from the one you posed upthread though. The ecosystem and tooling are very much there.

Happy to disagree on architectural merit of the approach. Personally I'm done with javascript/typescript for any future products/teams I build, and am glad to have a viable solution.

Re: The Hitchhiker's Guide to Kotlin

#30

Post by bberrry »

dehrmann wrote: post #19

I tried Kotlin, but I went back to Java. Interacting with Java libraries can be OK, but it can also get ugly. Using companion classes for loggers seems overkill. I didn't like having to explicitly cast ints to longs. I ended up going back because Java's getting better--var and records help with some of the pain--the tooling is simpler and more reliable, and working with something like Hadoop was significantly harder.

Why would you use companion objects for loggers? The logging library should only create one instance when you do getLogger({name or class}).
Post reply on HN