←back to thread

Go subtleties

(harrisoncramer.me)
234 points darccio | 1 comments | | HN request time: 0s | source
Show context
valzam ◴[] 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 ◴[] 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 ◴[] 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 #
1. cyberax ◴[] No.45673868[source]
Yeah, so pretty much every large project has concurrency bugs in Go. Because before generics, there was no way to write a parallel for-each loop without shooting yourself in the foot a couple of times.

Go is simple just like assembly is simple.