[pgwhalen]

I use (and enjoy using) both Go and Java at work, and Go is in my opinion very much a Java replacement more than it is, say, a Python or C++ replacement. It is absolutely suitable for business logic, and I've never been quite sure what its designers mean when they say it's a systems language. Yes, you can squeeze great performance out of it, but you can with Java as well.

The way I see it, both Go and Java are crawling towards the same ideal: a compiled, statically typed, garbage collected, modern enough program language targeted for a majority of back-end concerns. Go has to close the gap mostly just with generics; and Java with memory layout (Valhalla), concurrency (Loom), and ergonomics (Amber); but they will both be there in 3-5 years.

Take this with a grain of salt if you like, but while I probably find it more fun to program in Go, I don't think there's a compelling reason to switch a large codebase from Java to Go. It often feels like my company is needlessly divided by programming languages even though they solve fairly similar problems. It's one thing to move off of a dying language, but Java is certainly not that.

[zz865]

Thanks, that sounds about right. Throw Rust in there too, its an interesting time.

[theshrike79]

The difference between Java, Go and Rust is that you can teach the first two to any fresh out of school CS grad in a week or two and have them be productive.

Not so much with Rust.

[pgwhalen]

Rust is a great language too (I'm in the process of learning it), but I would definitely not put it in the same category as Java and Go in terms of the problems it is good at solving. It fits much more with C/C++.

There is a huge class of problems that don't need the precision (especially around memory) that Rust demands from the programmer.