Live data from Hacker News

Ask HN: Has anyone here programmed in Kotlin? What do you think about it?

news.ycombinator.com

161–170 of 203 posts

Re: Ask HN: Has anyone here programmed in Kotlin? What do you think about it?

#161

I have used it for a small amount of production code in a mixed Java / Groovy codebase coded using Intellij and Kotlin version 0.11. Kotlin worked well - clear concise code, no null worries and no cast worries. It is peculiarly refreshing to know that my code won't even compile if I try to call a method on null and that Intellij will underline the code in red and suggest a fix. At the time I was using it I would say…

> I have used it for a small amount of production code in a mixed Java / Groovy codebase

Hope first priority was to replace the Groovy rather than the Java.

Re: Ask HN: Has anyone here programmed in Kotlin? What do you think about it?

#162

Earlier quoted context omitted.

> What Kotlin still misses is somehow a good testing ability, to test it via Java Test Suites seems strange. Why? > I mean Maven really sucks Why? > Also these days a language needs Dependency Injection There's plenty of JVM libraries that provide it. Why does a language need to provide it?

> I mean Maven really sucks Why? I think after a while one gets tired of using XML as a configuration language. It's verbose and not the easiest to read. Beyond that, we used to find ourselves in dependency hell with maven pretty frequently, though that hasn't happened to me in a few years. The biggest problem, imho, is that it's inflexible. You can't just (easily) throw in a bit of functionality or make an unusual t…

> Beyond that, we used to find ourselves in dependency hell with maven pretty frequently

You'll hit that with Gradle, Ivy, Leiningen, SBT and Buildr too.

> The biggest problem, imho, is that it's inflexible. You can't just (easily) throw in a bit of functionality or make an unusual tweak to your build. So, if you can't find an existing plugin to do what you need, you have to write it yourself.

I'd also call that it's biggest strength. Maven POMs are only ever declarative. I've never hit a FOSS project using Maven that I couldn't build, but I've hit plenty using SBT or Ant that I had to tweak to build.

> I've written a maven plugin, and the documentation/support was rather poor.

I had the same experience with Gradle's DSL documentation, although having a look at it now, they've dramatically improved it since then.

Re: Ask HN: Has anyone here programmed in Kotlin? What do you think about it?

#163
post #79

Earlier quoted context omitted.

> What Kotlin still misses is somehow a good testing ability, to test it via Java Test Suites seems strange. Why? > I mean Maven really sucks Why? > Also these days a language needs Dependency Injection There's plenty of JVM libraries that provide it. Why does a language need to provide it?

