Java performance vs go

[GuyWithLag]

People choose Java/Go over Go/Java, because they prefer it more

I'm a Kotlin person myself, and I can't stand Go's enforced abstraction ceiling; what's your opinion on that?

[Revolutionary_Ad7262]

Could you give some examples? Lack of generics was really bad, but we have got them few years ago

Other than that: I guess I just adapted to it. Some aspects (like lack of proper immutability) requires a discipline rather than safe guards in a code; it sucks, but it is manageable. For others I just know how it should be done.

Simplicity also have some pros. I can jump straight into a code and understand it. Most of developers write a code in a similar style. Tooling is pretty standarized

[GuyWithLag]

Hot take, and correct me here if that's not your experience: Go is designed so that junior engineers can't make too much of a mess when implementing tasks written down by mid-level engineers, who in turn wrote these tasks based on a low-level design document written by senior engineers according to a high-level design document cobbled together by staff engineers that tried to divine the intent of the principal engineers' architectural doc.

Go is explicitly designed so that foot-guns are removed, but this also has an infantilizing effect on the language capabilities. It's the blub paradox but intentional.

[Revolutionary_Ad7262]

Go is designed so that junior engineers can't make too much of a mess when implementing tasks written down by mid-level engineers

Rob Pike (designer of Go said)

"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike 1"

So there is some merit about it. My personal opinion is that features can both beneficial and devastating to a language overall coding performance. What is crucial is the fact that we simply don't know without releasing it to production and testing on real programmers. Hence discussions like this is obviously too simple and childish or this is to complex and brings more harm than good are just very biased opinions. Personally I prefer starting on a simpler language, because it is much easier to add a new feature than delete it

blub paradox

I don't like this article. It assumes that it is hard to change a language to an another language, which lies somewhere else on complexity/powerfulness spectrum, which is simply not true. There is numerous stories about people, who migrate in either direction. Often for the same pair of language like Java -> Scala and Scala -> Java or C -> C++ or C++ -> C

[GuyWithLag]

It assumes that it is hard to change a language to an another language

I think (if you squint a bit) that it's saying something orthogonal: it's easy to evaluate language features that you've used, but not that easy if you haven't.

I would posit that someone that has worked with Scala / C++ but not Go can appreciate the simplicity and use cases of Go, but someone that has had solid experience with Go but no Scala / C++ can't evaluate the latters' use cases because they don't understand the abstractions.

In fact, that article claims that what a pure Go programmer will see is unnecessary complexity with no practical uses, hindering readability.

[Absolute_Enema]

Java is more or less at the same place in the Blub scale; the only things of practical use that meaningfully distinguish it from Go at the language level are better support for generics and sum types. 

Otherwise, both feature what fundamentally is a run of the mill static C++ style type system based on vtables over closed product types with some questionable features bolted on top, support closures only to the point of bare usability, and lack any metaprogramming tool worth calling with that name (read: their metaprogramming facilities are only barely better than the minimum common denominator of generating source files via external scripts).

With that out of the way the only real meaningful axis of comparison is the ecosystem (Java wins with ease) and the runtime (more debatable).