Hacker News Reader

Comment by throwaway189262 | Hacker News Reader

> but I'd love something like JavaScript that had the performance of C^

Java honestly is close. Data object creation is notably worse unless you're using Lombok or similar. Besides that, modern Java and JS syntax are similar. And Java doesn't have a horrible underlying object model based on prototype chains.

IMO Go seems easy because it's simple. I know Java and JS well and they're about the same complexity these days.

Knowing both I will never touch JS for backend again. Java is better suited for it. Strong typing is light-years easier to follow code paths and refactor. IDE's, debugging, profiling tools, memory usage, and performance are all better in Javaland. Real threading with proper shared memory exists. App size is smaller since Java bytecode is compact and distributed zipped.

My company stopped using JS on backend after the hype wore off. Our Java backends are easier to monitor and maintain.

View on HN

I agree wrt to Java. Because Java has been around for so long it has a lot of emotional baggage that I think makes people reflexively dislike it. But, modern Java with any of the micro frameworks or something like Spring boot, plus jOOQ makes for a very easy and productive backend. And because Java has been around for so long, if you run into edge cases like parsing a weird file format, there is probably a library out there. Kotlin has a lot of same advantages, plus a more expressive syntax if that's what someone is after.

Go is also works for the backend, but you have to get into the mindset that you're probably going to write a lot of code. That's fine, but it's a shift from many other languages. As someone who has programmed for 20+ years, I like the single way to do most things in Go. There's also a bit of elegance coming full circle through many languages where a for loop is once again just a for loop.

And maybe I'm showing my age, but I also completely agree that backend languages need strong typing. The other option is significant test coverage, but we have all seen how that goes in practice. Code without strong typing always feels like it's meant to be written once and thrown away because it's so hard to read later. And, this style fits with how UIs often work where the life of a product will end up with many UIs on the same backend.

I was on the Java hate train till I was forced to use it. It became my favorite language. For being so old, Java has avoided feature creep and bad decisions that make old code painful to deal with.

Sometimes I work on 10+ year old areas of codebase and it's fine. Compared to dumpster fire of 10 year old JS/Python/C++ it's paradise.

I use lombok judiciously to avoid getters/setters, the cruftiest part of Java. Newer versions of Java are quite pleasant.

Java is extremely mature. I pull in a library and it "just works" 99% of the time. No worries about the version of Java is was built for or missing native dependencies. Practically every language falls short of the polished user experience in Java.

I don't like Kotlin because the non-Android experience is an afterthought and it's a captured language by Google and Jetbrains. Java has a lot more hands at the wheel.

How does Kotlin compare?

Kotlin is better on paper but IMO, only the better choice on Android. I always run into Kotlin tooling issues on "non-android" Java. Stuff like Maven plugins not working. Plus, IDE support is only good in IntelliJ and it's been that way for years so I don't expect it to change.

Kotlin fixes tons of issues in the frankensteined Java 8 of Android. You can use Java 15+ everywhere else and its adopting many features that made Kotlin worth using.

Google is pushing Kotlin so they have control over Android language like Apple does for iPhone. It's just a nice layer over Java in the end since 100% interop is required.

Java is a long way from Kotlin feature-wise and at the current rate of "innovation" we're more likely to have expired before Java catches up with Kotlin. I mean, come on, in the 25 years since 1.0 Java hasn't even fixed the requirement to escape metacharacters in a regex. The SAM lambdas of Java 8 are also a feeble compromise with FP at best. Kotlin has a much cleaner approach to FP, immutability and null safety.

Reply on news.ycombinator.com