Isn't Kotlin just another iteration of languages like Groovy?
In other words, groovy didn't really replace Java in the end, although it found niche applications being gradle the most popular... I think. Maybe I'm wrong but... seems to me groovy will eventually fade away completely.
Do you think Kotlin might also face the same destiny? If not, why?
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
Hello I don't really want to get into comparing Kotlin with other JVM languages that are interesting in their own right and that I don't know so well.
But on the core of your question, yes, I do think Kotlin can be seen as a replacement for Java. It certainly did it in the Android world, which is now Kotlin first. And the reasons why it did apply elsewhere too. In most cases where Java is a good solution, Kotlin is a great solution. Because of the effortless interopability, you can start adding a bit of Kotlin in your existing Java codebase, and then notice it's better, and eventually replace it completely. I don't want to write in Java anymore and I think that usually I won't have to very often. Writing a JVM library is the counter example that comes to mind. Here it could make sense to use Java so that people don't have a transitive dependency to the Kotlin standard library. But even that I think could become no more problematic than adding a dependency to guava if Kotlin continues to grows.
Of course Java (or JavaScript) are huge enough that they will never disappear. But I do think that for most new projects, using Kotlin (or typescript) will be seen as a practical solution that improve developer productivity, so why not using it?
Three weeks ago I started a side project in Kotlin that could potentially replace a legacy Java code I created a couple of years ago. I'm very curious on how easy it'll be to integrate it in the whole solution, as well as how the classic GoF patterns will be applied in Kotlin.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
So actually the builder pattern is integrated in Kotlin itself.
Given data class User(val id: Int = 1, val name: String = "")
Then this do the same as the builder pattern would do in Java val user = User(name = "Alejandro", id =42)
The dialog function is a building block for building a DSL.
It takes as parameter a function init that you could define as having a parameter DialogBuilder and returning Unit. But instead you define the parameter as an extension function of DialogBuilder.
Isn't Kotlin just another iteration of languages like Groovy?
In other words, groovy didn't really replace Java in the end, although it found niche applications being gradle the most popular... I think. Maybe I'm wrong but... seems to me groovy will eventually fade away completely.
Do you think Kotlin might also face the same destiny? If not, why?
Ty.
Hello I don't really want to get into comparing Kotlin with other JVM languages that are interesting in their own right and that I don't know so well.
But on the core of your question, yes, I do think Kotlin can be seen as a replacement for Java. It certainly did it in the Android world, which is now Kotlin first. And the reasons why it did apply elsewhere too. In most cases where Java is a good solution, Kotlin is a great solution. Because of the effortless interopability, you can start adding a bit of Kotlin in your existing Java codebase, and then notice it's better, and eventually replace it completely. I don't want to write in Java anymore and I think that usually I won't have to very often. Writing a JVM library is the counter example that comes to mind. Here it could make sense to use Java so that people don't have a transitive dependency to the Kotlin standard library. But even that I think could become no more problematic than adding a dependency to guava if Kotlin continues to grows.
Of course Java (or JavaScript) are huge enough that they will never disappear. But I do think that for most new projects, using Kotlin (or typescript) will be seen as a practical solution that improve developer productivity, so why not using it?
Thank you for your response. This makes sense.
Three weeks ago I started a side project in Kotlin that could potentially replace a legacy Java code I created a couple of years ago. I'm very curious on how easy it'll be to integrate it in the whole solution, as well as how the classic GoF patterns will be applied in Kotlin.
Cheers and thanks for sharing.
You may be interested by this:
github.com/dbacinski/Design-Patter...
Hey, builder pattern is interesting....
I'm trying to understand this expression:
fun dialog(init: DialogBuilder.() -> Unit): Dialog =
DialogBuilder(init).build()
The part that is kind of weird to me is: DialogBuilder.()
Is that related to the extension functions?
So actually the builder pattern is integrated in Kotlin itself.
Given
data class User(val id: Int = 1, val name: String = "")Then this do the same as the builder pattern would do in Java
val user = User(name = "Alejandro", id =42)The
dialogfunction is a building block for building a DSL.It takes as parameter a function
initthat you could define as having a parameterDialogBuilderand returningUnit. But instead you define the parameter as an extension function ofDialogBuilder.kotlinlang.org/docs/reference/lamb...