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

From Java to Kotlin and Back Again

allegro.tech

Post reply on HN
Print view View original

131–140 of 199 posts

Re: From Java to Kotlin and Back Again

#131

Post by lmm »

shrewduser wrote: post #123
lmm wrote: post #115

Earlier quoted context omitted.

At the concrete/immediate level, a nice way to do error handling when you want errors to include a detail message (i.e. a Result/Either-like) - most languages that offer Option-like types let you use a type like that the same way, but in Kotlin the nice ?. syntax only works for "null". Even Java checked exceptions are a better answer for that use case than anything in Kotlin. Proper immutable types for e.g. collectio…

Sounds like the arrow for kotlin. I think eventually we will see all these things inside kotlin proper but kotlin is pragmatism of idealism not the reverse like scala so in good time for now we have Arrow.

> I think eventually we will see all these things inside kotlin proper but kotlin is pragmatism of idealism not the reverse like scala so in good time for now we have Arrow.

This is an absurd anti-intellectual non-argument. Saying "pragmatism" isn't an argument; if there were actual use cases where the kotlin design was better that would be one thing, but there aren't; it's just inconsistent for no real reason.

Re: From Java to Kotlin and Back Again

#132

Post by AlphaSite »

Roboprog wrote: post #102
V-2 wrote: post #66

"Kotlin changed the extends keyword into the : operator, which is already used to separate variable name from its type. Back to C++ syntax? For me it’s confusing." Not only C++; C# also. It's not very hard to confuse the author, is it :) I understand it's different from Java he's used to, but that doesn't mean one can hold every such difference against Kotlin. Not being Java isn't in and of itself a fault of a langua…

OK, so I’m used to : from doing Pascal back in the 80s, but anyway. Read the colon as “is a”, and it makes sense. “counter is a number” “DogClass is a (special) MammalClass”. Not seeing a problem there, but again, I have no particular love for curly brace languages. And I would MUCH rather see the type expression spewage AFTER the symbol name - especially given Java 5 generic declarations mixed with Java 8 lambda dec…

`var` helps a little.

Re: From Java to Kotlin and Back Again

#133

Post by bcoates »

kllrnohj wrote: post #113
bcoates wrote: post #100

Earlier quoted context omitted.

Optionally ignoring thread safety seems indefensible -- until you can go full COM and declare your package apartment-threaded, working in a mutable language with uncontrolled multi-threading is the deal with the devil you've made and code that doesn't embrace that reality is just broken. Agree about the shadowing. var x_2 = f(x_1) // never use x_1 again for anything deserves its own syntax and compiler checks

> Optionally ignoring thread safety seems indefensible Nobody forces everything to be thread safe. That would either be suicidally complex or suicidally slow. The problem isn't so much "ignoring thread safety", it's that this: class Foo(var thing: Int?) { fun doSomething() { if (thing != null) { thing++ } } } doesn't compile and it should . It fails to compile claiming that 'thing' could have changed in the meantime,…

They can't ever prove it; even just

  class Foo(var thing: Int?) {
    fun doSomething() {
      if (thing != null) {
        thing++
      }
    }
  }
is unsafe as any class user could cons up a Foo t, and call t.doSomething() while racing a modification to t.thing in another thread. There either needs to be a language feature for Foo to live in a restricted threading context or the whole construct is irreparably thread-unsafe. The error is valid because it rejects always-incorrect code.

Re: From Java to Kotlin and Back Again

#134

Post by lmm »

kllrnohj wrote: post #122
lmm wrote: post #115

Earlier quoted context omitted.

At the concrete/immediate level, a nice way to do error handling when you want errors to include a detail message (i.e. a Result/Either-like) - most languages that offer Option-like types let you use a type like that the same way, but in Kotlin the nice ?. syntax only works for "null". Even Java checked exceptions are a better answer for that use case than anything in Kotlin. Proper immutable types for e.g. collectio…

