[voidfunc]

Java gets a bad rap from people that used it late 90's through early 2000's and got burned out by XML and design pattern heavy frameworks but its a lovely language that with a little discipline can be used to create very lean looking code.

Go is one of the HN darling languages and I work in Go everyday for work (and generally like it), but I really wish I could reach for Java most days.

[laurent92]

“Java is a big DSL to transform XML into stacktraces” — so was the joke at the time when domain-specific languages were the hype.

This, and the FizzBuzz, Enterprise Edition: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

More seriously, what are you missing in Go that is well-done in Java? I assume verbosity of the code is still the defining characteristic of Java?

[voidfunc]

> More seriously, what are you missing in Go that is well-done in Java?

1. Generics. And yea, I know Go is getting generics "Real Soon Now" (tm), but it is incredibly annoying to write the same collection code over and over and there's some third-party libs that would really benefit from generics (looking at you Azure Go SDK).

2. Error handling... with the big caveat that I actually like Go's error handling mechanism at small scale but wish there was a good way to chain several operations together and return an error to the top if any failed... I find myself writing a lot of `err != nil` checks in sequence and I've found baking my own abstractions around this to be leaky or difficult to grow as the program requirements change.

3. Diverse collections API.

4. Iterators.

5. Not Java-the-language but the JVM has amazing monitoring tools.

> I assume verbosity of the code is still the defining characteristic of Java?

Pound for pound... I think Go and Java have about the same verbosity. I'm honestly never quite sure what people mean by "verbosity" in Java. Generally I interpret this as "frameworks" but I predicated my OP on the idea that legacy framework bloat is where most of people's frustration with Java lies... not the language itself.

[tonyarkles]

Now we've got Spring, which in my, admittedly limited, experience does a great job of transforming what could have been compile-time errors into run-time errors.

[pgwhalen]

Not OP, but...

> More seriously, what are you missing in Go that is well-done in Java?

As cliche as it is to say, Go missing generics (for the time being) does hold it back in many ways relative to Java. I like and use both languages regularly, and as I thought about my answer to this question I realized that essentially all of my complaints stem from the lack of generics - things like streams, a rich collection framework, and non-channel concurrency features (java.util.concurrent among them) don't exist in go because you can build them as generically as needed for them to be useful.

You might have said "well-done" as a way of excluding generics in Java since many people like to suggest they're not well done; of course most developers would like more, but they already enable an enormous amount of stuff not possible in Go.

[srparish]

Verbosity of code is more of a go thing these days:

  hasThing := false
  for _, v := range stuff {
    if checkForThing(v) {
      hasThing = true
      break
    }
  }
  if !hasThing {
    return false
  }

Java:

  if !stuff.stream().anyMatch(v -> checkForThing(v)) {
    return false;
  }

In the 2020s, loops are the new "goto", too much boiler-plate and ways to subtly be incorrect, much safer to use higher-level collection methods.

[matsemann]

The java ecosystem is very nice. Not necessarily the language itself, but everything else. The jvm, the tools, the libraries are all very mature and good.

Skipping java and instead using Kotlin allows one to reuse all that knowledge in a great language as well.

[pron]

I'd say the defining characteristic of Java is an unparalleled combination of performance, observability, and maintainability.

[rafaelvasco]

I at the same time laughed and got nauseated just by looking at that FizzBuzzEnterprise code LOL. I'm a minimalistic programmer myself, so the thing I hate the most in coding is over engineered code. Yes , it's a joke, but a joke based on real life haha.

[mleonhard]

Logging.

[ragnese]

I disagree that it's a lovely language. I think, as developers, we very quickly develop Stockholm syndrome. Once you "learn" a language, it's really easy to churn out code and apply idioms without even realizing that you're constantly writing workarounds and kludges for your language's deficiencies.

As a polyglot dev, the following are my gripes with Java:

* null - we all know, so I'm not going to bother expanding except to say that @NotNull is NOT a solution and it doesn't guarantee shit.

* interfaces are extremely lacking compared to type classes and lead to verbose and cumbersome patterns such as "Adapter".

* Type-erased generics. Why shouldn't I be able to implement a generic interface for multiple types? E.g., class MyNumber implements Comparable<Integer>, Comparable<Short>, Comparable<Long> {}

* It only just got Records and sealed interfaces, so thank goodness for that. But prior versions of Java are extremely lacking in expressiveness without these.

* I don't hate checked exceptions as a concept, but the fact that you can't be "generic" over the exceptions in a function signature is frustrating. This is why everyone says they're "incompatible" with Java's closure APIs.

* No unsigned ints.

* Silent integer overflow/wrap-around. It's not C- did it really have to copy this insanity?

* Dates and timezones are still insane, even in Java 8+.

* The fact that arrays got type variance wrong.

* JDBC sucks. JPA also kind of sucks.

* No concept of `const` or immutability.

I'm not saying that Java is the worst language in the world or anything, but it's far from great, IMO. Most programming languages are pretty awful, IMO.

[MaxBarraclough]

> No unsigned ints.

I think that's a mixed blessing. I believe Java did this deliberately to avoid the trouble that C and C++ have with signed and unsigned integer types having to coexist. Personally I've never been inconvenienced by Java's lack of unsigned integer types, but I'm sure it can be annoying in some situations.

I'm quite fond of Ada's approach to integer types, but I suspect I'm in a minority.

