Christopher Hübner
01/22/2024, 12:32 PMThomas
01/22/2024, 12:41 PMkqr
01/22/2024, 12:42 PMThomas
01/22/2024, 12:43 PMChristopher Hübner
01/22/2024, 12:44 PMThomas
01/22/2024, 12:45 PMThomas
01/22/2024, 12:45 PMChristopher Hübner
01/22/2024, 12:46 PMfun handleIp(ipAdress: IpAdress) : Nothing = when(ipAdress) {
is IpAdress.IpV4 -> TODO()
}
thanksforallthefish
01/22/2024, 1:28 PMthanksforallthefish
01/22/2024, 1:30 PMChristopher Hübner
01/22/2024, 1:35 PMDavio
01/22/2024, 1:44 PMSzymon Jeziorski
01/22/2024, 2:12 PMUnsupportedOperationException
fairly quickly. Kotlin seperates mutable collection interfaces, so if method's signature states to return read-only List, you just cannot invoke mutable methods on it - compiler has you covered in compile-time there.
They are also inconsistent in use of generics.
Let's say you have a list of dogs declared as List<Dog> dogs = new ArrayList<>();
. If you would like to add something to the list, add
method takes element generic argument, so you can only add another instance of a Dog, but when it comes to removing elements... well you can call dogs.remove(new Pickaxe());
because remove
takes an element of type Object
. That's just one example of method that uses Object
where it would make sense to use generics. It's also another example of failing in runtime (for example by ClassCastException), where the compiler could easily handle error case given proper method signature.
You still have to know how to use the API, but you're less likely to shoot yourself in the foot. 🙂
There are many such examples of inconsistencies and unintuitiveness in Java's API. Sure, if you are proficient in Java and you know its design, you will most of the bugs possibly related to above, but why not to choose a language that just has those fixed?
Besides Java issues, there are just a ton of Kotlin features that can make your life easier.
I don't want to make this post too long, so I'll just throw in some bullet points for you to look up: extension functions, named arguments, coroutines, lambdas with receivers, inline functions, reified generics.
I'm no Java champion, but I've used Java before, and I'm working on JVM, so I do see it everyday at job. Having that said, I'm working on Kotlin-first JVM backends for 2.5 years and here's my take:
It's definitely worth understanding Java and its APIs if you're targeting JVM, but I don't see compelling enough reason to pick Java over Kotlin for language to write in, if you're given a choice. They are interoperable, so you can call any Java code from Kotlin.
And if you are just switching from entirely different language as PHP and want to just use new language, no fireworks or fancy features, then I would still be suggesting Kotlin - you can still benefit many crucial mechanisms as null safety, while also being able to just use richer and (IMO) more mature standard library. Of course, you can make your code highly unreadable when trying to overuse all syntactic features you've just learned, but firstly that wouldn't be language's fault, and secondly, at least in 99% of chances you will not get NullPointerException
where you don't expect it (caugh caugh Java) 🙂
It is true that Kotlin's tooling is not yet on the same level as Java's, but given reasons above, to me it's definitely not a deal breaker, especially considering the fact that it's getting better over time.ashmelev
01/22/2024, 3:22 PMDavio
01/23/2024, 8:22 AMhho
01/23/2024, 10:19 AMwakingrufus
01/24/2024, 2:22 AMbidadh
01/27/2024, 5:32 AMstarter
modules, which, with Kotlin, is again better!
if you combine it with Gradle Kotlin DSL, makes it the perfect solution, and now I’m trying to bring KMM