Recently had to go back to an older Android codebase, and immediately decided I had to start converting.
The amount of boilerplate is unbelievable. I'm able to cut the number of lines by half while increasing readability. Type/null safety is a huge added bonus
P.S. Kotlin extensions are the best
Jetpack Composer is the latest example of such, finally is ConstraintLayout and the GUI editor gettting usable, they reboot the whole thing ('cause Flutter) without even having an idea how to support ConstraintLayout and MotionLayout with Jetpack Composer based UI tooling.
Anyway, nowadays you wouldn't see me making the same statements anymore.
My first issue appeared when I was maintaining an Android app written in Java. I needed an library for some functionality. The only maintained ones were kotlin-libs. But interoperability, right? I didn't hesitated to include it. There is no way to use or extend functionality with typealiases in your java code.
IntelliJ can compile Kotlin into Java and it is easily accessible. But there is no adb debugger for kotlin.
Null Safety is just overhead imho. I know when it is appropriate or neccessary to check for null, otherwise i can get rid of it. And its more easily grep-pable the Java way.
Writing Kotlin is not so fluent as one would guess, the tooling only fools you, that it is. You can easily make use of actions like typing pfi (extends to public final int) for java aswell. But when your property changes from nullsafe to nullable, you need to rewrtiging eeevverything.
Additionally, i do not like the implicit type on member property declarations used by almost anybody. The benefit of typing less boilerplate becomes annoying when reading sources outside your ide.
Boilerplate in my opinion is code i need to write by myself. When it is generated by any IDE, i do not bother about it. We are so familiar with Java that we can abstract this boilerplate when reading sources.
Spelling Kotlin to somebody via telephone is also strange for me.
I stopped promoting Kotlin as a Java killer. Code style is too different between different developers.
And why are we creating the same libraries once again?
Isn't the fact that you have to be explicit about null the main feature of explicit null safety?
Without null safety that could be quite tricky, especially when combined with type inference. The value could be stored and used only later, for instance. The compiler flagging where those fields are used without a null check is convenient, it tells you exactly where to insert new code to handle the missing data.
Anyway, you are absolutely right and I am glad @jach posted an link (above) regarding my intuition (@shoutout). When I learned programming (with Java, 3 yrs. ago) my mentor pointed out that i included too null-checks, even though i was familiar with the entire code base. Just after reading a post on this platform I realized his real intention: Sometimes (most often!) we needlessy check for null. Since then, forcing me to check anytime for null feels wrong and kotlin is forcing me to do so.
Eventually I just wanted to mention downsizes which comes into my way when using kotlin daily..
Thankfully..!
I don't have a hard stance on that, but I can see where he's coming from. My day job is all Java, and while we do occasionally have to deal with NPEs, they're just NPEs, not segfaults or things that can take down the whole program. They get caught and logged in a thread while the rest of the (server) app marches on. Programmatically, using Optional to signal intention of null as meaningful (and it is sometimes useful to have null as a meaningful "don't know" value, see http://john.freml.in/billion-dollar-mistake) works well and isn't syntactically laborious. (Additionally Optional chaining with maps is much nicer than the old way of nested if-not-null checks, but sure a "?." operator or similar would be slightly nicer.)
Common Lisp complects nil and false and the empty list '(), which originally annoyed me quite a bit, but after working with it more I see it as deeply pragmatic and it simplifies a lot of code while also making many types of annoying errors in other null-supporting languages either not relevant or much more trivial to fix. Additionally its OOP system has a function-call syntax of (method obj arg) instead of something like obj.method(arg) so in error logs you'll see "no applicable method for the generic function #method when called with arguments (nil arg)" (and in development you have the excellent condition system to resolve this without unwinding the stack and losing state, including the choice to define a method that explicitly handles a null object). But I don't see the programming language fashions moving any closer in that direction...
Anyone who thinks they can do better than a compiler for code safety is probably very new to this profession.
But there are times where you can be sure that the nullable object is not null. You got the double-exclamation-point (!!) for this. But some calls to Android-facilities doesnt accept this, so the IDE notifies you about an var, which could have changed at this point in time. Resulting in multiple !! in the same scope of function.
Same with vars, they are still needed every now and then but most of a clean codebase is hopefully vals and immutable data classes.
I found that despite Java's plainness ... it's robust and I don't worry about 'how fast I can express myself' I'm more concerned about readability and Java is still ok there.
> I'm able to cut the number of lines by half while increasing readability.
What I've seen from kotlin code on the web is that sometimes code is so terse that it's too hard to understand, but it's probably because of not being accustomed to kotlin yet (I've written so convoluted erlang list comprehensions that I'm still ashamed, but those can squeeze 10 lines of java into one erlang line).
The goal (and the opportunity) is to make your code very declarative.
view.removeSelf()
ViewGroup parent = (ViewGroup) view.getParent();
parent.removeChild(view);
If the library is open source, you can of course try to contribute changes, but they may or may not be accepted, and maybe the library is in such wide use that they don't want to break backward compatibility.
In any language it is possible to fix broken libraries.
removeSelf(view)