Re:Making a Go program 70% faster with a one character change
by robotresearcher on Monday November 14, 2022 @04:24PM
(#33601336)
If you take the position that the semantics of read() are 'read data from this endless stream', then EOF is an error indicating that this model no longer applies.
Doesn't bother me at all.
Re:Making a Go program 70% faster with a one character change
by account42 on Tuesday November 15, 2022 @04:42AM
(#33607156)
Except in that model it would be fine to return an error as soon as soon as you know there is an EOF while in the real world you do want to read right up to the EOF because EOF is usually not an error condition but expected, even with streams of indeterminate length.
Re:Making a Go program 70% faster with a one character change
by robotresearcher on Tuesday November 15, 2022 @11:30AM
(#33611296)
The model is that you don’t know there’s an EOF until you’ve read the last byte.
Re:Making a Go program 70% faster with a one character change
by bouncycastle on Wednesday November 16, 2022 @07:36AM
(#33622059)
But that's what "errors" are, the're signals.
I like Go's multiple returns and error checking by default, but it definitely should have been implemented with some sort of "Result/Error" type union instead. Go made so many good decisions, that I am frankly amazed they made this one really bad one.