https://kotlinlang.org
Join Slack
small investigation: what is your most hateful Kotlin feature, from design point? and why? I go fir...
# announcements
r
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 😶)
s
lateinit var
is somewhat like a 
val x by lazy
I like 
companion object
, because it can implement interfaces and it can be used for smart constructors.
c
i dont like following features inheritance for obvious reason companion object operator overloading
s
I don't hate any feature... But I do find some features not fully implemented, such as limited pattern matching for 
when
expressions
c
i like goroutines of golang over coroutines of kotlin
r
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.
👍 1
c
kotlin turns to be complex rather than simple to achieve concise.
n
@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?
😀 6
c
i'm not trolling i use kotlin as backend instead of java but these are my honest opinion
s
Missing package private.... Especially when even in the same file, private inner scopes cannot be accessedbu their outer scope.
👍 5
a
public by default Also don't really like the 
to
method to create a 
Pair
, really only makes sense in a 
Map
context
r
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.
s
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.
➕ 1
💯 1
c
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.
s
I love destructuring.... when used carefully and very locally. It hate it too, since it can be the cause of hard-to-spot bugs.
c
there is context and cancellation concept on golang too. @anton
n
@Chills then the #C5UPMM0A0 channel might be your thing
r
emm... are there any material about these hard-to-spot bugs? just curious 😉
s
@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/
r
@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.
g
I don't like that you have to declare subclasses of the sealed class in the same file.
r
@streetsofboston oh thats do causes problems... many thanks!! the link is awesome as well 😸
s
@gcx11 If not in the same file, how would you improve to enforce the 
sealed
part by the compiler?
r
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.
g
@streetsofboston I understand why there is restriction, but it could be at least the same package
a
@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
k
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.
r
if nesting is implemented then we have somewhat pattern matching...? just guessing. i think your point is illuminating. thanks! 😸
5 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by