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

I started with Java and I will most likely never go back. I mainly use Go now.

People want to learn/write Go. It's hard to find anyone that wants to learn/write Java. People probably prefer Kotlin over Java today. It's a much better language and you can keep using JVM libraries.

Go is very simple language that is just as powerful as Java, if not more powerful due to not having to rely on the JVM. That's why it's so popular as a replacement for Java.

How are Jars more portable than Go binaries when you need Java installed to run Jars?

Java obviously has a more mature ecosystem with more libraries due to age, but Go you don't need many libraries to begin with. The Go std lib will give you almost everything you need in most cases.



> Go is very simple language that is just as powerful as Java

I don’t think so, Go is very low on expressivity. Generics help, but I don’t see anything like JOOQ for go, just as an example. Also, no real alternative to Java’s stream api, which can at times make code much more readable than the 4 nested for loops with 4 different exits.



Having looked at the docs, it seems to be full of stringly-typed parameters.


In 2010, I think arguing that relying on the JVM would be an acceptable gripe. However, it is 2023, almost all of your stated issues have been (IMHO quite elegantly) addressed WITH the added benefit (or maybe detriment?) of backwards compatibility in modern versions of Java and the _incredible_ engineering behind the JVM.

I would actually argue the inverse. Between the two languages, Go would be my second choice precisely because it does NOT have the JVM. Even though I have used GraalVM for AOT, with Docker / containerd, I would take the JVM any day. It's just night & day when operating something in production.

That being said, Go still has a lighter resource footprint but I found Go to be a better Python alternative than Java.

Here are some IMHO acceptable gripes with Java:

- Java represents strings using UTF-16 (although there are optimizations introduced in Java9+ already to use LATIN1 / ascii encoding if you don't need to use Unicode)

- Java makes it difficult to have steady state memory consumption (by design)

- Java's escape analysis is primitive

- Java is missing value types (coming soon!)

I think Go is great, but IMHO modern Java is just better at building backend systems.


> How are Jars more portable than Go binaries when you need Java installed to run Jars?

Uh, you don't...?

https://docs.oracle.com/en/java/javase/14/docs/specs/man/jpa...

> you don't need many libraries to begin with.

This really depends on what you're doing. Having many libraries creates a lot of weird potential. You can absolutely subsist on less, but you can do more with more.

A while back I found myself wanting to render MathML into an image. So I dug up jeuclid which is absolutely antique and as far as I can tell not actively maintained. My project flat out would have ended there if I had to build my own math rendering engine to proceed.


> Each format must be built on the platform it runs on, there is no cross-platform support.

So now you're back to platform-specific packages, except you don't have Go's support for cross-compilation. Hardly much of an advantage.


Well yeah. You've still got jars though if you want architecture independence. Java's not really aiming at the desktop market though. It's a server language first and foremost. You're most likely setting up a machine (or VM or container) to cater to the Java code you're running.

But to be realistic, most Java code either runs in application servers (as WARs) or in containers, and in the latter case, even though your java jars are architecture independent, docker just isn't.


Go only does cross-compilation when using the standard library and pure Go libraries, hardly any different.

Plus the target OS needs to exist on the toolchain anyway.


You can make self-updating packages of JVM apps for Windows, macOS and Linux from your local OS ("cross compiled") using Conveyor:

https://conveyor.hydraulic.dev/

It's not JVM specific but it does understand how to bundle the JVM, use jlink to shrink it, read your classpath from Gradle etc.


> How are Jars more portable than Go binaries when you need Java installed to run Jars?

Your java knowledge is half a decade out of date.


It’s not hard to find people who want to write Java. I do it all the time. We have been hiring and writing Java code for fifteen years and have not seen a decline in the interest.


I'm not talking about people that have been writing Java for years. I'm talking about new programmers. If you asked a new programmer out of college which job they would rather have I job programming Go applications or Java. I would bet 90% of them would pick Go.


And they will agains say the current hyped language a year later. It’s almost like we shouldn’t really cater to “new programmers out of college”.


Sorry, it's hard to find you. I had to scroll down this page.

It's even harder to find Rust developers and yet it's well liked - so? So?

The funny part is most of the anti-Java logic is flawed. Maybe using Java will fix that for them :p


It’s hard to find quality people who want to write Java.


Where I am it's hard to find quality people period. If anything targeting Kotlin or Scala developers usually yields slightly better developers but also further restricts an already small candidate pool.


You are talking about more people than there are people in my country (around 10 millions java devs are out there)


I’m sure you can find a hole in your logic. (I’ll point it to you, millions of Java devs are not your hiring pool)


Really? So you mean to say there are no quality people in the millions of Java programmers out there?


No quality people - no, small amount - yes. And millions of Java devs are not your pool.


What is a small amount? 1%? 0.1%?


What people?!? That is a very special bubble over there.




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

Search: