←back to thread

Go subtleties

(harrisoncramer.me)
235 points darccio | 3 comments | 13 Oct 25 07:42 UTC | HN request time: 0.656s | source
Show context
valzam ◴[22 Oct 25 09:24 UTC] No.45666643[source]▶
Great list of why one can love and hate Go. I really did enjoy writing it but you never get the sense that you can be truly certain your code is robust because of subtle behaviour around nil.
replies(3): >>45666654 #>>45667227 #>>45671606 #
valzam ◴[22 Oct 25 09:26 UTC] No.45666654[source]▶
I guess as a corollary, Go really rewards writing the dumbest code possible. No advanced type shenanigans, no overuse of interfaces, no complex composition of types. Then you will end up with a very fast, resource light system that just runs forever.
replies(5): >>45666706 #>>45666893 #>>45669853 #>>45671891 #>>45672663 #
theshrike79 ◴[22 Oct 25 09:34 UTC] No.45666706[source]▶
And code with zero ability to do fancy trickery ("expressive" as some people like to say) is easy to read even if the codebase - or even the language - is unfamiliar.

Which is really handy when shit's on fire and you need to find the error yesterday. You can just follow what happens instead of trying to figure out the cool tricks the original programmer put in with their super-expressive language.

Yes, the bug is on line 42, but it does two dozen things on the single line...

replies(3): >>45667256 #>>45672153 #>>45673868 #
spoiler ◴[22 Oct 25 10:53 UTC] No.45667256[source]▶
I know it's not exclusive to Go or any language, but you can most certainly write incomprehensible code in it. If anything, expressiveness and proper abstractions can save you from this.

I think people often get burnt by bad abstractions in expressive languages, but it's not a problem of the language, but the author's unfamiliarity with the tools at their disposal.

If someone starts being clever with abstractions before understanding the fundamentals, it can lead to badly designed abstractions.

So I guess if there's less things to master, you can start designing good abstractions sooner.

So, in my experience, if we invest time to truly understand the tools at our disposal, expressive languages tend to be a great boon to comprehension and maintenance.

But yes, there's definitely been times early in my career where I abstracted before I understood, or had to deal with other bad abstractions

replies(3): >>45667769 #>>45669041 #>>45669329 #
DanielHB ◴[22 Oct 25 12:01 UTC] No.45667769[source]▶
I like to say this: "Only my code is allowed to be clever"

But, on a serious note, I agree with you. Go lacks a lot of power, especially in its type system, that causes a ton of problems (and downtime) that in other languages is trivial to prevent statically.

replies(2): >>45672342 #>>45673110 #
1. 9rx ◴[22 Oct 25 18:20 UTC] No.45673110[source]▶
Formal proof languages are pretty neat, but nobody really uses them in the real world. Among the languages that people actually use on a normal basis, even those that claim to have extensive type systems, they still rely on testing for most everything, and once you're relying on testing anyway the type system isn't any kind of real saviour.

There is, perhaps, some segment of the developer community who believe that they are infallible and don't need to write tests, but then have the type system exclaim their preconceived notions are wrong, and then come to love the type system for steering them in a better direction, while still remaining oblivious to all the things the incomplete type system is unable to statically assert. But that's a rather bizarre place to be.

replies(1): >>45674447 #
2. tyre ◴[22 Oct 25 20:05 UTC] No.45674447[source]▶
Typescript’s type system is a huge leap up from JavaScript.

You still need tests for functionality (this function does what it should) but the type system removes many error cases automatically.

replies(1): >>45676595 #
3. 9rx ◴[22 Oct 25 23:48 UTC] No.45676595[source]▶
It is a huge boost in developer ergonomics.

But doesn't change the tests you need to write, and those tests are going to incidentally cover anything the type system is also going to catch, so the type system isn't going to somehow make your software more reliable.

A much more expressive type system can get you there, but you won't find that in any language anyone actually uses on a normal basis.