I don't know about rust but I think kotlin is better in terms of development experience and most of the time kotlin code is concise and shorter than java code.
Conciseness per se is pointless. Development productivity is only thing that matter when comparing Kotlin and Java. And Kotlin often is worse than Java in this regard. At least for backend development.
Do you have personal experience with this? I wonder if this will change with time as people adapt to using the language more. In my area, Kotlin jobs or even projects are still very rare unfortunately, so please elaborate.
This might change over the time, but odds are low since some issues are inherent to Kotlin as a language. Here is my answer on similar question with more details and my personal experience.
I should note, that many Java issues, which make people consider Kotlin, can be solved by adopting Pragmatic Functional Java in combination with Java 11 and up (especially Java 17).
Yes, but Kotlin was designed with this exact mentality. Java plus some features, minus some annoyances, basically.
While I assume that you can do most things in Rust, it is primarily a speed and memory safety focused language. Without garbage collection, I might add. That does not make Rust bad, obviously, but I genuinely don't see the point of this article.
Yes, but that comes with additional complexity. Which is not a bad thing, as I said. We could say that Java does not have an ownership model because it's garbage collected nature does not need it.
It's just a different approach that demands different things from the programmer.
I think the most important part of Rust is that its ownership model also allows thread safety without manually synchronizing access to shared memory. Java cannot do that even in theory.
It may be worth distinguishing between missing, which in context you seem to be using along the lines of 'not built in to the language or std library', and unavailable, which I would describe as a feature not being accessible at all when using the language in question.
Rust doesn't supply garbage collection in std, but if you have a specific case where you need it there are crates like gc that implement a specific form of it. Rust also doesn't supply async/await, but you can add Tokio or async-std and have that feature available if you need it. Both examples of Rust's preference for paying only for what you use and their specific approach to what is and is not included in the std library.
Java has a different approach, as far as I know.
Re the original article, talking about language replacement without talking about what the tool is being used for seems a little misguided. It's sort of the blog equivalent of making a technical decision without knowing any of the actual project constraints. Real world examples of switching to Rust (eg Discord switching certain services from Go to Rust) are specific to the use case, not just blanket 'rewrite all the things in Rust'.
Yes, and likely it's won't be much longer before Java 17 is supported. Spring is likely to take a year before going to 17. If it's not possible by then, it's going to be a major deal breaker. Originally people used Kotlin mostly because they were stuck on also JVM's with Android. Kotlin also has other compile targets, like native and js. But I think they are still used very little.
Despite all the differences between the two languages, Java and Kotlin are 100% interoperable. You can call Kotlin code from Java, and you can call Java code from Kotlin.
Not 100%, you can't call a coroutine from Java, and you can't use Java Code that contains records for the moment. But yes, it all runs on the JVM, as does Scala, Groovy and Clojure, which you could use all together in one app.
I don't know about rust but I think kotlin is better in terms of development experience and most of the time kotlin code is concise and shorter than java code.
Conciseness per se is pointless. Development productivity is only thing that matter when comparing Kotlin and Java. And Kotlin often is worse than Java in this regard. At least for backend development.
Do you have personal experience with this? I wonder if this will change with time as people adapt to using the language more. In my area, Kotlin jobs or even projects are still very rare unfortunately, so please elaborate.
This might change over the time, but odds are low since some issues are inherent to Kotlin as a language. Here is my answer on similar question with more details and my personal experience.
I should note, that many Java issues, which make people consider Kotlin, can be solved by adopting Pragmatic Functional Java in combination with Java 11 and up (especially Java 17).
Yes, but Kotlin was designed with this exact mentality. Java plus some features, minus some annoyances, basically.
While I assume that you can do most things in Rust, it is primarily a speed and memory safety focused language. Without garbage collection, I might add. That does not make Rust bad, obviously, but I genuinely don't see the point of this article.
Rust doesn't have garbage collection because it's memory model doest need it.
Yes, but that comes with additional complexity. Which is not a bad thing, as I said. We could say that Java does not have an ownership model because it's garbage collected nature does not need it.
It's just a different approach that demands different things from the programmer.
I think the most important part of Rust is that its ownership model also allows thread safety without manually synchronizing access to shared memory. Java cannot do that even in theory.
Yeah, I just got your comment "Without garbage collection" as if that's a feature missing from Rust.
In a very literal sense it is missing from Rust, but yeah, could have phrased it better.
It may be worth distinguishing between missing, which in context you seem to be using along the lines of 'not built in to the language or std library', and unavailable, which I would describe as a feature not being accessible at all when using the language in question.
Rust doesn't supply garbage collection in std, but if you have a specific case where you need it there are crates like gc that implement a specific form of it. Rust also doesn't supply async/await, but you can add Tokio or async-std and have that feature available if you need it. Both examples of Rust's preference for paying only for what you use and their specific approach to what is and is not included in the std library.
Java has a different approach, as far as I know.
Re the original article, talking about language replacement without talking about what the tool is being used for seems a little misguided. It's sort of the blog equivalent of making a technical decision without knowing any of the actual project constraints. Real world examples of switching to Rust (eg Discord switching certain services from Go to Rust) are specific to the use case, not just blanket 'rewrite all the things in Rust'.
Great info, thanks!
And adding some other annoyances, like not being able to use Java 17 together with Kotlin at the moment.
Right.
I was actually wondering about that. Is Kotlin supposed to be compatible with Java in the future as well? If not, major RIP.
True.
Yes, and likely it's won't be much longer before Java 17 is supported. Spring is likely to take a year before going to 17. If it's not possible by then, it's going to be a major deal breaker. Originally people used Kotlin mostly because they were stuck on also JVM's with Android. Kotlin also has other compile targets, like native and js. But I think they are still used very little.
Despite all the differences between the two languages, Java and Kotlin are 100% interoperable. You can call Kotlin code from Java, and you can call Java code from Kotlin.
Not 100%, you can't call a coroutine from Java, and you can't use Java Code that contains records for the moment. But yes, it all runs on the JVM, as does Scala, Groovy and Clojure, which you could use all together in one app.
Seems you can use Java records with Kotlin (and even define them in Kotlin)
kotlinlang.org/docs/jvm-records.ht...