[liampulles]

I come from a Java background and now work primarily in Go. I used Kotlin a bit also. I use Go to handle typical enterprise business usecases (backend for frontend, integration systems, etc)

Go is quite different from Java enterprise work (in my experience) in that it really favours plain, non-magical code with a relatively obvious control flow. You don't create controllers and repositories with annotations, but with plain old function calls.

I like this about Go. I like being able to actually see why my services and controllers, etc. are not being wired correctly. It means it takes longer to scaffold things, (though honestly it's always a practice of copying something similar and editting isn't it), but the benefit is that a lot more issues show up at compile time (during the "dev loop"). It's easy for me to debug and find issues, because again, the control flow is plain and obvious.

Please for the love of God let no one turn Go into an AOP driven development ecosystem the way Spring has for Java.

[jillesvangurp]

This is actually why I like Kotlin. Java without all that nonsense that you are complaining about. That stuff is there if you need it but not really used heavily if you use Kotlin frameworks. E.g. Ktor is a nice alternative to Spring and uses no annotations whatsoever. Or reflection. Or AOP. Declarative functions all the way down. But it does that in a clever way that minimizes boilerplate.

It's also why it works well outside the JVM where reflection and AOP are simply not available. Ktor can actually work with the kotlin's native compiler. It uses a lot of the multiplatform stuff that Kotlin has these days that works in wasm, browsers, on IOS, or indeed on Linux. There's no Java/JVM code involved at all when it that way. And a lot more lightweight than what people are doing with e.g. Graal.

[liampulles]

I'm glad to hear that, I'll bear this in mind if a kotlin opportunity comes up.

If we're still talking big differences with Go, then another big advantage for me is monorepo management in Go. The fact that I can declare a new binary by just making a new folder with a main.go file in it is huge. It makes it very easy to solve adhoc problems that come up by making a new tool that uses existing classes in my main service code. And it means that build times are not a consideration when thinking about adding new microservices, because Go's ability to cache compilation is very effective at making compilation near instant.

In defense of Java/Kotlin, I think writing tests and mocking things is significantly easier in that ecosystem - AOP really does help a lot in that arena IMO.