[quotemstr]

You could have said the same about pre-generics Java. The problem is that when the language is simple and minimalist, people do things with the language that are byzantine and arcane, and you can't learn those in two weeks. Example: classic Spring's XML configuration inner platform.

[socialdemocrat]

No you couldn’t. I watched both Java and Go since they got released and Java really quickly went into the over-engineering and complexity camp long before generics. I worked as a consultant doing Java long before generics and the culture of over-engineering was already there. The language also really encourage it.

Go is an entirely different beast. The language, libraries and whole community is really worshipping simplicity in a way Java never did.

Just look around a bit at the standard library. There are pretty much no setters and getters. No inheritance hierarchy to speak of. Not even constructors most of the time.

It is not without reason that Go angers a lot of people that think they know how to do software. It breaks all the rules they have kept sacred, that they think all “real” programmers should follow.

Think about it this way. If Java is SLS assembled in a clean room never getting done, then Go is more like SpaceX assembling a rocket in open space with guy who normally weld water towers. It isn’t how it is supposed to be done but it works and they get shit done 20x faster.

[mbesto]

> The language, libraries and whole community is really worshipping simplicity in a way Java never did.

Isn't that because it's essentially "new"?

[Cthulhu_]

It's been released (or gotten a 1.0 release) in 2012 but in development since 2007, so relatively as old as Java 5 since Java's inception; compare the features added to Java with those to Go: https://en.wikipedia.org/wiki/Java_version_history vs https://en.wikipedia.org/wiki/Go_(programming_language)

[nrr]

I don't think so. Go looks to be focusing mostly on systems-level problems and the kinds of applications that orbit that concern.

Java, on the other hand--at least when you control for the confusion around whether "Java" referred to the JVM, the language, the base class library, or the security model--was looking to take on C++ and the kinds of software people were looking to write in 1996 in C++.

You can write line of business software in Go, but that doesn't really feel like its purpose in life. The language fights you a little bit when you try to do that.

[yesdocs]

News flash: this is what they said about COBOL, C, C++, JavaScript, closure, etc. as well as architectural patterns such as OOD or functional programming. Every language, and every platform has it’s nuances. You can do silly, non performing things in any language or platform. To assume a particular language will solve all your woes is outright naive and exhibits no memory of past software engineering concepts.

[ineedasername]

You are basically saying that no language is a silver bullet and any of them can go badly wrong, which is trivially obvious and not a productive addition to the discussion. If you have specific criticisms of this approach, that would be much more constructive.

[yesdocs]

When you claim history is ‘not productive’, you have taken the fool’s path.

[geodel]

Nope. Java complexity came straight from Sun and friends. J2EE / EJBs (came in 2000) did not come from some randos, it was official Sun specification and supposedly standard way to develop any enterprise application.

[jshen]

I think Go has held up pretty well on this front, and I've also found a good heuristic to detect if libraries aren't doing this well. Check and see if they use the empty interface type a lot (this is the All or Any type in go). It's a code smell for me if I see a library using it a lot.