Hacker News Reader

Comment by dr_faustus | Hacker News Reader

I'm currently working on a project which has both Java and Kotlin and I really have to say that I like working on the Java parts much better than on the Kotlin parts. I find coroutines a really strange and leaky abstraction (and the prevalence of suspend methods in libraries which you have to wrap all the time just to call them synchronously is really annoying).

With streams and the var keyword, Java is also not that much more verbose anymore than Kotlin and the code completion, error detection and refactoring capabilities are much better in Java. In Java I can also be sure that if I directly access a property on a class, there will be no side effects or expensive operation while if I use a getter, there might (and I dont have to write them either due to code generation or Lombok). So the parts where Java is still more verbose actually add clarity (and again, due to the IDE, you rarely have to type any of it): I dont really get why I would leave out the explicit types in the source code, only to be added again as non-editable, weirdly positioned text by the IDE (which is not there if just wanna have a quick look at the code on GitHub).

View on HN

Sure, but the one thing Kotlin has that makes me never look back is null-safety. Java has optional and non-null annotations and whatnot, but you have to be vigilant and put the right annotations everywhere. Kotlin you get this for free.

The extra sugar on top is super nice too - listOf, mapOf, x to y, apply… I think it just makes code that much cleaner. None of these are make or breaks but together they work amazing. A lot of what I work on professionally is still on Java 8 or 11 so I don’t get any of the cool features like record types.

Most of the OSS I do is Kotlin bedsheets I just enjoy writing Kotlin. I don’t feel that way with the older versions of Java (I’m starting to with the newer ones).

While I also love many things about Kotlin, the one thing that always sticks out like a sour thumb is error handling.

While Javas checked exceptions had a lot of problems, at least there was a way to declare the output (errors are ouput) of a function on a type system level.

With Kotlin, that's just gone. You can fiddle with Result type (or make your own), but you lose a lot of the ease of "bubbling up" errors.

How do you handle errors? (I wished Kotlin had error handling like Rust, which is the best that exists, imho)

You might like Scala (possibly enhanced by something like Monadless or Each , but personally I find the explicit for/yield approach very worthwhile).

How does this work in a SOA situation? Like do you have null checks + default values at every HTTP boundary for your application?

Most frameworks give 400 bad inputs. If the client gives a null but null is not allowed in the type, it will auto respond with 400 before it ever invoked the handler.

Java spring does the same thing: if you use an unboxed type (int instead of Integer) and the client passes in null, the handler will never be invoked.

But if you have an evolving API, you are back to what was asked. Either you are a bit of a jerk to all of your existing clients, or you have default values at the boundary.

I've found myself with this a lot on "progress" data classes where I will be building up a set of data over several expensive calls. I /could/ make a new type per current state of that, such that I never have nulls. I /could/ make it so that every field is Optional. Or, I could work on a convention that fields are filled out in order, and after the first null, nothing is available. In many years, this has not been where null pointers hit me.

To add to this I had a specific scenario in mind. At @current_job they bolted on a immutable struct library and wrote validations. We are responsible for sending out renewal notices and we get the renewal price from another system. In certain scenarios we were getting back a null price and our validations dutifully caught the null and threw an exception.

Theoretically everything worked. However, the end result is (1) the customer didn't get their renewal notice and (2) we got a validation error instead of (maybe) a NPE somewhere. So what exactly are we accomplishing here is my broader point.

To be honest, this is more of a question about how best to handle errors in asynchronous event handlers (not handlers marked as async, I mean like send an email at xyz time). Imo best way to solve this is to get notified of an error in sentry, be it an NPE or validation error.

In a case where the client expects an immediate response (http GET) getting “400 validation error: foo is not allowed to be null” is a lot more meaningful than “500 Null pointer”.

In general I try not to model invalid states - less mental overhead (no one has to tell you xyz can’t be null it just cannot be null).

Ofc this is a matter of opinion and the lines get blurred as soon ad you move stuff to runtime.

I believe the standard practice (as popularized by Google) is that all fields are optional. This allows you to deprecate fields in the future while still support older (non-updated) clients.

