Live data from Hacker News

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

news.ycombinator.com

181–190 of 203 posts

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

#181
post #79

Earlier quoted context omitted.

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/

>> No reason to bake it into the language

Go-style channels and goroutines are built on green threads which Go/Erlang has, but the JVM does not have. One way to work around this is to use fibers and continuations which is what Quasar is doing.

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

#182

How does Kotlin compare to Ceylon? Has anyone written something in both languages and can share their impression?

Kotlin is build with interoperability with Java in mind from the beginning. This is not the case in Ceylon. In fact some base types (Int, Long) in Ceylon don't match the corresponding Java type. Kotlin has extension methods which Ceylon has not. Ceylon has reified types, which Kotlin has not. Ceylon went 1.0 in November 2013. So far Ceylon seems not have caught any traction, which is unfortunate as it also is a language well-made in many ways. Kotlin has at least Android development to create some initial traction.

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

#183

Earlier quoted context omitted.

Non-nullable types aren't just about uninitialised vars, where did you get that idea? Consider that function parameters can also be nullable although you cannot help but initialise them. Nullable types (nonnull is the default) solve the issue of optionality: something that might be there sometimes but also may not be.

This is hard to explain and I didn't understand it either, after programming Java for 15 years. After 5 years of Scala I can't think of not using Option. If you allow null as a return type you need to check for null if you want to use it or not. If you return Option[_] people e.g. just use map() on the return value and then map().map().map().map() on that etc. With Option your code usually does not care to check unti…

In Kotlin there's a bunch of null-handling operators, which allows you to really treat null as None. Like x?.y()?.z(). Moreover, you can define extension functions on nullable types, which covers Option's map and much more.

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

#184

Earlier quoted context omitted.

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 mad…

"Kotlin interfaces are essentially the same as Java interfaces." Interfaces in Kotlin offer functionality beyond interfaces in Java. In Java interfaces can only have public methods. In Kotlin interfaces can also have (abstract) variables. Both, methods and vars, in Kotlin interfaces can be public and also protected. You need this if you don't want to break the encapsulation of your classes that implement an interface.

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

#185
post #46

Earlier quoted context omitted.

Where would Clojure fit into this mix? How would its interop compare with Scala or Kotlin, as well as its performance?

Clojure devs don't seem to care about performance. Just check how the JVM gets the blame for what is essentially Clojure initialization time. There are some in the community trying to improve the situation, but those are kind of forks like Skummet.

By "performance" I think you specifically mean "startup time."

I think there is a big difference between startup time and runtime performance. It is well-known and fully acknowledged by the Clojure community that starting up a Clojure environment and REPL takes a while. But are you also suggesting there is a problem with Clojure runtime performance?

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

#186
I started looking into Kotlin already when it was M2. Always liked it a lot, because every feature has a reason to exist. Nothing is added without careful thought whether it is needed at all or could be solved in the library anyway. Scala would have been a much more consistent language if the Scala people had progressed in this way as well and Scala code would also be much easier to read.

Kotlin seems to have a killer feature which is Android development, which is of course good. But what about internal enterprise development? It makes me think whether Kotlin has enough added value to make people change from a safe haven like Java8 to Kotlin. Sure, much better build times and less problems with code readability when using Akka, Play, Spark with Kotlin instead of Scala. Also Kotlin offers much more power in exploiting the features of those tools compared to Java. But how many people use Akka or Spark? Nevertheless, I wish Kotlin all the best. I will always greatly prefer it over Java or Scala.

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

#187
post #48

Kotlin is what Java would have been if it had been designed today. It follows the same philosophy: emphasis on readability, familiarity and maintainability, with PL research and new paradigms being non-goals. It does not introduce new concepts that will revolutionize your development, opting instead to adopt a few well-proven features (null safety, data classes). It is very easy to learn, feels modern and fun. Kotlin…

"Why not start with a mixed Java/Kotlin project?" Think that's a good idea. If you are missing AST transformations you can add Groovy to the game. All three languages in IntelliJ work really fine together. In eclipse you might have to rebuild the entire project when doing mixed language programming. I learned this were a problem with ecliupse, though.

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

#188
post #166

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…

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),…

Good points, as always.

> 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.

I didn't mention implicit conversions, but that's one area where Scala has taken the high risk high reward path. If you look a bit further down on the linked Spark page you'll see the conversions defined [1]. I'd say Spark's style guide is more geared toward Scala consumers and not necessarily library authors (i.e. if you know what you're doing have at it; otherwise keep to a strict subset).

Basically, in aggregate Scala's feature set is incredibly powerful; that power (despite the complexity, tooling challenges, and slow builds) is what draws dsl authors to Scala.

When IBM throws down an absolute boatload of cash on a project written in Scala, by proxy Scala benefits. Right off the bat there are de facto 3,500 new Scala developers (since the initial IBM Spark team will of course be learning Scala). Furthermore, it's not like competitors aren't aware of this, Spark automically becomes more of a "big deal" as a result, which cannot help but be a boon for Scala.

As for other JVM languages, agreed, Clojure has its own supply of awesome, though the lack of (built-in) static types are a no-op here. Groovy, meh, seems to be on a downtrend, I suspect non-immutable-by-default dynamic languages (except of course, javascript) will continue to fall out of favor.

Now, Kotlin, it's a nice language. If they can deliver on near Java build times, might just be the Java killer that Scala will never be, or at least not in its current design (where, as you rightly say, there is often more than one way to do the same thing).

Let's see how things play out over the next 3-5 years, JVM alternative language landscape is diverse and evolving quickly, good times now and great times ahead...

[1] https://github.com/apache/spark/blob/master/sql/catalyst/src...

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

#189

Yes, I've used kotlin to replace a large legacy Java application. Pretty critical to the business, sat in the middle interacting with. All upstream and downstream systems. Kotlin certain ly made life easier in some places, most importantly it was fast and easy and a joy to work with.

How can I contact you to hear more about your experiences?

pm me :)

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

#190
I today decided to try it on small project. I had a lot of class name clashes (wsimport from similar but different WSDLs). I had a nightmare in Java and Kotlin saved me, thanks to its smart import. Properties are much more readable than getters-setters. And there are a lot of sugar here and there, which makes programming more fun.

I literally spent may be 5 minutes reading their site. The language is extremely small and intuitive to pick up, if you had some experience with Scala.

IDE worked fine. I had few exceptions, but they didn't ruined anything. Refactorings worked. IDE support is very nice.

Post reply on HN