> 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.
I 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.
> 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
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.