> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
I'm curious to know why you think so, I thought it was a great article, showcasing how simplicity in the language doesn't make complexity go away, it just moves it to programs written in it.
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.
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”.
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 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.
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
Having used go in anger I don’t necessarily agree with this, could you point out an example. Maybe I just accepted it and work around it without paying much attention.
If you are referring to interface types being able to be null, well they are allocated on the heap and have dynamic dispatch, this isn’t particularly a surprise if you have worked in a lower level language but might be a surprise if you come from a language where that isn’t the case.