Re immutable: If you're doing functional why does this matter? "true" immutable vs. just an immutable view should only matter if the object is retained by the function it's passed to, but now we're talking object state rather than pure functions. Re "command-like" objects: I'm not following, can you give an example of something you can do in Scala here that you can't in Kotlin?

> Re immutable: If you're doing functional why does this matter? "true" immutable vs. just an immutable view should only matter if the object is retained by the function it's passed to, but now we're talking object state rather than pure functions.

For the same reason that being able to write val rather than var matters. With perfect discipline you can write pure functional code in any language, but in practice (and in codebases that likely have some non-functional sections, particularly if you're interoperating with Java) being able to be 100% sure that a given value is really immutable rather than 99.9% sure makes a huge difference.

> Re "command-like" objects: I'm not following, can you give an example of something you can do in Scala here that you can't in Kotlin?

There are lots of different use cases for this stuff, but one I was working with today was database transactions. I have operations that should only happen inside a database transaction, and want to enforce that at the type level, but I want to be able to compose several of those functions in a single database transaction, so I don't want to just have each one run its own transaction. So what I do is have a custom type, something like MustHappenInTransaction[A], which is actually just an alias for an existing library type (Free), and I automatically get the ability to use the for/yield syntax to compose these, and can use existing library functions to operate on it almost as if it were a plain value, but still safely (e.g. traverse rather than map on a sequence). I have no way to "get the A out" except for my doTransaction() function (what's why I say it's a command-like object), so the function will definitely happen in a transaction, but I can still do normal function composition, extract out common subfunctions, and all that.

You can't do that in Kotlin because there's no equivalent to "do notation" or "for comprehension" that you can use for user-defined types, and there are no higher-kinded types so you can't implement generic helper functions like traverse (there's no way to write the type signature it should have).

Re: From Java to Kotlin and Back Again

#135

Post by ghik »

lmm wrote: post #115
kllrnohj wrote: post #104

Earlier quoted context omitted.

> then why would you adopt it when it's missing important features compared to Scala Such as?

At the concrete/immediate level, a nice way to do error handling when you want errors to include a detail message (i.e. a Result/Either-like) - most languages that offer Option-like types let you use a type like that the same way, but in Kotlin the nice ?. syntax only works for "null". Even Java checked exceptions are a better answer for that use case than anything in Kotlin. Proper immutable types for e.g. collectio…

There's only immutable List in Scala. Seq or Map would be better examples (they actually come in three versions).

Re: From Java to Kotlin and Back Again

#136

Post by dagenix »

It seems like the author likes Java quite a bit. Kotlin, not being Java, seems to be his primary complaint. Take his first point - Kotlin allows variable shadowing. He doesn't say why it's bad or how it caused a bug, he just says that Java doesn't support it and he doesn't like it.

Everyone is entitled to their opponion. But, this article doesn't seem to have much of a point. It would be like if I wrote and article about how I preferred cherry popsicles to grape popsicles. That my opponion and I'm entitled to it. But, I don't know why I'd want to be publish a blog post about it or why anyone else should read it or care.

Re: From Java to Kotlin and Back Again

#137

Post by cesarb »

pjmlp wrote: post #48
_bxg1 wrote: post #27

TypeScript also has the weird reversed type declaration. I've never understood it; it's so much less natural to read. Having the type first allows you to easily mentally parse it as "A Foo named bob".

It is not weird, in fact it goes all the way back to Algol, a decade before C was invented.

> It is not weird, in fact it goes all the way back to Algol, a decade before C was invented.

As the classic "A Brief, Incomplete, and Mostly Wrong History of Programming Languages" (https://james-iry.blogspot.com.br/2009/05/brief-incomplete-a...) would say:

This criticism happens in spite of the fact that C has not yet been invented.

Re: From Java to Kotlin and Back Again

#138

Post by jillesvangurp »

I've been spending some quality time with Kotlin the past few weeks and have been converting some of our Java code. The fact that this is easy and that you can mix java and kotlin code makes the transition very easy. Mostly the transition has been pretty smooth and I'm liking this enough that I don't really care about switching back to Java at this point. For reference, I've been doing Java since 1996. It's been my primary language for most of that period. Kotlin is a big deal for me and I'm not doing this on a whim. I've been following Kotlin progress for years before deciding to switch.

What this author seems to get hung up on is that not all Java idioms port well to Kotlin. Some of his criticism is fair, e.g. the companion object thing is indeed a bit of a kludge. No matter how the Kotlin people spin it, the fact is that it is coming up frequently in forums, stackoverflow, etc. It's clearly a problem and it is entirely fixable.

So, it would be helpful if they added proper support for static fields and methods without requiring ugly annotations and offer full back and forward compatibility to Java. The JVM supports it and clearly their compiler supports it if you get insistent with the right amount of ugly annotations and verbosity. So, I see no sound technical reason for not doing this. However, it is not a show stopper. Companion object with some functions, add @JvmStatic annotations, problem solved.

There definitely are some more ugly corners in the language but mostly is clearly better than Java. And just because it's there doesn't have to mean you have to use all of it all the time. Adding question marks all over the place doesn't look like idiomatic Kotlin to me. Better to just have null safe code and not having to deal with nulls. Also, java.lang.Optional works just fine in Kotlin and kotlin probably adds some useful extension methods.

Otherwise, sane generics, extension functions, flexible property definition, data classes, no difference between boxed/unboxed primitive types, etc. All great stuff and kind of refreshing after dealing with Java's broken type system for years.

Add to that the upcoming support for co-routines, javascript (you can do react apps in kotlin) and native compilation, and the endorsement for android development, awesome tool support, etc. and you have a great language that is ready for just about anything.

So, mostly good stuff to say about Kotlin. As for Scala/Groovy, I never really cared for either. I'd say Kotlin's strength is that it cherry picks a few popular things from those and other languages without really trying to be those languages. It's seems to be succeeding where those languages failed in trying to get Java developers to abandon Java. Java 10 is a nice incremental change but doesn't really address most of the things that Kotlin fixes.

Re: From Java to Kotlin and Back Again

#139

Post by kllrnohj »

lmm wrote: post #134
kllrnohj wrote: post #122

Earlier quoted context omitted.

Re immutable: If you're doing functional why does this matter? "true" immutable vs. just an immutable view should only matter if the object is retained by the function it's passed to, but now we're talking object state rather than pure functions. Re "command-like" objects: I'm not following, can you give an example of something you can do in Scala here that you can't in Kotlin?

> Re immutable: If you're doing functional why does this matter? "true" immutable vs. just an immutable view should only matter if the object is retained by the function it's passed to, but now we're talking object state rather than pure functions. For the same reason that being able to write val rather than var matters. With perfect discipline you can write pure functional code in any language, but in practice (and…

You can do something like this:

    class MyTransaction {
        fun begin() {}
        fun commit() {}
    }

    fun MyTransaction.query() {}
    fun MyTransaction.update() {}

    inline fun  transaction(tblock: MyTransaction.() -> R): R {
        val t = MyTransaction()
        t.begin()
        try {
            return t.tblock()
        } finally {
            t.commit()
        }
    }

    fun test() {
        // update() doesn't compile, no such method
        val hello = transaction {
            query()
            update()
            query()
            "Hello"
        }
        println("$hello") // prints "Hello"
    }
Does that not work for your usage for some reason? Is there a problem with this approach I'm not seeing?

Re: From Java to Kotlin and Back Again

#140

Post by rsynnott »

V-2 wrote: post #78
pjmlp wrote: post #48

Earlier quoted context omitted.

It is not weird, in fact it goes all the way back to Algol, a decade before C was invented.

And the highly popular back in the day Pascal picked it right from Algol... Scala and Go follow the same approach, if I'm not mistaken

And Swift, and Rust, and... Really the C style is the odd one out here.
Post reply on HN