Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The title of the blog post is IMO a poor choice. The (hidden) subtitle of the post is "Algebraic data types in Java" which is much more descriptive of the content. A better title would have been "Algebraic data types in Java 21".

Perhaps because of the title, many/most of the comments here are off-topic. I was hoping to see more discussion about algebraic data types, strengths and weaknesses of the Java implementation, technical comparisons to other languages, etc.



Yes, I'm also not really sure I want to see algebraic types in Java even though I would prefer if a language that focused on algebraic types was more popular.

All the existing Java code doesn't go away, so is it really going to be nicer to have code like this mixed randomly into that?


Of all the features most Java devs (and ex-Java devs) desire, algebraic types are near the bottom.

How about intersection and union types? (NO, sealed classes are not a substitute for unions).

But, yeah, in my view JDK 21 is a a disappointment. I rarely want pattern matching, but I would like properties please and records are nice, but actual tuples are more useful. Etc.


I would love a union type in Java, but I still enjoy the language, community and especially development experience. I wouldn't recommend it for everything, but it's sturdy by design and enjoyable for when it fits.


I'd love if interfaces worked as in typescript.

As long as the object signature matches the interface as parameter then you can use it.


Check out project manifold, it’s a compiler plugin for Java. Among other amazing features it adds structural typing [1], which is essentially interfaces typescript interfaces.

1. https://github.com/manifold-systems/manifold/tree/master/man...


Well hopefully it won't be mixed in _randomly_.

I have some use cases in mind and think it will be very helpful. I have been converting a 10+ year-old code base to modern, functional-style Java and believe that sealed types and pattern matching will help us further simplify our code and eliminate more usages of nullable values.

A challenge for us will be that we need the core library to stay on JDK 8 for a while. But, in general, I am finding that you can implement a JDK 8 library that works well with newer JDKs if you are careful (and willing to write more verbose code using the older syntax/libraries to support the newer paradigms)


I did title it that way at first but ended up changing it at the last second, ended up shunting it off course.


It's a great post. Thank you for writing it!


thank you for giving it a read!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: