Live data from Hacker News

Kotlin Compiler Crash Course

github.com

21–30 of 51 posts

Re: Kotlin Compiler Crash Course

#21

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…

Try Clojure after which there's definitely no going back.

Re: Kotlin Compiler Crash Course

#22
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.

Yeah, right, so why do I still have to escape regex metacharacters in Java in 2021? That's just so 1988.

Re: Kotlin Compiler Crash Course

#23
post #3

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…

Why do you feel like that about Coffeescript?

The thing about Coffeescript is that you don't really gain anything other than syntactic sugar. Compare it to, say, Typescript and Clojurescript where you gain a whole set of features and, with Clojurescript, the semblance of a standard library.

Re: Kotlin Compiler Crash Course

#24
post #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 mo…

Interesting! However I wonder if building Java plugins is harder. For example: JPA entities have for requirement to have a no-arg constructor. Both Java records and Kotlin data classes have not such a constructor by default. However kotlin has a no arg compiler plugin that autogenerate it for data classes (without any annotation) and Java Records don't have anything similar yet to my knowledge. (however they would still remain incompatible with jpa anyway because unfortunately they are immutable)

Re: Kotlin Compiler Crash Course

#25
post #14

Earlier quoted context omitted.

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.

The whole point of OOP is that each object is responsible for maintaining its own invariants. Open classes are useless without open methods, and open methods are a weak point in terms of letting your child classes mess up those invariants.

Interfaces are completely free of this burden. Abstract classes signal that you're working with an incomplete implementation and you're expected to cooperate with the base case to make things work. Final classes just opt out of this whole thing altogether.

What, exactly, does a class being open say? In a default-open context, you don't know whether this is an omission or a design choice. In a default-final context, you're explicitly allowed to mess with the class (and, because of the explicitly open methods, only in safe ways).

Re: Kotlin Compiler Crash Course

#26
post #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 mo…

Manifold is very interesting. There is also a tail call recursion optimizer at the bytecode level https://github.com/Sipkab/jvm-tail-recursion

It would be nice to have a list of such extensions of the language/bytecode

Re: Kotlin Compiler Crash Course

#28
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.

I'm not sure how well "less tools" holds up when Jetbrains has done an awesome job of supporting Kotlin in their Java IDEs. There's something to be said for a dev tool shop developing a language.

Re: Kotlin Compiler Crash Course

#29
post #21

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…

Try Clojure after which there's definitely no going back.

Completely different motivations, and I suspect Kotlin is a reason that Clojure and Scala seem to be losing much of their initial steam. Clojure offers Lisp on the JVM, but what most people really wanted was a fixed Java. That's exactly what Kotlin delivers. Clojure has decent Java interop, but there's a serious impedance mismatch working with native Clojure and Java libs. Kotlin otoh dogmatically sticks to Java's model of programming, just a cleaned up version.
Post reply on HN