Go is more than a language; Go is a platform(eltonminetto.dev) |
Go is more than a language; Go is a platform(eltonminetto.dev) |
We would have to call pretty much all languages platforms if so. The list of things called out is not unique in any way to Go.
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.
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.
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.
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.
It's nice that Go includes a tool for finding race conditions or vulnerability checking with govulncheck but the overall claim is more marketing than a factual assessment of "Go".
Wait until it is time for Go2.0. until then it is comparison of minor vs. major versions.
Overall, this is not a platform description. This is fanboying over ecosystem richness. I'm glad for the author that they've found something they like, but they are a bit off the mark in the post.
Stability guarantees are never absolute, and can only be evaluated in retrospect. At this point, python 3.x on its own has just as much history of stability as the entire Go language, along with cultural agreement of “let’s never do that again”. On the other hand, if Google had an internal goal that was most easily met by breaking backwards compatibility in Go, I would be very surprised if Go didn’t make that change.
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.