Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

171–180 of 203 posts

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

#171

Post by mplatvoet »

CookieCutter2 wrote: post #39
CookieCutter2 wrote: post #13

Always looking for something more simple than (my current) Scala. - Argued with the developers, they have not clue about Option/Maybe and what it's good for. They offer non-nullable type which solves just one - minor - problem with Null - No deconstruction - Their documentation in the beginning mixed features and planned features without discrimination. Spend a lot of time to find out trying to make them work that th…

To clarify: Option/Maybe solves the problem of things either being there or not (from databases, domain modelling, ...). As a side effect this solves NPEs. Non-Nullable Types is there to solve (accessing non initialized variables) NPEs.

The question is, why should this be part of the language or standard library? This can easily be achieved by a library.

The Kotlin type system does help though/is essential to correctly implement Option types where other languages like C# can not.

The essential part is you can/should define an Option type with a non-null upper bound. Otherwise you would have a Some() that still might contain a null value. So the side affect of solving NPEs you speak of is only there if a language actually supports non-null upper bounds.

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

#172

Post by mike_hearn »

cryptos wrote: post #170
mike_hearn wrote: post #152

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…

Yes, being able to define numeric units is a helpful feature indeed.

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

#173

Post by mplatvoet »

lakedaemon wrote: post #126
merb wrote: 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…

For tests : I have had some nice experience writing jUnit tests with pitest (PIT) : there is a gradle plugin to do that in AS/Idea The only issue I had was to ignore Package class to make pit work For DI, Dagger2 works fine with kotlin For multithreading : Quasar supports Kotlin (I'm waiting for quasar to support android though)

If you want easy multithreading on Android take a look at Kovenant http://kovenant.komponents.nl/android/features/

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

#174

Post by mike_hearn »

CookieCutter2 wrote: post #13

Always looking for something more simple than (my current) Scala. - Argued with the developers, they have not clue about Option/Maybe and what it's good for. They offer non-nullable type which solves just one - minor - problem with Null - No deconstruction - Their documentation in the beginning mixed features and planned features without discrimination. Spend a lot of time to find out trying to make them work that th…

How is option different from proper nullability in the type system? In every case I've seen an option type be used, it was always a less efficient way of approximating how Kotlin does it.

Kotlin has deconstruction:

    val (a,b,c) = myDataObject
Their documentation did indeed commit this sin when I first started using Kotlin last year. It's been cleaned up considerably and this is no longer an issue (except, I think, for the mysterious modules which appear to be an IDE specific concept).

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

#175

Post by mike_hearn »

CookieCutter2 wrote: post #39
CookieCutter2 wrote: post #13

Always looking for something more simple than (my current) Scala. - Argued with the developers, they have not clue about Option/Maybe and what it's good for. They offer non-nullable type which solves just one - minor - problem with Null - No deconstruction - Their documentation in the beginning mixed features and planned features without discrimination. Spend a lot of time to find out trying to make them work that th…

To clarify: Option/Maybe solves the problem of things either being there or not (from databases, domain modelling, ...). As a side effect this solves NPEs. Non-Nullable Types is there to solve (accessing non initialized variables) NPEs.

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.

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

#176

Post by michel-slm »

lakedaemon wrote: post #126
merb wrote: 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…

For tests : I have had some nice experience writing jUnit tests with pitest (PIT) : there is a gradle plugin to do that in AS/Idea The only issue I had was to ignore Package class to make pit work For DI, Dagger2 works fine with kotlin For multithreading : Quasar supports Kotlin (I'm waiting for quasar to support android though)

Can you use PIT with Kotlin? Really tempted to try it out but wasn't sure. I suppose if it works at the bytecode instead of source level it would just work.

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

#177

Post by CookieCutter2 »

mike_hearn wrote: post #174
CookieCutter2 wrote: post #13

Always looking for something more simple than (my current) Scala. - Argued with the developers, they have not clue about Option/Maybe and what it's good for. They offer non-nullable type which solves just one - minor - problem with Null - No deconstruction - Their documentation in the beginning mixed features and planned features without discrimination. Spend a lot of time to find out trying to make them work that th…

How is option different from proper nullability in the type system? In every case I've seen an option type be used, it was always a less efficient way of approximating how Kotlin does it. Kotlin has deconstruction: val (a,b,c) = myDataObject Their documentation did indeed commit this sin when I first started using Kotlin last year. It's been cleaned up considerably and this is no longer an issue (except, I think, for…

1. Option solves a long list of programming problems (mostly around things being there or not, but others as well) while non-nullable types only solve NPEs.

2. Sorry, wording is vaque, often deconstruction is

val MyValueObject(a,b,c) = myObject

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

#178

Post by CookieCutter2 »

mike_hearn wrote: post #175
CookieCutter2 wrote: post #39

Earlier quoted context omitted.

To clarify: Option/Maybe solves the problem of things either being there or not (from databases, domain modelling, ...). As a side effect this solves NPEs. Non-Nullable Types is there to solve (accessing non initialized variables) NPEs.

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 until the very last moment. Sorry my English is not good enough to make the point :-( And I know, saying "You need to use Option (and Applictives etc.) some years to grok" sounds arrogant and unsatisfactory. But I would not go back to a language without Option (and Applicatives etc.) usage in it's culture.

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

#179

Post by CookieCutter2 »

mplatvoet wrote: post #171
CookieCutter2 wrote: post #39

Earlier quoted context omitted.

To clarify: Option/Maybe solves the problem of things either being there or not (from databases, domain modelling, ...). As a side effect this solves NPEs. Non-Nullable Types is there to solve (accessing non initialized variables) NPEs.

The question is, why should this be part of the language or standard library? This can easily be achieved by a library. The Kotlin type system does help though/is essential to correctly implement Option types where other languages like C# can not. The essential part is you can/should define an Option type with a non-null upper bound. Otherwise you would have a Some() that still might contain a null value. So the side…

Without proper Option deconstruction and map()/flatMap() syntacic sugar Option code beside map() is not very pleasent to read or understand to my eyes :-(

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

#180

Post by vickychijwani »

dodyg wrote: post #9

I started an open source Android project in Kotlin ( https://github.com/dodyg ) three years ago so I have witnessed the language evolution from early on. This is what I love about Kotlin: - It is IMHO the best language to develop native application in Android by far. - I was primarily a C# developer (still now) and I could pick up the language in a day. The language is quite small for people that has already known a…

Can you elaborate on what Kotlin doesn't get right? Surely there's something. Just trying to get a more balanced perspective here.
Post reply on HN