Java 26 is here, and with it a solid foundation for the future

Re:Java 26 is here, and with it a solid foundation for the f... by kyrra on Tuesday March 17, 2026 @05:01PM (#47418252)

Not the GP, but for really large code bases, Go is missing a few features that I've noticed:

1) No immutable types. My work team is a huge user of immutable data stuctures in Java to make sure data passed around to other teams isn't changed. Go doesn't really have a good way to do this.

2) Refactoring can be really annoying (or at least really noisy) because of public/private being defined by capitalization of method/field names.

3) Error handling isn't great. I love Go's errors being just normal values, but the `error` interface is awkward when trying to figure out what kind of errors can be thrown without having in-depth knowledge of the kinds of errors that can be returned. We regularly need to make different decisions depending on the kind of error returned. Knowing which errors can be returned in Go is not defined by the method being called (only in comments).

[ Parent | on HN ]

Re:Java 26 is here, and with it a solid foundation for the f... by oefrha on Tuesday March 17, 2026 @07:17PM (#47419658)

> No immutable types (in Go)

The typical answer is opaque types with only readonly methods exported. Not elegant, but it’s there. I guess it’s arguably not a “good way” to do it.

[ Parent | on HN ]

Re:Java 26 is here, and with it a solid foundation for the f... by joeblubaugh on Tuesday March 17, 2026 @07:42PM (#47419868)

In fact it was “the Java way” for many years and “useless getters” was always a big complaint about Java.

[ Parent | on HN ]

Re:Java 26 is here, and with it a solid foundation for the f... by oefrha on Tuesday March 17, 2026 @07:53PM (#47419977)

Hey it's better in Go. In Java it's getFoo(). In Go it's just Foo(). Saves three bytes, and three keystrokes if you program by hand and don't autocomplete!

[ Parent | on HN ]

Re:Java 26 is here, and with it a solid foundation for the f... by gf000 on Wednesday March 18, 2026 @03:33AM (#47422673)

I do agree to a certain degree, but with getters/setters you could properly hide/set to read-only fields.

[ Parent | on HN ]

Re:Java 26 is here, and with it a solid foundation for the f... by wbl on Tuesday March 17, 2026 @08:24PM (#47420215)

I think you want sum types which admittedly Go doesn't have in a matchable way. However complex error recovery is an anti pattern for Go.

[ Parent | on HN ]

Re:Java 26 is here, and with it a solid foundation for the f... by gf000 on Wednesday March 18, 2026 @03:31AM (#47422663)

> However complex error recovery is an anti pattern for Go.

Bit of snark from my side, but that's exactly what makes it less good of a fit for "industry purposes".

Go's error handling is possibly the worst out of any "modern" language, it basically copied C's errno which is not something you should have ever done.

[ Parent | on HN ]

Re:Java 26 is here, and with it a solid foundation for the f... by wbl on Wednesday March 18, 2026 @02:50PM (#47429817)

Why exactly do you have complex error analysis happening above a component that has the error? That's anti modular.

[ Parent | on HN ]

Re:Java 26 is here, and with it a solid foundation for the f... by gf000 on Wednesday March 18, 2026 @08:12PM (#47433038)

Because almost my definition you can't handle errors in the component, otherwise you would have a conditional and not an error.

E.g. if I do some IO like "make a copy of these files" and get an error/exception, it's only the caller or maybe even that caller's caller that can properly deal with this condition (e.g. to decide that we will skip the erroneous files or retry).

[ Parent | on HN ]

Re:Java 26 is here, and with it a solid foundation for the f... by peterashford on Thursday March 19, 2026 @03:36AM (#47436078)

This was exactly my experience when I first read about Go. I was so excited until I found they were repeating the c experience of check every bloody return value separately. That was the worst feature of c - why copy it

[ Parent | on HN ]

Re:Java 26 is here, and with it a solid foundation for the f... by dinkumthinkum on Wednesday March 18, 2026 @02:03AM (#47422050)

This is not a dig at Go and this will be controversial but I so struggle to see what problem or area Go is solving outside of CSP. It's a nice language it just feels far too simple and I am really convinced of it as a systems language over Modern C++ and if you want that alternative then we have our rather oxidized friend that seems to more substantial. That's just my take.

[ Parent | on HN ]

Re:Java 26 is here, and with it a solid foundation for the f... by peterashford on Thursday March 19, 2026 @03:47AM (#47436151)

I code Go at work. I've been using it for just over 3 years. I really like it. I prefer Java, but Go is a much more ergonomic C and its a very pragmatic language. Except for the *%!@ error system, that can burn in hell.

[ Parent | on HN ]