> Silent integer overflow/wrap-around. It's not C- did it really have to copy this insanity?

Curiously this cropped up 10 days ago. [0] You're not alone. The great John Regehr put it thus: [1]

> Java-style wrapping integers should never be the default, this is arguably even worse than C and C++’s UB-on-overflow which at least permits an implementation to trap.

> The fact that arrays got type variance wrong.

At least Java has the defence that they didn't know how it would pan out. C# has no such excuse in copying Java.

> No concept of `const` or immutability.

I recall a Java wizard commenting that although a const system is the sort of feature that aligns with Java's philosophy, it's just too difficult to retrofit it.

[0] https://news.ycombinator.com/item?id=26538842

[1] https://blog.regehr.org/archives/1401

[The_rationalist]

Your analysis is interesting and far from exhaustive, It would be nice to have a collaborative feature matrix for languages, on github.

Kotlin solve the following points:

null - we all know, so I'm not going to bother expanding except to say that @NotNull is NOT a solution and it doesn't guarantee shit.

I don't hate checked exceptions as a concept, but the fact that you can't be "generic" over the exceptions in a function signature is frustrating. This is why everyone says they're "incompatible" with Java's closure APIs.

No unsigned ints.

No concept of `const` or immutability.

Kotlin allow to specify either variance or contravariance so I guess it fixe this point too? * The fact that arrays got type variance wrong*

* interfaces are extremely lacking compared to type classes and lead to verbose and cumbersome patterns such as "Adapter".* Interesting, can you link to an example? Kotlin has first class support for delegation as an alternative.

* Type-erased generics. Why shouldn't I be able to implement a generic interface for multiple types? E.g., class MyNumber implements Comparable<Integer>, Comparable<Short>, Comparable<Long> {}* Kotlin has support for reified generics to some extent. The JVM is currently getting state of the art support for it too and for specialization.

* Dates and timezones are still insane, even in Java 8+.* I always hear that Java has got the best Time library, what is the complaint about?

* JDBC sucks. JPA also kind of sucks.* Do yourself a favor and use the JDBI or so many other sexy alternatives.

Of all your points the only unaddressed are: * interfaces are extremely lacking compared to type classes and lead to verbose and cumbersome patterns such as "Adapter".

And Silent integer overflow/wrap-around*

Strong agree about stockolmization and cargo cultism of language constructs.

Most programming languages are pretty awful Correct, hence why Kotlin stands out.

[superyesh]

>got burned out by XML and design pattern heavy frameworks

Most succinct summary I have heard lately :) I think a good bunch of blame is also on the developers who blindly adhere to said patterns. https://www.quora.com/What-are-the-most-ridiculous-Java-clas... to rest the case.

[Thaxll]

"Go is one of the HN darling languages"

It's def not the case, I spend too much time here and on Reddit and people are always complaining about Go ( generics, errors, type system etc ... ), if you want the godly language it would be Rust, anything about Rust will be upvoted.

As for Java, it's a good language / runtime that is overly complicated behind layers of abstraction. Take Spring for examnple, magic everywhere, add an anotation there and it does x.y.z, you can't see it in the code but it does something.

[ragnese]

The hype around Rust is largely justified. There. I said it.

Rust is nowhere near perfect. It's also supposed to be a systems language- it was probably not originally intended to replace languages like Java for general "app" development.

But it's so much better of a language than most of the higher level languages you see in popular use: Java, PHP, JavaScript, Python, etc, that people are actually willing to deal with the lack of garbage collection just to get to use its excellent type system and well-designed standard library API. I think that says a lot about Rust and the programming language environment today.

[kaba0]

Java itself is most definitely not overly complicated. Many frameworks, and created programs are due to enterpriseTM software development, but it’s orthogonal. And spring is a really feature-packed framework which has a solution for almost every business problem that one can face. Of course it comes with a great deal of complexity, but it is a tradeoff. I rather tinker with how to use a given feature than implement it myself, often in an inferior way.

[geodel]

> if you want the godly language it would be Rust, anything about Rust will be upvoted.

That is just better half part, sad part is anything negative about Rust will be heavily downvoted. Most of the time I disagree with Java/Go in their thread it would be just fine but not with Rust.

[vips7L]

You can just stop using Spring. There's plenty of good web libraries out there. Javalin, Spark, Micronaut, Quarkus, heck I'd probably even take JEE over Spring nowadays.

[kukx]

It also gets a bad rep because of Oracle.

[happyweasel]

Java isn't the worst C++ program I know.

[ericbarrett]

I got burned out by endless JVM preening and devs configuring their runtime options to use 128MB in a 2GB container, or capitalizing their -Xm option wrong, or what have you. So now with cloud computing you have the JVM in a container on a virtual host, all of which have their own constraints to set—matryoshka dolls all the way down.

Like, people always say, "Well that just means they didn't know what they were doing with the JVM"—yes, and it's been a problem for two decades and is about as likely to go away as buffer overflows in C.

Honestly the thing I like about Go, Rust, C++ the most is the resultant binary just runs in userspace, and you can set the constraints there. Even Python scripts don't have to muck with the JVM.

FactoryFactoryFactoryFactory code is the least of Java's issues.

[edp]

Starting with OpenJDK 11 (and I think available in OpenJDK8 with an optional flag), the JVM will use the memory constraints of the container, so no more -Xmx flags and so on if you are running the JVM in a container environment.