https://kotlinlang.org logo
Join Slack
Powered by
<https://medium.com/@cedricbeust/what-rust-could-l...
# feed
c
h
The 
/r/programmer
Link in the update at the end is the same as the 
/r/rust
link.
c
Oops, thanks @hho! Fixed.
s
I enjoyed this article and am looking forward to the reverse article on what Kotlin can learn from Rust as well.
m
Thx for the article...and as most others I look forward to part II. However there is one crucial thing I missed in the article - Testing - since in terms of comfort and techniques there is a huge gap between Rust and Kotlin in my experience.
c
Would love to hear your thoughts on testing, @Matthias Geisler. It's not in my list right now but I won't share more thoughts right now so I don't influence you 🙂
There is one more thing that just occurred to me that I would have liked to include in that part one, it's the lack of 
apply
. I can't see
Copy code
foo.a()
foo.b()
foo.c = 3
without cringing. Kotlin really nailed that one.
One of my early remarks right now is that the list for part 2 is twice as long, which means that it looks like Kotlin can learn more from Rust than the other way around, but I actually feel the opposite. There are fewer items on that first list, but they significantly impact my happiness coding in Rust, while that doesn't happen much in Kotlin
m
Frist of all I think, I should mentioned that Testing in Rust is a build in, which is mentally a huge thing in my mind and I really appreciate that. For Kotlin it is a bit different, since it comes with the build tool you use (in my case Gradle, so this is my point of comparison mostly). What I also appreciate in Rust is how closely related test code is to the actual productive code. Also this nice little feature that it runs code snippets of your docs. Now the but - what really alienates me is the fact that you place tests in the very same file where the productive code is or at least you need to make some weird stuff to extract those. Kotlin&Gradle work here much better since it helps quite a lot to keep your codebase clean&readable and well structured. 2nd thing which was kind of weird - testing of private function like you see it in the rust docs. 3rd mocking - if you not go pure functional style in Rust it is in my eyes super hard and painful to mock/fake/stub things, since it couples structs with function, without having a proper definitions of interfaces. You will probably say now: Wait, but there are traits, right? - Here is the thing you can treat them as interfaces, but I know some Rust developers, which will say Traits should be "abused" as Interfaces and there should be no Trait, when it is implemented only once. So these conversations turn out to be super tiresome even if the Rust blog states otherwise. Without utilising Traits you actually need to trade separation of concern with isolation of units (you effectively taint your production code with test concerns). This is in my eyes super bad. However even this is not a complete list, which with unpleasant surprises in Rust...you can work around most things in a way, which of course adds a significant amount of boilerplate. But to focus on the bright side...Rust is constantly improving over time, so those things might too. Also Rust has awesome features like its Preprocessing, which is super cool and I would love to see something comparable for Kotlin.
Summa summarum - I believe there is a bright future for both languages...and even brighter if you combine them, like the Signal App does it and beyond!
c
Both languages certainly have a very bright future ahead of them, and both of them are here to stay. Which doesn't mean they can't learn from each other, and I hope that my article (and the upcoming one) will help improve both languages to a point where they are both developers' favorites, which means that whenever a developer is being asked to implement a certain project, both Rust and Kotlin are valid options and it's up to them to pick which one they like best.
m
I totally agree
3 Views
Open in Slack
PreviousNext
Powered by