Yeah, my question is more about what you do as a consumer. How do you get back null safety if every field in the response is optional? Even moreso, in a SOA situation where 90% of what you work with comes across a HTTP boundary.

I'm not sure I understand the question. If you have only Optionals and Null does not exist, a NPE is impossible. The Optional type forces you to handle the empty case, so null safety is enforced by the type system.

The question is how do you handle the empty case for the hundreds of fields you pull from other systems.

You handle it how you would have handled fixing a NPE which shows up in production. Except now you handle it before an NPE ever shows up because the type system forces you to.

I think coroutines is probably the best implementation of cooperative multitasking (async/await) that is is available in any language: They build on structured concurrency and thereby allow to prevent a few common concurrency problems like runaway tasks. You can run them on different threading systems, like UI threads, threadpools, etc. And they default to run the continuation on the correct thread.

However as any async/await implementation it will obviously still have challenges. The "colored" world of functions means users need to know the differences between suspend functions and other functions, and using something wrong can lead to performance issues.

One thing to note is that with the upcoming of virtual threads (Project Loom) in Java itself, the need for using coroutines might become much smaller. You might just end up using them for UI work, and everything else could use virtual threads. That could simplify a lot of things.

Loom will just slot into co-routines without requiring many (if any) code changes. It's still going to be nicer to use co-routines from an API point of view and they'll just use the loom stuff underneath pretty much transparently when it is available. A virtual thread is basically just yet another thing that you can wrap with a co-routine. There are many such things across the jvm, js, and ios-native platforms that are supported via Kotlin already.

