[jillesvangurp]

It's very similar to Java and the JVM in many ways. Curly braces, garbage collected, strong typing, etc. Which raises the question, if you could level up the Go platform with a more modern language where e.g. generics and typing are less awkward & verbose. For Java there have been a few languages that provided that. I'm doing a lot of Kotlin the last few years for example. Other languages are available.

And of course with a native compiler now maturing, Kotlin is increasingly becoming more suitable for exactly the kind of stuff Go is being used for. I've not done a lot with Go but enough to not be too impressed with it as a language. I'm more impressed with it as a platform though. So much so that I might tolerate the language even. I appreciate the wide availability of good libraries and components out there. The build tools. Great decisions to make formatting mistakes a compilation error, etc. There's a lot to like. But the language as such is a bit bare bones and somewhat verbose especially for things like error handling. IMHO the comparison with Java is actually very fair in that sense since it is also a bit dated and clunky at this point.

Whether Kotlin or some other language (Zig?) gets more popular for native development is of course an open question but there's no good reason why system programmers should not have more access to more modern language features.

[bobajeff]

>Whether Kotlin or some other language (Zig?) gets more popular for native development is of course an open question

I don't see how Kotlin and Zig are comparable for native development. Maybe electron/nodejs, Swift or C#.

How much is Kotlin even being used outside of Android these days?

As far as I'm aware Kotlin has no plans for anything meant to address embedded or kernel programming.

So I don't think it's as much of a open question currently.

[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.