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

41–50 of 199 posts

Re: From Java to Kotlin and Back Again

#41

Post by krzyk »

jrs95 wrote: post #21
kjeetgill wrote: post #9

Earlier quoted context omitted.

I'm unfamiliar with Kotlin in detail. Can you explain "Functions are first-class (you can pass functions to functions)"? Are they more powerful than Java's lambdas?

Yes, Java lambdas are just syntactic sugar over anonymous classes with a single method IIRC. You must define a full Interface to use when defining the function signature. Kotlin functions are essentially objects that can be passed around, stored in variables, etc. You can also have functions that don’t belong to any class, no need to use static methods for that.

Not exactly, lambdas use invokedynamic which has different performance characteristics when compared to anonymous classes.

See a talk by Brian Goetz - https://www.youtube.com/watch?v=MLksirK9nnE

Re: From Java to Kotlin and Back Again

#44

Post by euroclydon »

eropple wrote: post #3

There exist really, really good arguments for the structure of a programming language. Obvious example: I think Perl-as-is-generally-written is line noise. But complaints like "the type comes after the variable name [so that we can consistently define types, including in arguments, without inconsistent syntax like Java is now forced into]"...aren't good. You might not be comfortable with it off the jump; it's more co…

> I think the way they do blocks is odd. I think that the braces should encapsulate the body of the block, not the variable expression as well

I can't find an example of what I imagine you're saying.

Can you link to an example from here the reference docs?

https://kotlinlang.org/docs/reference

Re: From Java to Kotlin and Back Again

#45

Post by __sr__ »

Is it me, or does the article feel like it is written by someone who didn’t actually bother to learn Kotlin. Instead they learnt the bare minimum syntax and tried to write Java in Kotlin.

The author complains a lot about how Kotlin is different from Java. Err.. it is a new language — it is supposed to be different — otherwise why bother?

> I have my favorite set of JVM languages. Java in /main and Groovy in /test are the best-performing duo for me. In summer 2017 my team started a new microservice project, and as usual, we talked about languages and technologies. There are a few Kotlin advocating teams at Allegro, and we wanted to try something new, so we decided to give Kotlin a try.

The opening lines set the tone for the article. The author tried Kotlin because other people wanted to — not because he found it interesting. Most people learn a new language by writing a toy project or two. They don’t start with a real project. And of course it will take time to get used to a new language and be as productive in it as as you were in the old one. The friction is always there, no matter which language you are switching to.

I am sorry, but I can’t take this article seriously — I feel that it’s written for the sole purpose of venting author’s frustrations.

Re: From Java to Kotlin and Back Again

#46

Post by V-2 »

bitL wrote: post #7

Good and clear summary of Kotlin warts. In the end I couldn't suppress the thought that there was some hidden Polish-Russian rivalry going on ("Kotlin" == "Heinz") ;-)

Heinz is American (and, in the context of the article, a global brand), not Russian.

Re: From Java to Kotlin and Back Again

#47

Post by solidninja »

johnwick17 wrote: post #13

My 5 cents: It seems to me that the author did not spent enough time to learn Kotlin. The way he mixes Java types (Integer.parseInt) inside pure Kotlin code and then complains about lack of Null-Safety? It is enough to use an extension function String.toInt() to stick to Null-Safety and compiler will do the rest. His main() function? Another weird argument because Kotlin's documentation has some examples on how to wr…

I have to agree. Sometimes you do find developers with so much tunnel vision of the "one true way" that it becomes difficult to open their minds to doing things slightly differently.

For example, the null safety example and the complaint that having `!`, `?`, `!!` is "too Scala like" and too complex. I wonder if the author ever had to reason about or in Java (e.g. https://briangordon.github.io/2014/09/covariance-and-contrav...). Scala doesn't even have these sigils (there is a different syntax for variance, type bounds and context bounds - but that's about all there is).

Another example - "In the C-family of programming languages, we have the standard way of declaring types of things." At that point you may as well point out that maybe Kotlin isn't in the C family.

Re: From Java to Kotlin and Back Again

#48

Post by pjmlp »

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

Re: From Java to Kotlin and Back Again

#49

Post by pvg »

johnwick17 wrote: post #13

My 5 cents: It seems to me that the author did not spent enough time to learn Kotlin. The way he mixes Java types (Integer.parseInt) inside pure Kotlin code and then complains about lack of Null-Safety? It is enough to use an extension function String.toInt() to stick to Null-Safety and compiler will do the rest. His main() function? Another weird argument because Kotlin's documentation has some examples on how to wr…

"didn't bother" "bitching" "no clue" "another gem" "hateful"

There's really nothing in the article that warrants any of this.

Re: From Java to Kotlin and Back Again

#50

Post by sixbrx »

kodablah wrote: post #11

I work in Kotlin and Java and have opinions on both. Some feedback... I disagree about the name shadowing issue. In fact, I wish Kotlin didn't suck so hard and not allow me to ignore those warnings specifically. My primary use for name shadowing is so that I don't use the previous variable. This may be a bit strange, but in highly functional contexts with immutable variables, shadowing a name is reasonable especially…

I agree about the shadowing. I find in some cases I need to refine a value to a more correct/cleaned/canonical form, but a separate method to establish an all-new scope is too much and would impact clarity. In those cases it's an insidious bug to accidentally be using an old/non-canonical form of something in the following code somewhere, mixed in with the uses of the refined form, just because the name can't be shadowed. It's very hard to spot because both forms seem to "read" correctly in isolation.
Post reply on HN