←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 #
h4ck_th3_pl4n3t ◴[] No.45671891[source]
Oh boi, all my RW mutexes for maps across goroutines would disagree.
replies(1): >>45672481 #
gethly ◴[] No.45672481{3}[source]
Use sync.Map or create simple wrapper to control access.
replies(1): >>45674040 #
mook ◴[] No.45674040{4}[source]
… the documentation for sync.Map literally says:

> The Map type is specialized. Most code should use a plain Go map instead, with separate locking or coordination, for better type safety and to make it easier to maintain other invariants along with the map content.

The documentation basically says that it's optimized for some cases that wouldn't affect the complaint above.

replies(2): >>45674709 #>>45676715 #
1. gethly ◴[] No.45674709{5}[source]
If you want to be pedantic, you can use https://github.com/puzpuzpuz/xsync which has generics and is faster than native sync.Map