Live data from Hacker News

Why Kotlin is my next programming language (2015)

medium.com

31–40 of 185 posts

Re: Why Kotlin is my next programming language (2015)

#31
I see the biggest market for Kotlin being Android. It manages to provide features that Java will likely never have while still having a fairly small impact on run time, deploy, and APK size. The conversion tool is really great too. It makes it much easier to migrate a project to kotlin, especially when trying to figure out more complex stuff like annotations. I see Kotlin being Android's Swift in the future.

Re: Why Kotlin is my next programming language (2015)

#32
> Kotlin comes from industry, not academia. It solves problems faced by working programmers today. As an example, the type system helps you avoid null pointer exceptions.

I'm sorry but you just undercut your own anti-intellectualism better than I could right there.

(There exist languages which have guarded against this without loss of expressive power since before Java and, oh, are from academia.)

Re: Why Kotlin is my next programming language (2015)

#33

Are there any decent languages that compile to readable Java? I think such a language would have a place in conservative Java shops, where management insists "we only use plain old Java around here". You could program in a "cleaner Java" translate it to vanilla Java, then commit, and nobody would know the difference.

Xtend from the eclipse foundation does just that - it compiles to plain java, not bytecode.

http://www.eclipse.org/xtend/

Kotlin follows a very similar path as it does, but to greater success. I played with xtend a few years ago and now I use kotlin for my jvm tasks.

Re: Why Kotlin is my next programming language (2015)

#34
post #5

Earlier quoted context omitted.

Personally I don't much mind the added verbosity, coming from Ruby/Python/JS, so long as I don't have to write so many damn tests. Speaking from minimal experience, Kotlin still seems like a big net win here. Same is true of other languages with lightweight, static type systems like TypeScript/Flow, Swift, and Go. I agree about the documentation – I think it's one of the biggest reasons the language has seen such lit…

What sort of tests don't you end up writing? I ask because I work in both dynamic and static languages, and find myself writing very similiar tests in each case.

Tests that verify the behavior of functions when they are passed data of a type that does not support the behavior that the function expects to be supported. I find this to be a very common case.

Re: Why Kotlin is my next programming language (2015)

#35
>Kotlin costs nothing to adopt! It’s open source, but that’s not what I mean here. What I mean is there’s a high quality, one-click Java to Kotlin converter tool, and a strong focus on Java binary compatibility.

The costs of adopting a new language are greatly more significant than implied here. The time it takes to learn it. The time it turns to learn the tools that are specific to it. And if you put it into production, the technical debt you've created by adding another language to the codebase, etc.

If the OP had said that you don't have to start a green-field project to use it, that would be more accurate.

Re: Why Kotlin is my next programming language (2015)

#36

Earlier quoted context omitted.

What sort of tests don't you end up writing? I ask because I work in both dynamic and static languages, and find myself writing very similiar tests in each case.

Tests that verify the behavior of functions when they are passed data of a type that does not support the behavior that the function expects to be supported. I find this to be a very common case.

I address this problem by checking the type at run-time via an assertion.

Depending on where you are in the security vs efficiency spectrum, you may opt to ignore those assertions in production.

Writing specific tests for that looks very inefficient to me but maybe I am missing something.

Re: Why Kotlin is my next programming language (2015)

#37
post #21
post #16

Earlier quoted context omitted.

> your unfamiliarity with the JVM Correct! > a problem with multi-language, multi-compiler projects that none of the major build systems on the JVM really handle admirably A bummer to hear – though I'm glad it's not just me. I tried using Kotlin with the Play Framework and did not have a great time. The hot-reloading features of Play didn't work with Kotlin at all, even with my attempts to `touch` a Java file wheneve…

Play isn't built for Kotlin and SBT is kind of a tire fire in general. I would suggest something more like Dropwizard for use with non-Scala JVM languages.

Or Spring Boot, which is fantastic.

Re: Why Kotlin is my next programming language (2015)

#38
post #4

I really liked Scala when I played around with it (bare with me here), but when deciding on what to use on a project I'm starting, targeting the JVM is a downside. Can I depend on the JVM being on the target machine? If not, I'll have to deal with the dependency. However, if I choose a compiled language like Rust, I don't have to worry about that.

Wow!I don't like the JVM and I'm a rust fan... But you've touched a nerve here, this is my biggest disappointment with rust. The JVM runs on A LOT more platforms than LLVM currently supports!
Post reply on HN