Что скажете?

This is just my opinion as someone who's spent more than a year with go and several years with Java. I tried Go first, and did the whole "idiomatic" Go, approach. I tried it back in the "pure" days before Generics came about.

I would like to preface it by saying that you can definitely build successful products in Golang. This cannot be discussed as it's being done. What follows is my own opinion, about aspects of Golang (and the Golang community at the end) that I dislike.

I have several things I would miss if I went back to Go compared to the current Maven based Java builds I do today. The first two points are the most critical.

The further down we go the less important the point.

Proper Dependency Injection

Doing dependency injection in general is considered Anti-Idiomatic-Go, and in fact I was told by another Senior Go Developer that it was not "Idiomatic" Go to do depenency injection. So under his tutelage I coded massive applications where everything was handwired together. Many of the components could not be tested independently of their dependencies.

Lack of proper package managment

The package handling in Go from the start ranks as among the worst possible setups of all the package management systems - It isn't one. It's something built to support Google's Mono Repo approach, but it does so in a horrible fashion. Setting up central repository mirrors, fixing versions, generating peer dependency graphs and all the things you need simply wasn't possible then, and it's not fully possible today either.

Setting minimum version as default in the newer approaches also sucks a lot of developer joy out of me just thinking about it.

Junior Devs (and quite a few Senior Devs) don't care about dependency versions - As just as the code runs.

I fear that Golang Apps will be opened to a whole host of CVE's over time due to this unfortunately :(

Java's Maven and PHP's Compose are the gold standards. I hope the Golang team looks to these package management systems and basically copy it.

Domain names in package names

This is a horrible anti-pattern which Golang made standard as the "Idiomatic" way.

This means that you basically cannot make properly modular designs, where you rewrite an implementation of a module, but published under your domain name. In that case you have to hand rewrite the codebase to use your packages, instead of just using a different dependency

The "You haven't worked in large codebases" excuse

I've worked in Java codebases reaching into 750k lines of code

Those codebases were easier to read than the 50k lines of Golang code I sometimes had to deal with that pulled in 30+ dependencies and implemented all sorts of work around.

The Java code had proper errors and stacktraces so debugging what went wrong was easy. They also wrote their logs to rotated files in a structured format. And the Golang code just wrote to standard output.

Was the Go code simpler? Yes. Could a Junior Developer start working on it faster? Yes. Could I fix an issue quicker in the Java applikation than in the Golang applikation, oh very much yes.

Lack of stacktraces in the errors

Stacktraces are possible, but they have to be handrolled in the error handling. You need to make a log statement before returning an error, and in that log you need to make sure the line number, function name, file name, etc... are all used.

Lack of Function Overloading

This one really doesn't have any good excuse. I've seen people when they implement a function immediately implement up to eight different versions of it, with the argument type in the name of the function. addInt, addString, addFloat32, addFloat64, addFloatVector, add ... and so forth. And this pattern extends throughout all of the source code with little explanation.

It's standard library isn't "All you need"

It's a myth I was told often when I started. "You only need the STD seriously! Just get a package for the database driver"

Then we needed to talk to SOAP Web Service

With assymetrically signed digital signatures in XML

Then we needed to handle various web security features, and we basically had to handroll each and every one of them. Admittedly this was many years ago.

Then we needed transaction management with multiple databases

The mess of dependencies I see in some Go projects, dependencies that themselves have dependencies, is starting to remind me of Javascript community's "Did you know there's a library for that; Left padding!" chaos. Thankfully Golang devs seem just a little bit more restrained.

Lack of Generics

A collection is a collection, is a collection, is a collection. We shouldn't have to create fourty different types of a box, if all it has to do is contain items and make them accessible.

Java only barely does this right, C# is even better (no type erasure)

The lie that it is more performant than Java or C#

Both Go and Java/C# are garbage collected programs

Go has faster startup time, but while running it does tend to use more CPU

Java and C# tend to use more RAM and have slower startup time

With Java the startup time can be mitigated significantly with GraalVM, I recently demoed a Spring Java APP with 0.002s startup time and no "warm up"

The "Idiomatic" Go excuse

I'll understand what this means the day I comprehend what the "Pythonic Way" is. I'm always willing to discuss specifics, but the above comes off as someone waving their arms and being vague about not liking certain features.

Golang developers disagree internally about what "Idiomatic" Go is.

One Senior Golang developer once told me that copy-pasting Golang code is the idiomatic approach! :O