4 ms·
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 _
by pdpi 8y ago
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.
- deleted 8y ago[deleted]
- k__ 8y agoAn 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.
- pdpi 8y agoHuh. 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.
- kevinslashslash 8y agoMy guesses would be handling unsigned hex https://youtrack.jetbrains.com/issue/KT-4749 https://youtrack.jetbrains.com/issue/KT-4749 And bitwise operations https://discuss.kotlinlang.org/t/when-does-bit-fiddling-come-to-kotlin/2249 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.
- k__ 8y agoYes, the bitwise operator stuff.
- Waterluvian 8y agoWhen 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.
- pdpi 8y agoKotlin 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.
- nine_k 8y agoKotlin 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.
- nine_k 8y agoPython 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.)
- kjeetgill 8y agoIf 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.