3 ms·
> A send to a closed channel panics And the related read is purely a misunderstanding about how concurrency is modelled. Channels are not meant to be written f
by jpc0 1y ago
> A send to a closed channel panics
And the related read is purely a misunderstanding about how concurrency is modelled. Channels are not meant to be written from multiple writers, maybe this gets discussed in the next article. I can understand why it is confusing and you consider it unintuitive.
The read situation is literally not understanding or even looking up the interface, there is another return value that will tell you the channel is closed.
Nil channel reads make sense for it to do what it does if your familiar with the interface but at the same time you are literally holding it wrong. Vs a language where that would be UB its an improvement. Compared to a language like rust sure the information isn’t available at compile time but on the same not you would need to be developing in rust, and no offence but if you think golangs concurrency story is difficult to grasp just wait until you meet async rust…
These are the unintuitive, these are generally complaints of you failed to even begin to read the documentation and then complain when things aren’t doing what you expect, leave your preconceived notions at the door and you will be fine.
The faster than lime take needs to be updated, comparing golang from 5 years ago to modern golang is about as useful as comparing rust fron 5 years ago to rust now.
And you can happily make Cgo calls to the windows libraries if you want to access windows APIs, the language provides an abstraction for the normal use case not the specific use case, theres an escape hatch if you want it. And regarding the complaint about timeouts, context is a thing.
Because you don’t know how doesnt mean it’s unintuitive, it means you don’t know how.
- vips7L 1y ago> And you can happily make Cgo calls to the windows libraries if you want to access windows APIs, the language provides an abstraction for the normal use case not the specific use case, theres an escape hatch if you want it. And regarding the complaint about timeouts, context is a thing. Not having to call into ffi/c libraries to modify files is the normal use case. Windows is the largest used operating system. > Because you don’t know how doesnt mean it’s unintuitive, Do you know what the definition of unintuitive is? If it was intuitive you wouldn’t be able to “hold it wrong”.
- jpc0 1y ago> Not having to call into ffi/c libraries to modify files is the normal use case. A “systems” language designed by some smart people that is mostly targeted at the most deployed os in the world “cough not windows”, definitely does not need to make windows the default. > If it was intuitive you wouldn’t be able to “hold it wrong No unintuitive means if you understand the domain and idioms yet the interface still does not make sense. Returning multiple values when reading and passing context around (even in a wrapper) is normal intuitive golang. So is allocating complex object instead of simply instantiating them, sure this point is slowly moving out of idiomatic golang but at the same time the history is important. Not understanding CSP and not liking explicit return values does not mean it is unintuitive.
- vips7L 1y agoI never said Windows should be the default. I implore you to please actually reread what I said and the article. Having to call into ffi to work with files on a major operating system is not normal. It is valid to criticize these decisions whether or not it’s a “systems” language made by “smart people”. I can see this conversation will go no where though. This is the typical conversation with Go users when you point out any criticism of the language. Cheers man.
- jpc0 1y ago> Having to call into ffi to work with files on a major operating system is not normal. You don’t. Normal operation like reading writing modifying and creating works just fine in windows. The only thing that doesn’t is explicitly permissions where windows is the outlier and uses (imho a better) method of managing permissions. However they are the outlier and it is an uncommon operation. Why would the stdlib cater for that? If you need to alter permissions at a more granular level on windows than is possible using golangs interface then call into the ffi, but in general you don’t need to to that. If that is your only criticism then I agree we will not agree on this point, it is however also trivial to make ffi calls using go