Hacker News Reader

Comment by riku_iki | Hacker News Reader

> Java's problem is that it doesn't do this well for anything but heavy business logic applications, and the more clever the programmer, the more they can build up complex structures

Java has very simple OOP constructs (classes, interfaces, inheritance, simple generics) which everyone supposedly know already in industry. Golang from another hand implemented unorthodox solutions, which actually require some learning curve (e.g. how to model stuff without inheritance and generics).

View on HN

Java encourages (partly through language design and partly through its community/ecosystem) [Enterprise Grade Programming](https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...). The problem isn't the language per se, but that most code bases will require you to earn an architecture astronaut certification for that particular code base.

But also, the Go spec is a couple of pages and the Java spec is, uh, it's taking a while to load for me... ah yes, 876 pages. How's that learning curve?

> but that most code bases will require you to earn an architecture astronaut certification for that particular code base.

sure, if go would be popular in enterprise dev, we would see magnitude more error handling spagetti and genericless copy-paste code in go

> But also, the Go spec is a couple of pages

I think you undermeasured it by 20 times. Also it is very possible that golang spec is much more shallow. But anyway, I don't think one need to learn java spec to learn the language.

Java is too slow, and the language is not powerful.

The go spec today is ~130 pages [0]. Like golang’s Stalin, its spec remarkably approachable. The latest Java spec is ~800 [1], also very accessible, but clearly there’s more complexity there.

You have to admit, there’s something appealing about being able to read the entire spec for a popular, performant, production language over a lunch break. You don’t need to read and/or master a language’s specification in order to use it. But at 130 pages, you can.

[0] https://go.dev/ref/spec [1] https://docs.oracle.com/javase/specs/jls/se23/jls23.pdf

> You have to admit, there’s something appealing about being able to read the entire spec for a popular, performant, production language over a lunch break. You don’t need to read and/or master a language’s specification in order to use it. But at 130 pages, you can.

you are probably programming language enthusiast, but I am not, I have long list of other things to read..

Relying on composition rather than inheritance often feels much more natural in my experience. C, Basic, Pascal, etc. are all missing inheritance and generics, are they similarly unorthodox and difficult?

Java-style OO has a place, but it’s not always a perfect fit. Java, C#, and arguably C++ have taken a kitchen-sink and grafted any and all constructs found in other languages so long as they look remotely useful. The result often is useful, but it also results in a more complex language.

While Go isn’t a perfect language, nor is it a great language, I /have/ found it to be a productive language in ways that Java, python, ruby, etc. are not. I attribute this productivity boost to the simplicity of the language (if not the runtime) and to the conservative approach taken to add new features.

> C, Basic, Pascal, etc. are all missing inheritance and generics, are they similarly unorthodox and difficult?

yes, they are unorthodox for this specific niche: enterprise devs, most languages have OOP and most devs know it.

> Java, C#, and arguably C++ have taken a kitchen-sink and grafted any and all constructs found in other languages so long as they look remotely useful.

I disagree with you, Java approach was very conservative, and original goal was to have simplified OOP. If you have specific examples: we can discuss.

Reply on news.ycombinator.com