3 ms·
Except Go. "Go does have undefined behaviour: if your program has a race condition, the behaviour is undefined" -- Ian Lance Taylor, https://groups.google.com/
by knorker 3y ago
Except Go.
"Go does have undefined behaviour: if your program has a race condition, the
behaviour is undefined" -- Ian Lance Taylor, https://groups.google.com/g/golang-nuts/c/MB1QmhDd_Rk https://groups.google.com/g/golang-nuts/c/MB1QmhDd_Rk
It annoys me to no end how Go could be created in the 21st century and willfully ignore so many lessons from the state of the art in language design. The more code I read and write (basically every day, by good programmers), the more disappointed I am in how much of a missed opportunity Go is.
There are other fundamental flaws in Go, but that would be off topic.
- marcosdumay 3y agoThat's not a memory safety issue. And well, like people keep pointing on that discussion thread, C and C++ undefined behavior isn't just an operation you don't know the result; it's a much deeper and crazier thing that no other language has (unless when they inherit it by sharing compiling tools).
- knorker 3y agoTo your second point: Ian Lance Taylor explicitly says that Go has undefined behavior, which as you say is not just "don't know what it is". He (as he shows in this thread too) is, like me, very much aware of what UB is. He's even correcting people who are using the term "undefined" incorrectly. As for "memory safety", maybe you're right on the terminology. But this does mean that in Go a data race, being UB, can do anything. There are no guarantees of no use after free, or read/write out of bounds, anymore. If you create a data race in Go, you are in UB land. And that's one of the many many missed opportunities of Go.