[arihant]

Java programs got that way not because of language, but because teams of thousands of developers managing same codebase for decades. Explicitness and non-magicness are extremely valued in that environment.

Imagine you're refactoring a code written by employee #12340 that was written 10 years ago. With Go, you'd go file after file decomposing the program to finally figure out that if he just used a word to implement an interface, you only had to read that file and a javadoc. Long class names are still easier to look than signatures of functions.

Java emphasises abstraction. Go emphasises composition. Both have its uses, but what I was refuting was people claiming that Go is better than Java which I think is extremely uninformed conclusion.

[chrisbroadfoot]

> Explicitness and non-magicness are extremely valued in that environment.

This is not my experience with Java programs.

Enterprise Java programs often have many layers of magic abstraction, like Aspect-Oriented Programming, dependency injection, IOC.

Furthermore, people love using configuration files over code to determine program behaviour (see servlet configs, etc).

[mahmoudimus]

If you had said this comment 5 years ago, I would agree. I think you should take a look into today's Java development environment. It's world class, and light-years ahead of anything else out there.

[chrisbroadfoot]

Good to hear. I haven't programmed in Java in about that much time :)