Currently it sucks to write tests with JUnit while using Kotlin, there is Spek (Jetbrains made it(, but it's early (too early). XML based Build Tool, I mean seriously? It should at least be somehow human readable. A language should need a sane integration of it, not the library itself. Okai DI is definitly somewhat that isn't needed, but a good integration is still suitable. I mean good Multithreading lives in RxKotl…

> Currently it sucks to write tests with JUnit while using Kotlin

Why?

> XML based Build Tool, I mean seriously? It should at least be somehow human readable.

It's entirely human readable in my subjective opinion. At the very least, it's as human readable as HTML...

> A language should need a sane integration of it, not the library itself.

Any language which has constructors already has the best DI integration available.

Re: Ask HN: Has anyone here programmed in Kotlin? What do you think about it?

#164

I've been using Kotlin on-and-off as a Java replacement and I've really enjoyed it. A couple of months ago I used Kotlin to setup a Dropwizard project and it was a breeze so I put together an example on GitHub to serve as a starting point for others: https://github.com/doomspork/kotlin-dropwizard

Need more projects like this! Thank you!

You're welcome!

Re: Ask HN: Has anyone here programmed in Kotlin? What do you think about it?

#165
post #79

Earlier quoted context omitted.

> What Kotlin still misses is somehow a good testing ability, to test it via Java Test Suites seems strange. Why? > I mean Maven really sucks Why? > Also these days a language needs Dependency Injection There's plenty of JVM libraries that provide it. Why does a language need to provide it?

Currently it sucks to write tests with JUnit while using Kotlin, there is Spek (Jetbrains made it(, but it's early (too early). XML based Build Tool, I mean seriously? It should at least be somehow human readable. A language should need a sane integration of it, not the library itself. Okai DI is definitly somewhat that isn't needed, but a good integration is still suitable. I mean good Multithreading lives in RxKotl…

There is Quasar if you want Go or Erlang style concurrency in either Java or Kotlin (and the Pulsar wrapper to it for Clojure).

No reason to bake it into the language -- and as you can see from comparing the Java and Kotlin sample code, there is a reason for a language that let you write Groovy-like DSLs.

http://docs.paralleluniverse.co/quasar/

Re: Ask HN: Has anyone here programmed in Kotlin? What do you think about it?

#166
post #135

Earlier quoted context omitted.

FYI, I had taken "every opportunity to danger-danger-dragons-be-there" Scala — on record — years before I even dreamed of the database company that would one day have an open-source project which would end up competing with Akka (I'm talking 2009/10, while Quasar was first conceived in mid 2013). It was after leading an attempt to adopt Scala at a large organization, which failed because of what I saw as Scala's bait…

Interesting analogy, incredible how Spark drives the Scala helicopter like a car; they seem to have nailed parallel parking ;-) Seriously though, I doubt Kotlin would ever be the first choice for a project like Spark since Scala excels in the DSL department (really without rival on the JVM, and off, only Haskell comes close). Look through Spark source code [1] and you'll see: operator overloading, (sealed) ADTs, exha…

1. None of those features (except sealed ADTs, which really aren't necessary) is missing from Kotlin. The set of Scala features Spark is using is pretty much identical to Kotlin.

2. I don't see how IBM's investment has anything to do with Scala, though. Spark is a great product, and deserves an investment even if it were written in BASIC.

3. Even if Spark did rely on Scala features that aren't in Kotlin (it doesn't), Spark is a library/framework/middleware completely unlike enterprise projects. It is orders of magnitude smaller, for one. That is not to say it isn't awesome, but I wouldn't extrapolate from its choice of technologies (including the language) to the enterprise.

4. Clojure makes writing DSLs easier and with far less magic. Groovy DSLs are also as powerful as Scala's and easier to write. Kotlin DSLs are not as powerful, but are more than enough for Spark.

5. I've never, ever, said Scala is unusable. In fact, I've always said (and believed), it is a very powerful language. I have said that that kind of power is not what most companies want or need, and that that kind of unopinionated kitchen-sink, cutting-edge language is probably not suitable for long-time maintenance in large companies. I completely stand by this. My problem with Scala, again, is not that it's a bad helicopter, but that it insists that it's a good choice if what you want is a car (unless you actually try to drive it like a car -- as Spark does -- in which case you invite the ire of the entire community), and, IMO, it isn't.

6. It's OK to not like your language. It's OK to say it. It's OK to explain why. And it's OK for you to disagree. That doesn't make me biased, and certainly not some kind of bogeyman. It also doesn't justify ad hominem attacks, which -- unlike my criticism of Scala -- are completely unfounded.

Re: Ask HN: Has anyone here programmed in Kotlin? What do you think about it?

#167

Earlier quoted context omitted.

Interesting analogy, incredible how Spark drives the Scala helicopter like a car; they seem to have nailed parallel parking ;-) Seriously though, I doubt Kotlin would ever be the first choice for a project like Spark since Scala excels in the DSL department (really without rival on the JVM, and off, only Haskell comes close). Look through Spark source code [1] and you'll see: operator overloading, (sealed) ADTs, exha…

Do you actually know Kotlin? It has many features for DSL support, including operator overloading (though not the ability to invent random new operators fortunately), infix notation, a form of exhaustive pattern matching, extension functions, annotation processing, inlineable anonymous extension functions which sounds bizarre but actually is key to defining many DSLs in the language, and so on. It's a different appro…

Or our Kotlin actor API: http://blog.paralleluniverse.co/2015/06/04/quasar-kotlin/

Re: Ask HN: Has anyone here programmed in Kotlin? What do you think about it?

#168
post #68

Earlier quoted context omitted.

Kotlin is great, but I would like to point out a few things: > Lambdas can be inlined! Kotlin's inline functions are meant to serve as a poor man's macro system (to implement simple control structures) and/or for argument type specialization -- not to save the "inner class overhead" because, guess what? There isn't one! While HotSpot's JIT will certainly not inline lambdas in every circumstance (though it's getting b…

Inlining is also about performance. Classes impose significant memory and code size overhead even if HotSpot does inline the code eventually .... but much code is still interpreted. And Kotlin also targets Android. Finding documentation about what optimisations ART does is difficult, but I imagine it's got a weaker compiler than HotSpot if only because it's newer.

Not directly related, but for completeness sake: Java 8 lambdas only generate classes for capturing lambdas, and even then, only at runtime (a class file isn't generated). Kotlin can't quite do that because it relies on method handles and invokedynamic, which are missing from Android.

Also, there are few compilers anywhere with optimizations as powerful as HotSpot :) And HotSpot compilation is only getting better and better. Java 9 will even let us use Graal as the optimizing compiler (i.e. instead of C2), which can do this: https://twitter.com/ChrisGSeaton/status/619885182104043520

Re: Ask HN: Has anyone here programmed in Kotlin? What do you think about it?

#169
post #135

Earlier quoted context omitted.

FYI, I had taken "every opportunity to danger-danger-dragons-be-there" Scala — on record — years before I even dreamed of the database company that would one day have an open-source project which would end up competing with Akka (I'm talking 2009/10, while Quasar was first conceived in mid 2013). It was after leading an attempt to adopt Scala at a large organization, which failed because of what I saw as Scala's bait…

Interesting analogy, incredible how Spark drives the Scala helicopter like a car; they seem to have nailed parallel parking ;-) Seriously though, I doubt Kotlin would ever be the first choice for a project like Spark since Scala excels in the DSL department (really without rival on the JVM, and off, only Haskell comes close). Look through Spark source code [1] and you'll see: operator overloading, (sealed) ADTs, exha…

To add to my previous comment (now below), Scala DSLs are without rival only in the complexity of their composition. Clojure DSLs are based on macros. Groovy's are on builders and method-missing. Haskell's are on symbols, monad syntax (do) and lazy evaluation. Kotlin's are built with typesafe builders and inline functions. Scala's are built with symbols, right-associative operators, macros, implicits, monad syntax (for) and possibly even dynamics.

Even this most powerful yet most dangerously-clever capability offered by some programming language is supported by like five different Scala features with ten different ways of achieving the same goal. It's absolutely perfect if you want to explore different ways of programming. It's not so great if you need to maintain your DSL for the next 10-15 years in a large organization.

Besides, given that the JVM has two of most advanced meta-programming tools anywhere, Xtext[1] and JetBrains' own MPS[2], I wouldn't call any JVM language's embedded DSLs "without rival". All this is about to get even better with Truffle/Graal in Java 9. Saw an interesting talk about easily constructing very efficient languages with Truffle and object algebras at ECOOP[3]. So, especially on the JVM, going for an embedded DSL, let alone one built with very complicated techniques (rather than just Lisp macros) is probably not the best way to use DSLs. It has no advantages and lots of disadvantages.

[1]: https://eclipse.org/Xtext/

[2]: https://www.jetbrains.com/mps/

[3]: https://twitter.com/biboudis/status/618402989720662016

Re: Ask HN: Has anyone here programmed in Kotlin? What do you think about it?

#170

I've played a bit with Kotlin and have a much better knowledge of Scala, so I could be biased. I like Kotlin, it looks like Java should look like. Kotlin is "just" a better language and not a complete new World like Scala. In Scala it feels often wrong to use a Java lib instead of a Scala lib. So, Kotlin is a smooth upgrade for all Java developers. But Scala is much, much more powerful than Kotlin. Just look at Scala…

Traits seem like an odd feature to pick. What are you thinking of, precisely? Kotlin interfaces are basically the same: they can contain method and property impls (same as Java 8). Do Scala traits have some additional feature I am unaware of? I admit to a little bias: I've tried to get into Scala several times, but the bad documentation and often overly complex approach puts me off. A lot of Scala features seem like…

Kotlin interfaces are essentially the same as Java interfaces. But Traits in Scala are more like (slightly) restricted multiple inheritance. They can have fields, they can be stacked (http://www.artima.com/scalazine/articles/stackable_trait_pat...), you can restrict the types where a trait can be mixed in.

Value types are useful to enforce certain types which helps to avoid million dollar mistakes like the NASA made when mixing inch and meter as simple floating point numbers.

All in all I think, that Kotlin is a good example of the 80:20 rule. You get the most useful concepts and convenience with a low investment. Maybe Kotlin hits a sweet spot in the JVM landscape.

Post reply on HN