And since it is API compatible with things that are already supported by co-routines, pretty much all you need to do is change your custom co-routine contexts to be backed by virtual threads rather than actual threads. This should just work even without explicit support for this in the co-routines library (it's just another thread pool). But they obviously will add explicit Loom support as well as it makes sense to make co-routines be virtual threads pretty much always.

When that ships, all current kotlin code that uses co-routines will be using virtual thread on a Loom capable jvm. It already has structured concurrency and all the rest so all of that will continue to work. And some of the blocking Java stuff that you currently need thread backed co-routine contexts for, will stop being blocking so you can stop doing that. But it will still work of course.

I guess you could "slot loom into co-routines", but the niceness of loom is that you don't even have to use coroutines. It could just be regular "blocking" Kotlin functions which run on virtual threads.

If you already use Kotlin coroutines - fine to continue to use them. But I imagine for a new project you might want to opt to build on virtual threads instead of coroutines.

> With streams and the var keyword, Java is also not that much more verbose anymore than Kotlin

I have no experience with Kotlin yet, but I recently did some Java after years of js/ts, and was nearly driven mad by constantly having to convert different kinds of collection. String[], Array, List, Iterable, Stream... and every library expects or returns something else, so you're constantly converting these things.

Any of them would have been perfect if only it had been supported by everything, but because of Java's long history of constantly inventing newer and better ways of doing things, libraries written at different times support different kinds of collections and you constantly have to convert them.

I agree to some extent, however, IDEA often helps you with that (e.g. by converting arrays with Arrays.asList(array)). And I have to disagree: Any of them would not have been perfect. An array is sometimes significantly more performant and requires less memory than a list.

In the different collections, you see a history of 20 years of developer experience improvements coupled with an almost religious emphasis on backwards compatibility in the language and standard library.

In every (long term) JS/TS project I worked on, about 20% - 50% of the development time went into upgrading libraries and keeping everything running on the current node version. It was maddening. Stuff like the different types of collections are a very small price to pay, IMHO, if you can be sure that your current Java project will with very high probability also run on a current JVM 10 years from now.

> Any of them would not have been perfect. An array is sometimes significantly more performant and requires less memory than a list.

That's actually why I prefer List, because a List is an interface and can be an ArrayList or another type of List and I don't care about the implementation, as long as it's a List. But Array is an array that's not a List, and Iterable is also an interface, and I think a List is also an Iterable, but I'm not sure, and I suspect not every Iterable is a List. And then there's Stream which should have been a set of convenient functions that are part of List or Iterable right from the start, but they're not. And what the hell is a Spliterator and why do I need one to turn an Iterator into a Stream?

I understand that there are reasons for this, and I totally agree that the js/ts dependency situation is far from ideal, but it's still maddening to have so many different collection types, when js/ts just has an array that's not even an actual array, but it still works fine, and all the new stuff just gets added on top of it.

One of these days someone should invent a new programming language that finally gets all of this right once and for all, but I bet people will find ways to improve it again.

> I understand that there are reasons for this, and I totally agree that the js/ts dependency situation is far from ideal, but it's still maddening to have so many different collection types, when js/ts just has an array that's not even an actual array, but it still works fine, and all the new stuff just gets added on top of it.

It "works fine" for basic cases but it doesn't give you anything like the same capabilities. JS/TS have no easy equivalent of array or stream, anything you could write in js/ts you could write in Java by only using ArrayList. Java's collections library is big and complex but almost everything that's in there is there because it has a use case, and while it's showing its age now it was well designed for its time.

> One of these days someone should invent a new programming language that finally gets all of this right once and for all, but I bet people will find ways to improve it again.

Your best hope is a language with Haskell-style typeclasses where you can not only add new implementations of existing interfaces, but also retrofit new interfaces onto existing implementations. No library is going to be perfect from day 1, and a big part of the reason why Java Stream is awkward is that it had to be retrofitted into the existing collection library.

I'm curious what libraries you are dealing with that are so opinionated on what collection type you send to them? In my years of working with Java, I think I see List. And... yeah List. That is about it.

I have had some internal teams try to use Iterable or arrays, thinking they needed to be optimized. Almost without fail, those are from teams that stall out and never actually finished what they were doing.

I have seen case studies of giants that actually needed to optimize down to arrays or buffers, but this is often not the case. I'd imagine unless you are trading or gaming, you can get more than enough mileage out of List. (Specifically ArrayList. LinkedList is usually a sign of premature optimization without having actually benchmarked what was running.)

In your own code you should always use one of collection classes, usually Iterable, Collection or List, depending on which features you need.

Stream usually is not used other than for call chains. Like list.stream().map(...).toList();

I write Java for many years and I can't really say that this was source of pain for me. I agree that streams could be implemented with better ergonomics, but Java designers wanted to provide us means to use parallel computations with one extra word, so here we are. I've yet to find a place where I'd want to use that.

I used collection classes in Java 1.4 and I'm using them in Java 19 and I don't think that anything changed in that regard. Collections are the same.

> In your own code you should always use one of collection classes, usually Iterable, Collection or List, depending on which features you need.

Yes, but every library I use requires or returns a different one.

> list.stream().map(...).toList()

But why not list.map(...)?

In this specific case I think it is because stream operations can be implemented lazily - they only run once you call toList()

This sounds like you are trying to shoehorn asynchronous kotlin code into synchronous Java code. Which would be doing it wrong. The problem is trying to make asynchronous code synchronous: don't do that. The whole point of asynchronous is to do it end to end and isolate the remaining synchronous bits and pieces that you have on separate threads so they don't end up blocking all the asynchronous bits and pieces that you have.

Use a proper asynchronous framework and then the only thing you need to worry about is avoiding calling synchronous code on your main thread (i.e. dispatch it to some thread pool backed co-routine context). Not that hard. And you can get rid of a lot of that stuff by gradually switching to non blocking versions of whatever you are using.

If you are exposing class properties without accessors in Java, that's not necessarily a great thing. Especially if your state is non final (i.e. mutable). In Kotlin, you'd use vals (or vars if you really have to) and by default they just behave like they have getters/setters. But you don't have to spell it out. And you can override the getters and setters. Just like you would in Java. It's just the distinction is not there. It's basically a less hacky Lombok.

The weirdly positioned text that your IDE adds are called hints and you can turn them on or off as you please. They are there to help you. Type inference is a nice thing: it means you can read the hints without having to spell out what is what. Java has type inference too but it's a bit more limited and more verbose. There is no uncertainty about what the type of anything is in either language: exactly what you specified (but just once in Kotlin's case).

