Community comments are great!

Need swift to kotlin

As an experienced Android engineer. Should I learn multiplatform technical skills such as KMP, flutter, React Native. Which would be the best one.

I wish Kotlin would add support for dataarg (similar to vararg). It would make data classes more composable -- e.g. clone a data class with a few more fields without copying the full list of fields.

good

So cool!

this Video is so 🤯I'm a professional Java Developer, wich sitching currently to Kotlin, this is my 3th Video from you, and i love it. This is Nerd P**n

Thank you Dave. very clear explanation. more in-depth videos explaining coroutines please.

Do you plan to implement a Chain of Responsibility?

Masterfully explained. Loving this series.

Today I learned something new thankyou ❤

just one more example of how kotlin is badly designed

11:29 Can you show the code snipet?

All the things are neat. It would be great if you also explain each of such cool language features with a practical use case.

why is this api still unreleased?

Awesome 👍

I wish the kotlin team had thrown away the java collections from beginning. They are so f***** wrong and Kotlin made it even more worse, (whats not their fault). 1. Iterating over an arraylist by index and get method is significantly faster than all other methods. The problem is, in kotlin using the lesser conrete type List for definitions is common. Even when all the Lists are 95% Arraylist you cant be sure. Its also possible that the List you got from somewhere is a Linkedlist and you go to performance hell with get method. 2. The problem is that the java lists are poorly optimized. When you want full performance you cant rely on the build in non existing optimizations, you have to optimize from outside. But when everybody uses non concrete types for defining their members and returns you have no chance. Best example is listOf() which creates a ArrayList but returns it as List. Knowing its an Arraylist would give you the possibility to optimize, but the information is just thrown away. If the collections would be well implemented it would be a good practice to use non concrete types, but they are not. 3. Java is unable to give lists a search(lambda) method in decades!!!!. It just have a forEach method. Where is the problem? The problem is that you have to use iterators when searching things since you should not use get-method because of not random access lists. So there is unnecessary object creation for such simple tasks even in kotlin even for arraylists what just a bummer. Java just have to add a search method to the list interface with a default implementation and let derived classes implement their optimized versions. 4. There is a RandomAccess-Interface for lists in Java, nice. ArrayList implements it, LinkedList dont, nice. But the Java-geniuses thought its a good idea to let RandomAccess not derive from List. Its a pure marker interface providing zero methos. WHY??? So we have RandomAccess which can do fast gets but it has no get-method and we have LinkedList which has a get-method but O(n) means it doesnt work. The existence of LinkedList.get() is a crime. But no problem, just hide the crime and let others run into problems: val iFeelAshamed : List<T> = LinkedList<T>. Using the non conrete type in this case doesnt even prevent optimizations it introduces heavy deoptimization The list goes on and on. Overall, i say: Mark java collections as depcreated and replace them by a modern, thoughtout and well implemented new library. Yes, i spent too much time in useless micro benchmarking last days and i saw things you have to call war crimes. Kotlin cant fix it by sugar and cosmetics.

This is why Compose by default does not treat `List` as stable since it may actually be mutable.

I just treat my mutable list carefully and that's it. Immutability is mental 😅

"a MutableList" sounds awfully similar to Immutable list 😅

I never know this feature before, and after trying it, I find an interesting case: For this function: fun sum2(vararg args: Int): Int { return args.sum() } println(sum2(2, 3, 4)) When changing it to anonymous function like: val sum2 = fun(vararg args: Int): Int { return args.sum() } println(sum2(2, 3, 4)) IDE warns that `Vararg on this parameter is useless` and the call way is incorrect: `The integer literal does not conform to the expected type IntArray`. IDE tells me that the type of `sum2` is `(IntArray) -> Int`. However, after changing it to: val sum2 = fun(vararg args: Int): Int { return args.sum() } println(sum2(intArrayOf(2, 3, 4))) // here, wrap it with `intArrayOf` The IDE dose not show error lint, however, it cannot be compiled successfully: `Argument type mismatch: actual type is 'kotlin.IntArray', but 'kotlin.Int' was expected.` IDE is in K1 mode and Kotlin version is 2.0.21. Is that a bug or intended behavior?

Cheer~~~the fact or quality of being different, divergent, or inconsistent.😊

Awesome kotlin content on this channel!🙌

anonymous functions are useless should be removed.

Very well explained. But as a non native-english speaker it's difficult to wrap my head around the meaning of keyword yield in this context

Can we code a game with kotlin???

I could not understand sealed class properly.

The moment I saw the return type as a Composable lamda, my jaw dropped. I learn from this channel every single day! Thanks, can't wait for the paperback version of the book!

Mr. Grumpy is always right and Dave is always wrong. just kidding. using contracts to check if a variable is null or not, simplifies the code a lot and makes it less error prone

Thank you for this video! your explanations are so clear

Great video! But what is anonymous function from internal POV? I mean lambda is anonymous class

So, with *this* kind of composition, we have one vehicle inside another vehicle?

In our religious, Islam It's encouraging people to smile at each other The prophet Muhammad said "Your smile in your brother's face is charity" Thanks for sharing Dave ❤ Can't wait for your next video

You’re the best! I was wondering if you could consider making a video on Kotlin Flows. It would be really helpful to see topics like- Flow, StateFlow, SharedFlow

You are the best man

Gratitude helps feel better.

Based on this, operator functions like filter, map and find, all are using decorator pattern under the hood.

Now I'm confused whether to love this language or hate it

Thank you.

Great Explanation!

Probably most Jetbrains folks not even aware such anonymous fun syntax!

how using inline function allows lambda function to return values ?!

Can you explain how `where` work? Any other examples?

Loving the content. I think a great future topic could be building in-line DSLs.

Thanks Dave, these videos are so good. I have been using Kotlin in old Java ways, not really using the language features.

Thanks Dave! Your Kotlin content is Gold.

All very interesting, but a double-edged sword. The usefulnes is limited and comments here prove that it is widely unknown. I understand that this may be a product out of genericity and completeness, but it in my book a language is a means of communication between developers. What I write, another needs to understand. If they have to ponder on a piece of code due rarely used idoms, it slows them down and they might miss crucial implications (here: return value logic.) Don't get me wrong, though, it sure is an interesting corner of the language to explore.

There's a nice rule of thumb for `return` statements for that case with the inline lambda returning the `main` function: a `return` statement always returns the closest `fun`; In the case of the return inside the inlined lambda call, that is the `main` function, and for the anonymous function, it has its own `fun` so it returns there.

Best Kotlin content! Thanks Dave