Wow, so much negativity here O.o Kotlin is getting rapid adoption in the Android community and is quickly getting the same status as Swift has in the iOS world. The main reasons for the rapid adoption are: - It's designed to easily integrate into existing Java codebases. This means that starting to use Kotlin is pretty much a case of adding two Gradle dependencies and source files into `src/kotlin`. Interop with Java…
Why Kotlin is my next programming language (2015)
121–130 of 185 posts
Re: Why Kotlin is my next programming language (2015)
#122Wow, so much negativity here O.o Kotlin is getting rapid adoption in the Android community and is quickly getting the same status as Swift has in the iOS world. The main reasons for the rapid adoption are: - It's designed to easily integrate into existing Java codebases. This means that starting to use Kotlin is pretty much a case of adding two Gradle dependencies and source files into `src/kotlin`. Interop with Java…
You seem to know a few bits about Kotlin. I'm not well versed in Java land but why target Java 6 that's been unsupported for the last 3 years? Isn't that a problem?
Re: Why Kotlin is my next programming language (2015)
#123Earlier quoted context omitted.
Have a look at Scala Native. Despite its young age it creates really fast, tight code (they have issues benchmarking things because Dotty Linker + LLVM gets rid of too much stuff).
Thanks. It is too early to say if it would be of any use, however, since they don't talk about freeing these native data structures.
Re: Why Kotlin is my next programming language (2015)
#124Earlier 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.
Re: Why Kotlin is my next programming language (2015)
#125Earlier quoted context omitted.
You seem to know a few bits about Kotlin. I'm not well versed in Java land but why target Java 6 that's been unsupported for the last 3 years? Isn't that a problem?
Because the VM on Android devices runs only Java 6 compatible bytecode.
EDIT: On the other hand Java 6 byte code might run just fine under I.E JRE 8?
Re: Why Kotlin is my next programming language (2015)
#126Re: Why Kotlin is my next programming language (2015)
#127Earlier quoted context omitted.
I think that might be what's needed for a really good programming language. If you want a general-purpose language, you probably don't want something unique and envelope-pushing - you just want a language that avoids all the mistakes that are so common, that learns from what's gone before. Like buying a table - you usually don't want a radical table that can do something other tables can't, you just want a good solid…
Could you explain why Ceylon fits the bill while Kotlin does not please ?
* Ceylon has actually listened to the lessons of Scala tuples and built theirs the way ours should have been all along (HLists), making them much easier to abstract over. (NB not actually an issue in Scala in practice - you import Shapeless and then everything works the way it should - but it's nicer to have the right thing by default, as will hopefully be the case in Scala 3.x)
* Ceylon has higher-kinded type support done right - multiple parameter lists to avoid Scala's unification issues that lead to the use of "type lambdas" (hopefully fixed in Scala 2.12).
Kotlin simply doesn't support higher-kinded types; combined with the lack of union types this means magical annotations with bytecode manipulation where suddenly the code you wrote isn't the code that runs, because just like Java that's the only way to do a lot of things in Kotlin. Async is a special case with language-level dedicated support code. Error handling is done solely through unchecked exceptions which is fine for system failures but not a good way to handle "expected" failures like input validation.
Re: Why Kotlin is my next programming language (2015)
#128I tried Kotlin during the Surprise Language round of Codeforces, a programming competition. I found it to be more verbose than a typical modern scripting language. Maybe it's the result of choosing the least of the evils for what it's trying to accomplish. The other drawback: the documentation. Kotlin's reference documentation (looking up how to properly use a call) does not have any examples. I'm not even talking ab…
https://discuss.kotlinlang.org/t/examples-in-the-api-docs/16...
Re: Why Kotlin is my next programming language (2015)
#129Earlier quoted context omitted.
I think that might be what's needed for a really good programming language. If you want a general-purpose language, you probably don't want something unique and envelope-pushing - you just want a language that avoids all the mistakes that are so common, that learns from what's gone before. Like buying a table - you usually don't want a radical table that can do something other tables can't, you just want a good solid…
It is interesting that when I considered next language to write a side-project in, I was choosing between Ceylon and Kotlin. In the end I did choose Kotlin. My reasons included: * support in IDEA * focus on java interoperability * nice interop with android but the main thing probably was, that I trust JetBrains that they will support Kotlin in the long term, while I don't think RedHat has any projects depending on th…
Re: Why Kotlin is my next programming language (2015)
#130Earlier quoted context omitted.
I initially used Kotlin for a project at work, and I would agree that it is underwhelming. Pivotal had announced official support for Kotlin with Spring Boot, which is what motivated me to give it a try. However, there was no support for the @Transactional annotation in Kotlin at the time, so I ended up writing a decent amount of Java anyways. Then there was a compatibility issue with one of our internal libraries, a…
As of 1.0 Kotlin has solid Java compatibility, @Transactional definitely shouldn't be an issue. What features are compelling for you in 1.1? They are nice, but generally just a nice sugar. I don't really miss any of those. I suggest you to try it now, if you have a chance.