small investigation: what is your most hateful Kot...

# announcements

[Ray Eldath]

small investigation: what is your most hateful Kotlin feature, from design point? and why?

I go first: lateinit, only can be a var instead of val. and perhaps companion object, it's a good idea, but i think the syntax is not very good.(though i think i can't come up with a better design 😶)

[streetsofboston]

lateinit var is somewhat like a val x by lazy

[streetsofboston]

I like companion object, because it can implement interfaces and it can be used for smart constructors.

[Chills]

i dont like following features
inheritance for obvious reason
companion object
operator overloading

[streetsofboston]

I don't hate any feature... But I do find some features not fully implemented, such as limited pattern matching for when expressions

[Chills]

i like goroutines of golang over coroutines of kotlin

[Ray Eldath]

agree. pattern matching is a very useful tool i think, and it's going to be implemented in java. i think currently kotlin lacks this for simplicity maybe...? but after all in my case pattern matching is defenitely not a necessity. when + deconstruction mostly enough for me.

[Chills]

kotlin turns to be complex rather than simple to achieve concise.

[nfrankel]

@Chills are you trolling?
what do you want to achieve
by bashing kotlin on the kotlin slack?
that’s fine you don’t like it
but then, what are you doing here?

[Chills]

i'm not trolling
i use kotlin as backend instead of java but these are my honest opinion

[streetsofboston]

Missing package private.... Especially when even in the same file, private inner scopes cannot be accessedbu their outer scope.

[Alowaniak]

public by default
Also don't really like the to method to create a Pair, really only makes sense in a Map context

[Ray Eldath]

agree again... KotlinConf 2019 addressed package private, as Andrej: package-private is what we really don't want in Kotlin, but there do have cases need this. so there'll be possibility that the cases amount are large enough to overrule us.

[streetsofboston]

I take Coroutines over goroutines. The fact that one can write imperative/sequential code as if it is non blocking while it is actually doing asynchronous stuff, is just great. On top of that, Structured Concurrency helps a lot in managing proper cancellation and avoiding leaking of asynchronous tasks.

[Chills]

get a new dev on board @nfrankel let them say the code readability is clear , bet the changes are low unless the new dev knew kotlin before hand 🙂

On other hand i do like functional way of doing things and these sugar coated things.

[streetsofboston]

I love destructuring.... when used carefully and very locally. It hate it too, since it can be the cause of hard-to-spot bugs.

[Chills]

there is context and cancellation concept on golang too. @anton

[nfrankel]

@Chills then the #C5UPMM0A0 channel might be your thing

[Ray Eldath]

emm... are there any material about these hard-to-spot bugs? just curious 😉

[streetsofboston]

@Ray Eldath eg when you destructure a data class instance and you add an extra val to it's list of properties of the same type, especially when it's in the middle of its list of properties. You won't get any compiler errors...

And this:
https://jakewharton.com/public-api-challenges-in-kotlin/

[Ray Eldath]

@Alowaniak the to problem......... today i met this hundred times, cause http4k do uses to a lot. and whenever the types mismatched, it will generate a pair, which will cover the origin of the problem, i think. kinda annoying.
but sometimes the to is very useful. so double-edged sword here.

[gcx11]

I don't like that you have to declare subclasses of the sealed class in the same file.

[Ray Eldath]

@streetsofboston oh thats do causes problems... many thanks!!
the link is awesome as well 😸

[streetsofboston]

@gcx11 If not in the same file, how would you improve to enforce the sealed part by the compiler?

[Ray Eldath]

note: java use permits clause to specify. kotlin & scala can define multiple class in one file, so they just enforce the locality.
i don't like the constraint as well... though i understand the reason.

[gcx11]

@streetsofboston I understand why there is restriction, but it could be at least the same package

[Alowaniak]

@Ray Eldath regarding the to, what annoys me even the most is that it creates a Pair while IMO it's nonsensical to talk about pairs with "to", a pair doesn't have a directional relationship
It makes sense inside a Map when it's an Entry

[Kroppeb]

I agree with the to function being bad. It is a nice short descriptive word that could be used for many things like DateTime::to(DateTime) or Point::to(Point). But now we always risk in getting a pair if one of our inputs is nullable or just a completely different type, resulting in getting a type error in a different place which can be even more confusing to novices. If we still want to use to for maps, we can make mapOf() accept a lambda where there is an infix fun <http://K.to|K.to>(value : V) available. The problem of coarse is that this would break backwards compatibility.

Unpacking of dataclasses has its flaws too. AFAIK all other languages who have something similar do not allow unpacking to the wrong amount of items. Although none of these languages have to work on the JVM.
Python does this check at runtime.
Haskell just uses the constructor notation to deconstruct as everything is immutable and "objects" are just containers for data without anything extra.
C sharp allows for function parameters to be used as output.

I would also love the nesting of destructuring. It doesn't happen often that this is useful, but it might be nice to have.

[Ray Eldath]

if nesting is implemented then we have somewhat pattern matching...? just guessing.
i think your point is illuminating. thanks! 😸