Go is more than a language; Go is a platform | Hacker News Reader

Go is more than a language; Go is a platform

eltonminetto.dev

44 pointseminetto15 comments

No, it's not a platform, unless you want to redefine platform to mean "something with lots of supporting tools", instead of "something that other things run on top of".

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.

You only need to read as far as the first paragraph for confirmation that some Kool-aid was drunk in the production of this article.

Agree, but clickbaity title aside I think the main purpose of this article is to provide a good overview of golangs features and it did do a good job of that

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.

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

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.

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.

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.

If Go is a platform, every language is a platform, and so the term loses all meaning.

I mean, I doubt you'd consider brainfuck a platform...

It's a bit of a stretch because half of the tools are not part of the Go distribution, for instance IDEs like Jetbrains or VS Code. Also, other languages do have IDE support as well :) Other examples are Delve, SBOM generation tools or Sonar code scanning.

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

The word you want is not “platform” but “ecosystem”.

Not sure what makes a platform, but I found interesting that you can easily re-use packages from other repositories without having to explicitly be published as libraries

> Compatibility Promise: This makes choosing Go much safer, especially for companies, as it avoids the need for significant future refactorings, as happened from PHP 4 to PHP 5 or from Python 2 to Python 3, for example—more details on the language blog.

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.

It also ignores how young Go is as a language. It was released in late 2009, and is 14 years old. Python was first released in 1991. Python 3.0 was released in 2008 (17 years old), but the strong push for migration didn’t start until python3.4 in 2014 (23 years old).

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.

Reply on news.ycombinator.com