←back to thread

One year after switching from Java to Go

(glasskube.dev)
257 points pmig | 2 comments | 18 Feb 25 16:55 UTC | HN request time: 0s | source
Show context
owlstuffing ◴[19 Feb 25 00:35 UTC] No.43097059[source]▶
Going back to first principles, nominal typing is what I miss most with Go. I get the utility of structs + interfaces + structural typing, but most of the time there is more benefit in declaring that a type nominally implements an interface when that is the intention. Code is far easier to read and understand that way, both for developers and tooling.

I suppose exclusively structural typing would be more acceptable if Go supported _real_ interface composition, like Scala with traits or true delegation via the manifold project[1] for Java. But that's missing as well e.g., does not inherently fix the Self problem, etc.

Considering Go's initial goal, which was IIRC a better systems language, then yeah, sure it's an improved C. But now that Go is routinely compared with Java/Kotlin and friends, I personally don't see it, particularly wrt the type system, to be taken seriously as a Java contender. Shrug.

1. https://github.com/manifold-systems/manifold/blob/master/man...

replies(4): >>43097336 #>>43098207 #>>43100050 #>>43100109 #
1. dagss ◴[19 Feb 25 01:10 UTC] No.43097336[source]▶
Are you aware of the trick of "var _ foo.RequiredInterface = myType{}" to make the compiler enforce that a struct implements a given interface?

Is what you seek a nicer syntax for this or does what you speak of bring something more feature wise?

At least IntelliJ IDEs will always make it clear what interfaces all your structs implement.

replies(1): >>43098792 #
2. owlstuffing ◴[19 Feb 25 05:09 UTC] No.43098792[source]▶
>Are you aware of the trick

Yes, and while it uses the compiler to ensure a type implements an interface, it's still a trick that exposes a large hole in the language... and begs for it to be filled. Most importantly, it still doesn't make the code much easier to read and understand.

>At least IntelliJ IDEs will always make it clear (or less foggy)

Indeed. Go benefits hugely from IntelliJ, or to be specific the IJ plugin API.