Hacker News Reader

Hacker News

Comment by melling | Hacker News Reader

Full thread

melling

“Shorter code: Kotlin’s modern design makes its code shorter.”

How much shorter? How large would the code be in pure Java?

View on HN

We actually made this number public in the post. It just appears laters around the conclusions sections.

> On average, we’ve seen a reduction of 11 percent in the number of lines of code from this migration.

I was hoping for more but 11% is still significant.

So that’s an extra million lines of code that didn’t need to be debugged.

I wonder how much of this could be reduced if they used records in Java.

An extra million lines of {, @NotNull, .stream(), .toList().

Hardly any code that would actually have bugs.

We have a consistent braces style, so the lines that are removed are rarely those.

A lot of the saves come from `?.` replacing null check chains. Many more from the shorter constructor and field initialization syntax (you can get a bunch of things in one short statement). A bunch more from usage of standard library lambda taking functions (`first`, `single`, etc.). Some more just comes from shorter lines due to less explicit types. These are all more some guesses due to conversions I've seen, and not the result of accurate analysis.

We also use very little Java streams. A combination of Java 8 arriving late to Android code, and the preference to avoid extra allocations and inefficiencies streams can cause for shorter lists.

There's also the line length to consider.

I've seen the same on my own converted Java code. Less lines of code. But you also get lots of a really short lines. And some formatting actually spreads things out over multiple lines for readability. E.g. I use intellij's build in "put arguments on separate lines" a lot. Especially with named arguments, this is just nicer to look at. It's the same or less code but more lines. But less dense code.

A more interesting metric might be simply the byte size of the source files. I would expect that to be slightly better than 11percent. Maybe closer to 20-25%.

A nice, simple kotlin left-to-right access deep into a nullable nested object tree can quickly be four lines of java for each and every ´?.something´, for as many of them as fit into your preferred line width. In java, this often leads to either skipping more null checks than you really want to skip, or calling getters more often than necessary.

Kotlin might seem a little weak to someone returning from a scala deep dive, but where it really shines is in creating a large overlay between the convenient path and the pedantic path. It removes many "in the small" tradeoffs that you just take as a given in java. It's the "better java" that groovy was not.

> Kotlin might seem a little weak to someone returning from a scala deep dive

I dismissed Kotlin for this very reason years ago. But after seeing bad Scala codebases, Kotlin feels like a breath of fresh air.

If you have more than 2 levels of nested null-checks I would wager you are doing something fishy. You should probably go with mapstruct or similar libs (which are absolutely cool and a must for data conversions).

On my fishy scale, requiring translation between different data models would by pretty high up. And how would it help anyways? Absence can be a perfectly valid state and alternative representations of absence like scala's Option seem pointlessly ceremonous once you've worked with a syntax that does not completely suck at dealing with null.

They should switch to Perl and replace 80% of the code with punctuation

Expect a 10-30% reduction with J2K, maybe another 5% once manual refactorings are made.

What’s pure Java?

Reply on news.ycombinator.com