> I find coroutines a really strange and leaky abstraction.

I've only used Kotlin on Android, but from what I remember co-routines are not necessary to use. If you don't like them, then don't use them.

Kotlin has a number of advantages over Java. The biggest of which is built-in optional typing. It's also really nice that everything is expression instead of a statement. Library functions like `let` also make code a little nicer to write. And stuff like data classes and better property initialization are icing on the cake. In my opinion, you can write Kotlin exactly as you would Java, but the development experience is much more polished.

> built-in optional typing

Typing is not optional, everything in Kotlin is typed. What the language has is type inference. The following lines have the exactly same types:

  val teens = people.filter { it.age < 20 }.map { it.name }
  val teens: List<String> = people.filter { p: Person -> p.age < 20 }.map { p: Person -> p.name }

Just for comparison’s sake, java is not significantly more verbose.

  final var teens = people.stream().filter(p -> p.age < 20).map(People::name).toList()

Keep in mind, you can use Kotlin in any JDK8 project and instantly get all those features. What you're proposing requires upgrading to a new JDK.

Upgrading to a new JDK is significantly less work than upgrading all your tools to support a new language.

JDK 8 came out in 2014 - Internet Explorer was still widespread at the time.

Well, the new Android UI framework (Compose) is fully based on Kotlin and coroutines.

> With streams and the var keyword, Java is also not that much more verbose anymore than Kotlin

In general Kotlin is more concise, checkout these comparative examples:

https://stackoverflow.com/questions/34642254/what-java-8-str...

Those examples seem very biased; often the Java version does not use a more concise method that's available, or bloats the code by not importing a static method.

The Java examples are quoted from a Java stream tutorial.

Sure, which was probably optimised for explicitness (e.g. showing where everything is imported from) rather than concision.

>I dont really get why I would leave out the explicit types in the source code

One my pet peeves, shit like this sucks :

var f = MyStupidMethod();

In practice, the return type is often obvious. You can write:

  val foo = new MyReallyLongUglyFactoryClass()

instead of:

  MyReallyLongUglyFactoryClass foo = new MyReallyLongUglyFactoryClass()

And you never have to use type inference. If you have a method where the return type isn't as obvious, you can always annotate it explicitly:

  val foo: Int = doSomeThing()

Do people exercise judgement about when to make the type explicit? Eh, depends on the team. But if you combine type inference with established conventions in a particular codebase (e.g. I/O calls always return IO[Foo]), you will rarely be left wondering what the type of something is.

Yes but that isn't real code. If you see something like:

> var conn = openDatabaseConnection();

Are you actually confused about what conn represents? Does it matter what the exact type is, if you already know what it is and what you can do with it?

Yeah it does, I don't really know what I can do with it. A type annotation would be useful to search for.

I mean, you could just search for the method called, if you're REAAALLLLLYYY averse to using any IDE or editor of the last 10 years. Which would be an odd choice to base language decisions on.

Maybe you need to start using IDE, instead of programming in nano.

Maybe you need to go work for GitHub to fix their code search references, instead of trying to act superior to random people on the internet.

I'm using Intellij, VSCode and Code Search for searching, why would I use GitHub for it?

Why? The compiler knows what the type is, the ide can tell you the type if you need to know - it’s redundant for you to have to type it out.

Now do the code review in GitHub. Ooops!

Never have this issue. I'm not being hyperbolic either. I review Kotlin PRs every day and am never lost for context on a type.

I do code review on GitLab all the time, what’s the issue?

No compiler there so the compiler can't tell you the type. No IDE there so the IDE can't tell you the type. You're at the mercy of colleague(s) not to write code like var request = service.call() or, worse, var b = getResult().

nonsense

this line has zero readability

you're not writing code for compilers, you're writing code for people

I prefer inferred types when available. Then an IDE and compiler can get together to provide further details when needed. Honestly f: MyStupidInterface = myStupidMethod(); doesn't tell me much more.

The era of strong vs weak typing debate has passed. Adopt strong typing, like a professional, or fade into the 90s web. Harsh but fair.

