Re:Conc: Better Structured Concurrency for Go
by aetherane on Wednesday January 11, 2023 @09:42PM
(#34348473)
It seems unrealistic to assume that everyone on a reasonably sized team knows all of the subtle edge cases to avoid and never makes mistakes
Re:Conc: Better Structured Concurrency for Go
by erik_seaberg on Wednesday January 11, 2023 @10:24PM
(#34348785)
I can use reflect.DeepCompare(x, y) and live with false negatives, but maps will always use x == y and blow up for something as simple as adding a private cache or callback to a value.
Re:Conc: Better Structured Concurrency for Go
by erik_seaberg on Wednesday January 11, 2023 @11:21PM
(#34349151)
I can nag everyone to use reflect.DeepEqual and live with some false negatives, but maps always use k1 == k2.
Re:Conc: Better Structured Concurrency for Go
by Groxx on Wednesday January 11, 2023 @11:47PM
(#34349341)
There are also significant performance and behavior differences between the two.
They are not inter-changeable, nor can one replace the other.
Re:Conc: Better Structured Concurrency for Go
by ikiris on Thursday January 12, 2023 @02:45AM
(#34350401)
more specifically, it's really strange to hear of people doing equivalence checks on objects with structure. What are you expecting that comparison to do? I doubt it is doing what you think is happening, and is indeed risky of panics.
Re:Conc: Better Structured Concurrency for Go
by mappu on Monday January 23, 2023 @01:11AM
(#34486042)
This is days later, sorry, but - you can't use an interface as a map key, so this shouldn't apply, right?
Re:Conc: Better Structured Concurrency for Go
by erik_seaberg on Thursday January 26, 2023 @11:02PM
(#34542303)
https://go.dev/ref/spec#Map_types says that is allowed.
> If the key type is an interface type, these comparison operators must be defined for the dynamic key values; failure will cause a run-time panic.
this kind of thing is why deepcompare exists to begin with