Live data from Hacker News

Kotlin Compiler Crash Course

github.com

11–20 of 51 posts

Re: Kotlin Compiler Crash Course

#11

Kotlin is one of those things that I avoided learning for so long just because I didn't want to learn another new thing. And one day I had to work on a project that was 100% kotlin and so i decided to do a 3 hour crash course on Youtube (actually watched it at 3x speed so it was really 1 hour) and once I grasped the basics it really made so much sense and I don't think I'm ever going back to writing Java classes anym…

From my modest experience with Kotlin few months ago in a small Android project for learning purposes. I can just say that the language resulted very expressive, concise and easy to use for me. Coming from other languages (Go, Rust, C#, JS, PHP among others) but doing almost no Java in the past, I was able to getting started with that Android project few weeks later after have been passed across Kotlin's docs https://kotlinlang.org/docs/home.html

So basically I can confirm "Android’s Kotlin-first approach" https://developer.android.com/kotlin/first

Re: Kotlin Compiler Crash Course

#12
post #6

Kotlin is one of those things that I avoided learning for so long just because I didn't want to learn another new thing. And one day I had to work on a project that was 100% kotlin and so i decided to do a 3 hour crash course on Youtube (actually watched it at 3x speed so it was really 1 hour) and once I grasped the basics it really made so much sense and I don't think I'm ever going back to writing Java classes anym…

Java developers are rightfully conservative and sceptical of "new things". That said I believe Kotlin really provides a strong value proposition over Java. You also don't sacrifice much, there is less tools ofc but enough to get by, performance is equal for the most part etc. Also unlike stuff like CS it has a very strong future with Android backing.

Oracle does a really good job improving the Java language. I really don't see any reason for why I should start using Kotlin. I use Groovy when I just need to do something fast without all the boilerplate code. But for 95% of the business problems, plain old Java is exactly what I need. For anything else, its Rust, Python, Javascript that shines in each of their category.

Re: Kotlin Compiler Crash Course

#13
I recently moved to a new team after using Kotlin for a few years (serverside) and transition back to Java is realy annoying, so much boiler plate and rituals and needless code.

Instead of concentrating on solving problems it feels like my job now is to do the elaborate java dance. Alot of muttering and cringing from me.

I think Jetbrains should have called Kotlin Java++ instead (yes i know theres alot more to Kotlin than JVM) as it would have made it an easier sell in enterprise world to management who dont realise how much overlap and interop with Java there is when using Kotlin, nor the possible productivity gains from not having to create as much code, having better type system and nullability/immutability features and about dozen other features which make Kotlin such a nice language to work in day to day.

Anyways yeh, hopefully can steer team back to Kotlin, they should like it, just like previous team came to love it.

Re: Kotlin Compiler Crash Course

#14
post #12
post #6

Earlier quoted context omitted.

Java developers are rightfully conservative and sceptical of "new things". That said I believe Kotlin really provides a strong value proposition over Java. You also don't sacrifice much, there is less tools ofc but enough to get by, performance is equal for the most part etc. Also unlike stuff like CS it has a very strong future with Android backing.

Oracle does a really good job improving the Java language. I really don't see any reason for why I should start using Kotlin. I use Groovy when I just need to do something fast without all the boilerplate code. But for 95% of the business problems, plain old Java is exactly what I need. For anything else, its Rust, Python, Javascript that shines in each of their category.

Oracle is doing a good job adding features to Java to keep up with modern languages, but it’s not just about adding — some things need to be removed or changed.

By way of example:

Final classes by default with an open keyword instead of open by default with a final keyword. Inheritance is a very tricky thing to get right and it’s better to explicitly say “I thought about this and put in the effort to make it work”.

Checked exceptions are a contentious topic and I’m not sure which choice I prefer, but Kotlin chose to remove that, and it has an impact on style.

Re: Kotlin Compiler Crash Course

#15
Kotlin has this amazing concept called compiler plugins where you can extend, intercept and alter the compiler at any stage of the compilation pipeline (ast, psi, ir) through an API.

There even are frameworks that make writing such plugins easier such as https://github.com/arrow-kt/arrow-meta (which enable to bring union type, higher kinded types, pattern matching, etc) Or https://github.com/google/ksp

Re: Kotlin Compiler Crash Course

#16
post #14
post #12

Earlier quoted context omitted.

Oracle does a really good job improving the Java language. I really don't see any reason for why I should start using Kotlin. I use Groovy when I just need to do something fast without all the boilerplate code. But for 95% of the business problems, plain old Java is exactly what I need. For anything else, its Rust, Python, Javascript that shines in each of their category.

Oracle is doing a good job adding features to Java to keep up with modern languages, but it’s not just about adding — some things need to be removed or changed. By way of example: Final classes by default with an open keyword instead of open by default with a final keyword. Inheritance is a very tricky thing to get right and it’s better to explicitly say “I thought about this and put in the effort to make it work”. C…

> Final classes by default with an open keyword

...is exactly the wrong way around. Inheritance is very much about unplanned reuse and programming by difference. That is: there is something that almost works the way you want, but not quite.

If you are actually planning this ahead, then typically inheritance is the wrong approach and you're better off using composition.

Re: Kotlin Compiler Crash Course

#17

Kotlin has this amazing concept called compiler plugins where you can extend, intercept and alter the compiler at any stage of the compilation pipeline (ast, psi, ir) through an API. There even are frameworks that make writing such plugins easier such as https://github.com/arrow-kt/arrow-meta (which enable to bring union type, higher kinded types, pattern matching, etc) Or https://github.com/google/ksp

While this is cool, it doesn't look like something very different from other existing JVM compiler plugins... it seems quite similar to Javac plugins[0] and perhaps somewhere in between that and Groovy AST transformers[1].

Manifold[2] is basically a javac plugin if I'm not mistaken, and it shows just how powerful stuff can be accomplished with this approach (including e.g. auto-generation of Java types from common modelling languages like GraphQL, JSON, YAML etc. adds extension methods, unit expressions, ranges, C++-like preprocessors, structural subtyping, even crazy stuff like type-safe reflection - like Ceylon used to have!).

For Groovy, besides the built-in AST annotations like `@Immutable` and `@Canonical` (which turns a class into a data class, basically), you can achieve stuff like the Spock Testing Framework[3] which changes the Groovy syntax a little bit to make it really awesome for testing.

[0] https://www.baeldung.com/java-build-compiler-plugin

[1] https://groovy-lang.org/metaprogramming.html

[2] http://manifold.systems/

[3] https://spockframework.org/spock/docs/1.0/spock_primer.html

Re: Kotlin Compiler Crash Course

#18
post #12
post #6

Earlier quoted context omitted.

Java developers are rightfully conservative and sceptical of "new things". That said I believe Kotlin really provides a strong value proposition over Java. You also don't sacrifice much, there is less tools ofc but enough to get by, performance is equal for the most part etc. Also unlike stuff like CS it has a very strong future with Android backing.

Oracle does a really good job improving the Java language. I really don't see any reason for why I should start using Kotlin. I use Groovy when I just need to do something fast without all the boilerplate code. But for 95% of the business problems, plain old Java is exactly what I need. For anything else, its Rust, Python, Javascript that shines in each of their category.

Wow, I am pretty much exactly of the same view (except for using Python, I really don't like Python, been burned too much by its constant problems with using system libs that only ever seem to work on "my machine" - Groovy is a lot more reliable for scripts IMO)... but I do use Kotlin sometimes, but with Java 17 likely bringing sealed classes/interfaces to Java, I am less and less excited about using Kotlin.

Re: Kotlin Compiler Crash Course

#19
post #18
post #12

Earlier quoted context omitted.

Oracle does a really good job improving the Java language. I really don't see any reason for why I should start using Kotlin. I use Groovy when I just need to do something fast without all the boilerplate code. But for 95% of the business problems, plain old Java is exactly what I need. For anything else, its Rust, Python, Javascript that shines in each of their category.

Wow, I am pretty much exactly of the same view (except for using Python, I really don't like Python, been burned too much by its constant problems with using system libs that only ever seem to work on "my machine" - Groovy is a lot more reliable for scripts IMO)... but I do use Kotlin sometimes, but with Java 17 likely bringing sealed classes/interfaces to Java, I am less and less excited about using Kotlin.

Yeah, for me, Java 16 bringing record classes (data classes/case classes etc.) to the table is making Kotlin less compelling.

Simply because using Kotlin brings in more moving parts. For example: https://docs.micronaut.io/latest/guide/index.html#kotlin

> When you use any Micronaut AOP Advice, it creates a subclass at compile-time to provide the AOP behaviour. This can be a problem because Kotlin classes are final by default. If the application was created with the Micronaut CLI, the Kotlin all-open plugin is configured for you to automatically change your classes to open when an AOP annotation is used. To configure it yourself, add the Around class to the list of supported annotations.

Re: Kotlin Compiler Crash Course

#20
post #12
post #6

Earlier quoted context omitted.

Java developers are rightfully conservative and sceptical of "new things". That said I believe Kotlin really provides a strong value proposition over Java. You also don't sacrifice much, there is less tools ofc but enough to get by, performance is equal for the most part etc. Also unlike stuff like CS it has a very strong future with Android backing.

Oracle does a really good job improving the Java language. I really don't see any reason for why I should start using Kotlin. I use Groovy when I just need to do something fast without all the boilerplate code. But for 95% of the business problems, plain old Java is exactly what I need. For anything else, its Rust, Python, Javascript that shines in each of their category.

I felt the exact same way until last year. Java 8+, IntelliJ IDEA, and Lombok combined massively reduced boilerplate.

Groovy was great for “more than Bash” and DSLs.

I was wrong. Last year we gave Kotlin a try as a team and at this point we’re 100% Kotlin where we would’ve been using Java or Groovy (which would be the vast majority of our code).

Spring and IDE support has made this transition easy. Coroutines are great for the type of code we write, SAM advances in Kotlin 1.4x have removed the last couple “I like the way Java handles that better”. Best off, all of those libraries we already created and use are still completely usable, we didn’t have to rewrite anything.

For me nullability checks by default, synthetic/map backed properties, extension functions, inline/reified functions, and coroutines have so drastically improved the readability AND conciseness of our code I can’t imagine going back.

Post reply on HN