Comment by jillesvangurp | Hacker News Reader

Comment by jillesvangurp | Hacker News Reader

Parent Full thread

Java did improve over the years. But it still defaults to doing basically everything wrong by default. Parameters are non final, classes are open, things are mutable, etc. It's unsafe by default. And it's hard to fix because it breaks backwards compatibility. Kotlin doesn't have that problem and it has been doing the right thing by default for a long time. It's still getting better.

I think on Android the choices are either to start from scratch or to migrate to Kotlin for Facebook. Sticking with Java on Android just makes everything harder. All the new frameworks are Kotlin centric. Most Android developers they'd be hiring would have been using Kotlin for years. Etc. So, I can see why Facebook is making the effort to keep their code base alive and future proof. Android is more Kotlin focused and has been for years. And that's only going to be more the case now that compose multi platform is a thing.

Btw, most of the stuff you mention is probably more applicable to server side Java and less to Android. IMHO, Spring + Kotlin is a very nice combo on servers. Very well supported by Spring and they bundle a lot of convenient things for Kotlin. And I don't need any of the tools you mention because it does the right thing by default.

> And I don't need any of the tools you mention because it does the right thing by default.

I mostly agree with you, but Spring+Kotlin does require the allopen plugin, so it's kind of hacking Kotlin to do the wrong thing (all classes open) in order to support an arguably bad design choice by Spring.

Can't blame Kotlin for that. And it's a very minor sin frankly.. set-and-forget.

I don't blame Kotlin for it, I blame Spring for it.

all-open plug-in is the only sane way to operate Kotlin.

A whole lot of pie in the sky architects, which seems to be all of Kotlin authors and all of Kotlin-writing cadets, sure love to dream that closed by default is a good design choice and think of times when something open was extended or accessed that wasn’t actually consciously fore-thought of the intended points of extension. But they conveniently ignore the costs of these shackles to their business and agility, and I argue that the costs are far greater than the benefits, especially for non-library code. We just spent a couple of decades fighting the waterfall delusion of big design up front. Yet closed-by-default takes us back to the Stone Age that ignores the reality that there’s no way that the original code authors could’ve thought of all legitimate/sensible uses ahead of time. But good engineers tend to decompose code into smaller classes and functions, which often have a pretty good chance of being extended rather safely in practice.

It is wild but such is the consequence of the culture that punishes explicit failure, and ignores failure to be able to ship fixes for the unpredicted situation and ignores failure to have a productive code base. I cry for the mounds of copy-pasted code that must result from this policy that treats its engineers code like radioactive garbage.

Exception: final parameters. They should never be assignable.

Yeah, I disagree. Inheritance is the wrong tool for the job 99% of the time anyway.

Reply on news.ycombinator.com