Hacker News Reader

Comment by rcaught | Hacker News Reader

I struggle to see how you pick Java over Kotlin on the JVM these days. It's everything that Java is, minus everything Java shouldn't be, plus everything that Java should be.

View on HN

Syntactic sugar does not solve programming problems. Kotlin does not offer any paradigm changes which could make switch worth it.

The only Kotlin feature that it's really hard to live without is properties. Otherwise sure, it's better than Java 11, but I can live without all those niceties. And (non)nullable types even get in my way!

I just don't understand where there's syntax sugar for propeties in Java. There are lot of unneeded stuff added, that I don't really care about. But my classes are still full of autogenerated getters/setters. I recently tried to find some JEP and I did not find one. There was some talk around Java 7, but nothing since that. Nobody even wants to add properties support for Java?

And (non)nullable types even get in my way!

Interesting how that goes...: the sibling comment to yours said the exact opposite. How does this feature get in your way?

1. Language problem:

    if (this.prop != null) {
        this.prop.something() // does not work
    }

this construction works for local variables, but not for properties. Yeah, theoretically it could be modified by another thread or function in the middle. In practice it does not happen and I'm forced to use terrible code like

    this.prop?.apply { prop ->
        prop.something()
    }

(this example could be written as this.prop?.something() but that's not the point, usually it's harder than that.

2. Interoperation problem. A lot of Java code does not use @Nullable annotations, so all types are just that: platform types. So Kotlin nullability adds nothing to that.

What is uglier about the kotlin code? It's the same number of lines and the code is more robust. What's the ugly part?

Using library functions instead of language keywords feels very wrong to me.

Why?

Probably because in general they are a code smell. They are anti-OO.

That's just not true. If I'm writing simplest REST service, I have to return JSON responses. To return JSON response, I have to write class corresponding to that response. And that will be data class. If I'm interacting with database, I'm writing data mapping classes. And that will be data class. Those are normal code that every developer writes every day. If you think that it's anti-OO, then I don't care about that OO. I care about writing performant, concise and extensible software.

That statement is valid in both contexts you mention. You do not need properties for data mapping and serialization - it’s possible to write a good OO code without getters and setters.

If a useful feature is incompatible with OO, it's a problem with OO, not with the feature. Properties allow one to work with plain old data (not everything is meaningfully an object with behavior) without freezing the underlying implementation forever. Fewer (or maybe more decentralized) religious arguments like this is one of the few things I like about my job in C++. (Shame C++ doesn't have properties, these would come in handy in refactoring config handling code that I currently work on, but on the other hand the last thing C++ needs is yet another feature hidden under common syntax that may blow up allocations and runtime unexpectedly).

EDIT: to clarify: for example, I consider std::optional as an example of a very "un-OO" type that's immensely useful. In general I like the idea from functional programming that complex types can be treated no different than primitives, rather than the OO way of wrapping and uplifting everything until even integers have methods.

There’s only one case where properties may be useful - GUI forms mapped to domain-like model. In practically any other case it’s violation of one or more OO design principles. In Java you can live without them with a life full of joy.

You kind of answered your own question: auto-generated getters/setters. Having a tolerable Java experience is so dependent on huge IDEs and other huge frameworks that people overlook language issues.

Kotlin's null safety alone is enough to prove you wrong here.

I find the whole discussion about null safety completely negligible.

Since when are nulls the biggest problem for developers? Null pointer exceptions are by far some the simplest problems to avoid and/or solve.

There are more serious arguments that can be made in favor of Kotlin.

Where was it suggested that nulls are the biggest problem for developers?

But they are a problem that happens, and in Kotlin, the compiler checks your nullable logic for you; instead of your users finding the errors at runtime.

It just a way to conceal bad coding practices, which doesn’t prevent from having the same problem in a different form, just like GC in JVM cannot protect from all memory leaks. I can hardly remember a case when NPE was reported by some user in my projects.

It was suggested that that feature is relevant enough to justify using kotlin over Java. However, I'd (and others in this very thread also have) argue that only slightly tips the scales towards Kotlin, while not solving the problem they were actually trying to solve here: reduce the barrier for contributing.

https://duckduckgo.com/?q=billion+dollar+mistake

Here here. I’ve heard “but null pointer errors!” countless times to justify one’s coding approaches (eg, strong typing, Maybe/Optional invasion, this or that PL, ...)

People will murder all kinds of productivity to avoid potential NPEs, when as you say they are generally the easiest bugs in the world to contend with.

It is beyond baffling to me, and given how often I hear it, it makes me question the dev world’s sanity.

Lately I’ve seen code bases where the Java devs don’t return empty arrays or collections but return null instead. Of course they have to test for null in their calling code. I suggested to return empty collections and objects implementing the NullObject pattern. I think this will make the code more readable, simpler and more secure, but I was answered with skepticism.

Interestingly I agree w/ a preference for empty semantics over null semantics, but NOT for the reason "avoid NPE". Rather, I think minimizing branching/forking in the code logic is how complexity is reduced.

For this same reason I don't care for NullObject/Maybe/Optional type approaches which simply do not change the branching forking in your code:

   if (val == null) { ...logic... }

This branching here ^ is not improved at all by a different syntactical representation:

   ((Optional) val).ifNull(v -> ...logic...)

You are still branching, so in my opinion you've made no substantial improvement here. (I can already hear the "but, but..."s.

I'm dealing with an old code base in which methods tend to process exceptions by catching, logging and returning a null. The dev that wrote this code treated exceptions more like a rare-occurring annoyance rather than a signal for error, thus none of the calling methods had null check branching implemented. The amount of NPEs I had to fix in the past year is astounding.

Optional to me is a large leap forward. That being said, I also don't like its verbosity and wish for it to be improved somehow.

Advocating programming constructs as a kind of ‘policing’ against bad developers doesn’t work for me.

It usually ends up at odds with better objectives & heavily taxes conscientious developers, for whom we should really be optimizing things imo.

You can easily get it on Java with PMD and other static checkers.

If you care about null safety, why not just use Scala? I've programmed Scala professionally for a long time and have never ever experienced a null pointer exception.

Correct null handling genuinely helps you write better, more correct, less bugged code.

It's not just syntax sugar.

Instal PMD and you are set.

They want to use a language that has a large pool of interchangeable "x years of experience in language y" labour available.

As someone that uses both languages, I can't help but think that the OpenJDK will (hopefully) start implementing much of the Kotlin paradigms. Perhaps at some point Java & Kotlin would not differ too much. Let's see what the 6-month release cycle brings. That remains to be seen.

I guess you mean Java here, and yes some of them have a JEP defined.

It's the lowest common denominator. It's the same reason I haven't been able to adopt Kotlin at work. Everyone acknowledges it would be better, but "everyone knows Java". Seems almost like "nobody ever got fired for buying IBM" to me.

... or, worse, "everyone here uses Java <= 8".

Except there is no need to do. They already biased for maturity and long term maintainability. I don't think Kotlin is bad per say, but it feels untterly unnecessary.

Because until JVM turns into KVM, Kotlin is just another guest language on the JVM, without much to add as a company pushing their agenda and trying to use the JVM as a lever.

KVM might well turn out to be ART, but that is the extent of it.

As someone who just started using Kotlin again, I'm curious what you mean by "agenda". A typical company trying to make products for money, or something else?

Yes, Kotlin as gateway drug into JetBrains products.

For example, the graphical debugger for Kotlin/Native is only available in Clion.

There is even a statement in that regard.

Reply on news.ycombinator.com