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 is it that makes you not having to write so many tests?
Why Kotlin is my next programming language (2015)
11–20 of 185 posts
Re: Why Kotlin is my next programming language (2015)
#12I 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.
There is a slice of the universe where this exists, but it's not really Kotlin's target in the first place (and I think that's basically self-evident from everything around it) so I'm not sure why you'd try to jam that square peg in the round hole to begin with.
Re: Why Kotlin is my next programming language (2015)
#13I 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…
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…
I would suggest (and I'm not trying to bag on you with this) that this concern is more your unfamiliarity with the JVM than a failure of Kotlin, which is generally targeting Java and Scala developers. Kotlin operates pretty idiomatically in the Java universe and, as an experienced JVM developer who's comfortable with all of Maven, Gradle, and SBT, I dropped Kotlin into a Maven project, side-by-side with Java, with a cursory glance at the documentation--"oh, it's another pre-compile-step thing". (Which I then consume via IntelliJ, because IntelliJ imports Maven projects nicely, but Maven allows others to use their IDE of choice.)
The pre-compile-step thing sucks, I'll be the first to say that, and it's a problem with multi-language, multi-compiler projects that none of the major build systems on the JVM really handle admirably. I prefer to use multi-module Maven projects and separate out Java and Kotlin--or Scala, for that matter--code into separate ones. But that's a different beast entirely from the initial bootstrap when learning.
Re: Why Kotlin is my next programming language (2015)
#14I 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.
Under what circumstances are you writing software for deployment in places you don't have administration access on (i.e., your servers, which should be deployed with CM as-is and make adding dependencies trivial) where you cannot package OpenJDK (this is trivial on Windows, OS X, and Linux), cannot expect a system administrator to install the JVM, and can expect Rust to run? There is a slice of the universe where thi…
Is Kotlin not capable of being a client application?
Re: Why Kotlin is my next programming language (2015)
#15I 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.
Most people writing Java will be able to control the presence of the JVM. Only B2C desktop apps, which are fairly rare these days, will have to worry much about the dependency.
Re: Why Kotlin is my next programming language (2015)
#16Earlier 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…
> I couldn't even find how to integrate Kotlin files into a Java project without using IntelliJ. I would suggest (and I'm not trying to bag on you with this) that this concern is more your unfamiliarity with the JVM than a failure of Kotlin, which is generally targeting Java and Scala developers. Kotlin operates pretty idiomatically in the Java universe and, as an experienced JVM developer who's comfortable with all…
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 whenever my Kotlin file changed (presumably they're recompiling more intelligently than I was).
Perhaps having SomeController.java and SomeController.kt in parallel, where the former imports the latter, and receives a `touch` or similar whenever the Kotlin file changes, might work? Or would you recon such a project to be a fool's errand?
Re: Why Kotlin is my next programming language (2015)
#17Earlier quoted context omitted.
Under what circumstances are you writing software for deployment in places you don't have administration access on (i.e., your servers, which should be deployed with CM as-is and make adding dependencies trivial) where you cannot package OpenJDK (this is trivial on Windows, OS X, and Linux), cannot expect a system administrator to install the JVM, and can expect Rust to run? There is a slice of the universe where thi…
I'm thinking of client machines. People balk at installing Java these days. Is there a way to get the JVM without Java? Is Kotlin not capable of being a client application?
Re: Why Kotlin is my next programming language (2015)
#18I 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.
Re: Why Kotlin is my next programming language (2015)
#19Earlier quoted context omitted.
I'm thinking of client machines. People balk at installing Java these days. Is there a way to get the JVM without Java? Is Kotlin not capable of being a client application?
You just package the JVM with the application itself. Create a .bat/.exe/.sh/binary file that calls the JVM with your program as the argument. It's simple, but it will increase the download size of your program significantly (unless your program is huge - then it doesn't matter)
Re: Why Kotlin is my next programming language (2015)
#20I 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…