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

121–130 of 199 posts

Re: From Java to Kotlin and Back Again

#121

Post by bobbyi_settv »

hoodoof wrote: post #51

val list = listOf("Saab", "Volvo") val map = mapOf("firstName" to "John", "lastName" to "Doe") The above seems a really strange decision for a "new" language - why would you not just use the most common structure, being JSON?

One of my biggest annoyances in Scala is not having literal syntax for sequences and maps. The language seemingly tries to have every syntax convenience that's ever existed in every language, even when they conflict with each other and cause confusion, and then misses the most basic one.

I've been told that it's because "how would it know which specific sequence and map class you want", but it already has Seq() and Map() which give you the default immutable sequence and map classes, so obviously a literal syntax would give you the same one.

Re: From Java to Kotlin and Back Again

#122

Post by kllrnohj »

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…

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: From Java to Kotlin and Back Again

#123

Post by shrewduser »

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…

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.

Re: From Java to Kotlin and Back Again

#124

Post by kodablah »

lmm wrote: post #99
__sr__ wrote: post #45

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 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? Kotlin advocates try to have it both ways. If it's a full new language, to be evaluated as a full language, then why would you adopt it when it's missing important features compared to Scala? The narrative is that it's a set of small enhancements to Java that are ea…

> If it's a full new language, to be evaluated as a full language, then why would you adopt it when it's missing important features compared to Scala?

For all the features it has that Scala doesn't of course, many of which may not be part of the core language (compile times, tooling, backing, simplicity, compile-time null safety, coroutines, quality native compilation, Android support, etc).

Re: From Java to Kotlin and Back Again

#125

Post by kllrnohj »

kodablah wrote: post #109
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?

There are a lot of things I miss. Case objects, macros, string contexts, (built-in) options as single-element collections, tuples, built-in either, abstract/self types, implicits, etc. We can argue about "importance" or even if those are good things, but we can't pretend that there aren't many missing features. Granted these days I appreciate Kotlin more than Scala, but that is more about tooling and backing.

> We can argue about "importance" or even if those are good things, but we can't pretend that there aren't many missing features.

I don't think anyone would deny that Scala has the most features of anything, it's purely a question of importance. Important missing features is more interesting to discuss than purely missing features.

I've found myself more missing features from C++ when working in kotlin - specifically constexpr & static_assert.

Re: From Java to Kotlin and Back Again

#126

Post by choward »

tabs_masterrace wrote: post #59

Man i gotta disagree with almost all points in this article. Name-Shadowing is confusing? Should be common sense to not have multiple variables with the same name in the same scope. Optionals are ugly in Java-Interop, so we decided to just use Java instead. Great reasoning.

> Name-Shadowing is confusing? Should be common sense to not have multiple variables with the same name in the same scope.

You're saying name-shadowing isn't confusing because it should be common sense not to use it? Then why not just enforce that in the language?

Re: From Java to Kotlin and Back Again

#127

Post by kodablah »

kllrnohj wrote: post #125
kodablah wrote: post #109

Earlier quoted context omitted.

There are a lot of things I miss. Case objects, macros, string contexts, (built-in) options as single-element collections, tuples, built-in either, abstract/self types, implicits, etc. We can argue about "importance" or even if those are good things, but we can't pretend that there aren't many missing features. Granted these days I appreciate Kotlin more than Scala, but that is more about tooling and backing.

> We can argue about "importance" or even if those are good things, but we can't pretend that there aren't many missing features. I don't think anyone would deny that Scala has the most features of anything, it's purely a question of importance. Important missing features is more interesting to discuss than purely missing features. I've found myself more missing features from C++ when working in kotlin - specifically…

Meh, importance of language features becomes just too subjective. I consider several of the things I mentioned as important, but not important enough for me to choose the language.

Re: From Java to Kotlin and Back Again

#128

Post by pdpi »

riku_iki wrote: post #116
ptero wrote: post #74

Earlier quoted context omitted.

I feel the same way: author wants Java and was hoping only for a better Java: compatible with most patterns, tools, even libraries, but addressing some of his pet frustrations. When Kotlin did not satisfy his hopes he got disappointed. Understandably, but I do not see it as the Kotlin problem. The other problem I have with this post is that it did not state desires/hopes up front. The intro only mentions compile-time…

> a better Java: compatible with most patterns, tools, even libraries, but addressing some of his pet frustrations. But is this a main pitch of Kotlin?..

Being compatible doesn't mean that compatibility is the path of least friction, especially when it clashes with good design.

A good example of that tension is the final/open thing: Wonky frameworks abuse inheritance and force you to use open all over the place, but Effective Java suggests you should make every class/method final unless you specifically design it to be extended.

Re: From Java to Kotlin and Back Again

#129

Post by lmm »

__sr__ wrote: post #117
lmm wrote: post #99

Earlier quoted context omitted.

> 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? Kotlin advocates try to have it both ways. If it's a full new language, to be evaluated as a full language, then why would you adopt it when it's missing important features compared to Scala? The narrative is that it's a set of small enhancements to Java that are ea…

Why would you use Java when you could use C++ which has a ton of extra features? Or Haskell which has a lot of neat abstractions? Or Python which is super easy to use? Or Lisp which is extremely flexible? Simple, they all serve a particular purpose. Scala serves a particular purpose, so does Kotlin. I have found Kotlin to be an easy to use modern language which the JVM ecosystem was IMO lacking. That said, I am not a…

> Why would you use Java when you could use C++ which has a ton of extra features? Or Haskell which has a lot of neat abstractions? Or Python which is super easy to use? Or Lisp which is extremely flexible?

Because C++ and Python aren't safe enough, Haskell is too hard to learn, and Lisp is too flexible to maintain. Or maybe you weigh the factors differently and wouldn't use Java, and would pick one of those languages instead.

> Simple, they all serve a particular purpose. Scala serves a particular purpose, so does Kotlin.

I disagree with this as a language design philosophy. Your language may end up being better suited for some purposes than others, but I find languages that aim to be general-purpose tend to work out better than languages that design for a small niche. Scala in particular was explicitly designed to be a "scalable language" that could be used for both large and small programs - and my experience is that it manages that. (Indeed I'd say it doesn't make sense to adopt it as a language if it's not replacing the majority of your stack - there's more to learn in Scala than in most languages, but if you can replace two languages with Scala then that's still less to learn overall).

> No one likes small enhancements over an existing language in a new language - it is usually not worth switching over. Remember D?

Exactly - I think Kotlin has largely made the same mistake as D or CoffeScript, of not being willing to make a big enough break from the existing language in the space. And yet at the same time we see that it's not so easy for a Java user to pick up, either.

Re: From Java to Kotlin and Back Again

#130

Post by lmm »

kodablah wrote: post #124
lmm wrote: post #99

Earlier quoted context omitted.

> 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? Kotlin advocates try to have it both ways. If it's a full new language, to be evaluated as a full language, then why would you adopt it when it's missing important features compared to Scala? The narrative is that it's a set of small enhancements to Java that are ea…

> If it's a full new language, to be evaluated as a full language, then why would you adopt it when it's missing important features compared to Scala? For all the features it has that Scala doesn't of course, many of which may not be part of the core language (compile times, tooling, backing, simplicity, compile-time null safety, coroutines, quality native compilation, Android support, etc).

The claims about null-safety are pure FUD; once you get past thinking about the literal string enn-you-ell-ell, Kotlin and Scala are exactly as null-safe as each other in all the ways that matter (e.g. as shown in the article, Java interop in Kotlin has exactly the same null-safety issues as in Scala).
Post reply on HN