practically all modern strongly typed languages are adopting or already had type inference from day one, allowing you to do things like var. They give up nothing in terms of strong typing to do so. Forcing people to write manual boilerplate does not equal professional, what a strange take.

The engineering trade-offs are paid somewhere, better in an objective space than a subjective one.

i dont know what you mean by this?

Fundamentally, this is a story of technology getting better (type inference in compilers) so humans can do less work. We're not pushing the work to some other human place. We're not losing anything in safety, and we're gaining in readability, boilerplate and expressiveness. Its progress!

Noone is arguing for weak typing. They're arguing for type inference. They're not even slightly the same thing

The era of not knowing the difference between static typing, strong typing, and type inference is past. I'm the sort of professional who likes to learn computer science.

> you're not writing code for compilers, you're writing code for people

i agree, thats why i don't want to clutter my code with annotations designed for the compiler, not humans. Type inference is a _good_ thing for readability.

You can just the type hints in the IDE for bad code like the above example. But glancing through my code, that is never an issue in practice because code reviews should have caught the poorly named variable and method.

Since the actual size of the code base isn't an issue in the modern world, I personally like that the Kotlin ecosystem discourages the use of esoteric names and non obvious abbreviations. Once you write and read enough of it you stop making poor choices.

Nonsense is doing compiler work yourself, even bigger nonsense is duplicating for zero reason.

> One my pet peeves, shit like this sucks :

> var f = MyStupidMethod();

Yeh, but so does:

  List<MyWeirdoFooClass> myWeirdoFoos = new ArrayList<MyWeirdoFooClass>();

Sometimes it's clear what it is. Sometimes you don't really care. Sometimes you do. You can still make it explicit when you need it to be explicit.

I don't find coroutines that helpful, but the syntax sugar and standard library in Kotlin is pretty awesome. The Elvis operator alone is worth the switch. Say you have some container with 3 levels of nesting. In Java, you have to null-check every level vs. 3 "?." dereferences.

In theory this is possible to approach with annotations but I found it hard to keep up in a large codebase.

If you need 3 levels of null-checks that's a red flag though

And with records you mostly don't need Lombok (unless you really like builders and can't wait for withers in Java).

JPA requires mutable classes.

Records ergonomics is terrible if you want to replace data classes with records, even if immutable is OK. You need to write builders. You can't really write code like

  new Person(id, null, null, null, lastName, firstName, null, null, null, null, null, null, null, age);

Withers can help with that, but they're not even in any kind of experimental shape right now, so we have many years to wait for it.

Right now records are only fine for very simple use-cases like Point(x, y). Or if you want to write or generate builders. But at this time you don't really save anything, if you can generate a builder, you can generate a class as well.

Yeah, I don't like JPA because of lack of support of immutable types (records or my own classes that don't have setters, only constructor).

If you have data class with more than 5 fields then you have it wrong. Builders are like lombok and like field injection: hide poor class design.

If using a class hurts, it is badly designed and should hurt until it is refactored/split up into consumable parts.

I use records extensively, but those are in most cases converted classes which were small and immutable. JPA being one of the exceptions (a stuck in the past spec)

Some of database tables I worked with had over 100 columns.

I don't think you need to map all of them to a single object - projections work well here.

There are very few cases where you need to work simultaneously on that many columns.

I can't imagine other way of dealing with database rather than using a single class per table. Projections are a way to optimize some niche queries which are too slow otherwise.

A 100 column table will be slow either way.

Why not have it like new Person(name, new Address(…))? Nesting is allowed.

Records not being extend(able) is the reason why Lombok is still mostly needed...

Why would you need extend over implements? I found sealed interfaces with records really cool.

> I find coroutines a really strange and leaky abstraction (and the prevalence of suspend methods in libraries which you have to wrap all the time just to call them synchronously is really annoying).

I think the point is to be calling them asynchronously. Unfortunately async programming is kind of contagious and difficult to shoehorn into sync stuff but if it’s written asynchronously there’s usually a reason.

Is it? Seems to me that most instructions are naturally async or can be refactored as such. I’m probably wrong, just a feeling.

Reply on news.ycombinator.com