4 ms·

To be pedantic, Go strings are immutable and will carry different pointers to different underlying rune slices, so the reader would just display one string or t

by caeril 3y ago

To be pedantic, Go strings are immutable and will carry different pointers to different underlying rune slices, so the reader would just display one string or the other, not "Susan Sarcemin". That said, I'm not sure why developers freak out over races so much. Races that result in simple display of data that's one nanosecond old is typically not a failure condition in most applications. Actual failure conditions from races are usually from read-operate-writes like increments/decrements/etc. And for these, we have tons of solutions, anywhere from atomics to transaction contexts to CRDTs, etc.

tialaramex 3y ago
> I'm not sure why developers freak out over races so much In all languages if you cause a data race you lose Sequential Consistency. Java's experience teaches us that even if you go to extraordinary lengths to ensure that everything else is still fine, programmers cannot reason about non-trivial software without Sequential Consistency and so now they can't fix it. In something like C or C++ all races are Undefined Behaviour, all bets are off. In Go as we saw some data races aren't immediately dangerous but even if you're careful you do lose Sequential Consistency and so good luck doing anything when you don't understand what your program means any more. > And for these, we have tons of solutions If you put the solution in place and thus prevent a data race, you don't have a data race. Now, when was the last time you wrote a program in which you got everything right first time?
- GoblinSlayer 3y ago
  Do you need to imagine a vulnerability when we have a CVE database?
tialaramex 3y ago
> To be pedantic, Go strings are immutable and will carry different pointers to different underlying rune slices, I wasn't thinking specifically about Go for this example, but alas Go's strings aren't trivial objects, and so this data race would be immediate UB in Go, whereupon "Susan Sarcemin" while still very unlikely is not impossible. The text (underlying rune slices? really? I guess that would be on brand but it's a bad idea) isn't getting mutated, but your string typed value is, and that is a non-trivial object.

by caeril 3y ago

tialaramex 3y ago

> I'm not sure why developers freak out over races so much In all languages if you cause a data race you lose Sequential Consistency. Java's experience teaches us that even if you go to extraordinary lengths to ensure that everything else is still fine, programmers cannot reason about non-trivial software without Sequential Consistency and so now they can't fix it. In something like C or C++ all races are Undefined Behaviour, all bets are off. In Go as we saw some data races aren't immediately dangerous but even if you're careful you do lose Sequential Consistency and so good luck doing anything when you don't understand what your program means any more. > And for these, we have tons of solutions If you put the solution in place and thus prevent a data race, you don't have a data race. Now, when was the last time you wrote a program in which you got everything right first time?

GoblinSlayer 3y ago
Do you need to imagine a vulnerability when we have a CVE database?

tialaramex 3y ago

> To be pedantic, Go strings are immutable and will carry different pointers to different underlying rune slices, I wasn't thinking specifically about Go for this example, but alas Go's strings aren't trivial objects, and so this data race would be immediate UB in Go, whereupon "Susan Sarcemin" while still very unlikely is not impossible. The text (underlying rune slices? really? I guess that would be on brand but it's a bad idea) isn't getting mutated, but your string typed value is, and that is a non-trivial object.