Hacker News Reader

Comment by pdpi | Hacker News Reader

I've been doing Kotlin on the backend for a while now, and I can't recommend it enough. One of the things that I really enjoy about the language is that it is _not_ a clever language. It's not trying to revolutionise PL theory, it just wants to get out of your way and let you get on with it. This shows up as the language being mostly worried about bringing well-understood modern conveniences into the Java world (interface delegation, property delegation, data classes, generic variance, type inference, etc).

On top of that "modernised Java" base, the language then adds only a small set of clever new features (mostly inline functions and receiver lambdas), and it leverages the hell out of those few features to produce a lot of value — e.g. there is no try-with-resource in Kotlin as a language construct. It's implemented as an inline receiver function that takes a receiver lambda as an argument.

View on HN

When I think about language that gets out of my way for the backend I think Python. I really need to find time to dig deep into a language like kotlin to confirm or dispel my assumption that nothing else comes close to python for getting out of my way and letting me focus on the problem not the code.

Kotlin is very much meant to operate at the same level of abstraction as Java, which is a fair bit lower-level than Python. If you don't need to work at that lower abstraction level, Python will still feel a bit nicer. Kotlin definitely closes some of that gap, though.

Kotlin gives you enough metaprogramming and syntax sugar to feel a rung above Java. You can pack a lot into a short line (list / map literals, compact map / fold / iteration, elvis operator), so it feels to me much closer to Python than Java 8 ever did.

Python gets out of your way as long as your code base is small enough. It's great for experimentation and building quick things. But it strains you a fair bit when your code base becomes large, with many contributors, and a significant amount of components and interfaces between them. You start to grab for static analysis tools.

(I say this having worked with Python for 20 years, and loving the language.)

If you're working in a small enough team (or solo) or a young codebase I think you won't see a ton a lot of value a basic type system can bring. I say this with experience with both Java and Python but not Kotlin.

Reading old undocumented code and refactoring it confidently is wildly easier with Java than Python. The structure provides obvious moves and shifts and reason about code you haven't fully read yet. Even with relatively clean Python (i.e. No messing with scopes or abusing dicts as params or monkey patching) you can still end up with difficult knots. One of the most frustrating examples is that even typos can remain uncaught without near 100% code coverage. I find these occur readily not when I'm writing code but when refactoring.

An Android dev told me, it is between JS and Java, some low-level stuff is harder, but most day-to-day tasks are really simple and you can always fall back to Java if you like.

Sounds nice.

Huh. I'd be interested to hear what low-level stuff they thought was harder than in Java. Can't think of anything you can do in Java that can't be done at the same abstraction level in Kotlin.

My guesses would be handling unsigned hex https://youtrack.jetbrains.com/issue/KT-4749

And bitwise operations https://discuss.kotlinlang.org/t/when-does-bit-fiddling-come...

And maybe handling generics. I haven't had any issues, but kotlin is a bit stricter which is generally a good thing, but I'd believe that for some edge case it makes things harder.

Yes, the bitwise operator stuff.

Reply on news.ycombinator.com