3 ms·

> Golang has a whole lot of weird, pointless quirks in both its base language and standard library Having used go in anger I don’t necessarily agree with this,

by jpc0 1y ago

> Golang has a whole lot of weird, pointless quirks in both its base language and standard library 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.

vips7L 1y ago
Here’s a great read on its quirks, and where it really isn’t “simple”: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... https://dave.cheney.net/2014/03/19/channel-axioms https://dave.cheney.net/2014/03/19/channel-axioms
- Mawr 1y ago
  Your "great read" is horrible.
  - whytevuhuni 1y ago
    From HN's guidelines: > 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.
    - vips7L 1y ago
      Golangers really don’t like any criticism of their language.
- 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.

by jpc0 1y ago

vips7L 1y ago

Here’s a great read on its quirks, and where it really isn’t “simple”: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... https://dave.cheney.net/2014/03/19/channel-axioms https://dave.cheney.net/2014/03/19/channel-axioms

Mawr 1y ago
Your "great read" is horrible.
- whytevuhuni 1y ago
  From HN's guidelines: > 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.
  - vips7L 1y ago
    Golangers really don’t like any criticism of their language.
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.