4 ms·

I love how most of the responses to this article here blame the author for wanting the wrong thing. One could implement a future struct that is awaitable and th

I love how most of the responses to this article here blame the author for wanting the wrong thing. One could implement a future struct that is awaitable and then the scaffolding to wait on a bunch of them. I have done things like this in other languages, it can be immensely useful. Similarly, when some wanted generics, they were bemoaned for wanting the wrong thing. Go is a wonderful language, even if it is not my cup of tea. But must its users be this defensive?

inopinatus 2y ago
it is possible they fear being replaced with a few lines of erlang
tptacek 2y ago
I don't think this is defensiveness so much as that attempting to model promises in languages like Go will result in bad, nonidiomatic code, and that is a thing that happens semiregularly with Go in particular, as it has so many refugees from other languages with sharply different idioms. Here, we're discussing implementing future structs just to print DNS results in order. I don't think the UX proposed in the post is good, but stipulate that it is; this is not a hard problem to solve in idiomatic Go.
- arethuza 2y ago
  "refugees from other languages with sharply different idioms" Reminds me of the time I had to decipher some numerical analysis code written in Common Lisp but in the style of Occam...
- surfingdino 2y ago
  > refugees from other languages with sharply different idioms Mostly Java or JavaScript devs unable to make a dent in their main programming language space looking for a shortcut to jump to a better paying job by pretending to make a huge difference to the other programming language. I cringe every time a frontend dev who hasn't fully grasped React yet utters the words "I hear Rust is the future. I am going to port a JS package to it..." They have already started making inroads into Golang with half-implemented modules.
- noapologies 2y ago
  > this is not a hard problem to solve in idiomatic Go. Genuinely asking, what would the solution look like in idiomatic Go? Let's assume for a second that the premise of the article is valid and exactly the behavior we want - "asynchronous execution but to report the results in order, as each becomes available".
  - logicchains 2y ago
    Send the results into a channel, with a separate goroutine that polls the channel, stores a buffer of results, and sorts and prints the latest results at a regular interval.
    - jcparkyn 2y ago
      > sorts and prints the latest results at a regular interval Slightly more complicated than that, because you can only sort and print elements once you have _all_ the elements that came before them. Once you add that layer you've got quite a lot more code (and potential for mistakes) than the promises version.
    - kbolino 2y ago
      You could also have N channels, one for each argument, and use reflect.Select to receive the results as soon as available, waiting to print any result until all of its predecessors have come in. You could also have a mutex-guarded block at the end of every worker goroutine to do the printing and a sync.WaitGroup to follow the workers in main.
      - yencabulator 2y ago
        No need for reflect.Select, just loop through the channels and wait on each. That'll do your "predecessors" part just by the sake that it's an in-order for loop.
        kbolino 2y ago
        You're right, and for some reason I thought that solution had been ruled out.
- 3np 2y ago
  Do you find OPs solution nonidiomatic? I do not. The sequence-number solution would probably have been fine too. How would an idiomatic solution look to you?
pif 2y ago
[flagged]
zer00eyz 2y ago
> But must its users be this defensive? Go is to programing what Brutalism is to Architecture. It is striped bare of everything down to the most basic of forms. It is structure is laid bare, put on display and free of decoration. If you come in and try to write Golang like other languages your going to be unhappy, your going to tell us how go sucks because NPM/PIP/Gems is better (a common lament). It's not defensive rolling up the news paper and wacking new devs to Golang and telling them "don't do it like its java/c/ruby/js/python do it like this..." Embrace the less is more of Go and it makes more sense and gets much more pleasant.
- tsss 2y ago
  I don't think that is a fair comparison for Brutalism. Programming's brutalism is more like Scheme: Simple, composable, sound and principled design. Golang is a "modern" McMansion: it tries to copy a modern style by unintelligently stripping away all ornamentation, but it doesn't understand the underlying theme of modernism and ultimately fails to achieve a coherent design.
  - patrickjd 2y ago
    This is the HN thread I didn't know I needed until I saw it. I often wonder how many of Brutalism's ardent fans grew up in an environment dense with Brutalist structures. I'm not here to bash the movement (the finest examples are wonderful) but just a reminder that the median Brutalist building is often a bleak, bleak affair. There's probably an analogy in there somewhere for programming too. Perhaps the best of Golang is wonderful but the median just doesn't compare. ETA: Either way, thanks for the taking the discussion down this direction. Certainly made me chuckle.
- binkethy 2y ago
  Garbage collection screams: "look elsewhere if true brutalism is what you seek; maybe C or Pascal deserve that mantle more than a high level language like Go."
amelius 2y ago
Reminds me of how I once wanted to implement a doubly linked list in idiomatic Rust but then people started telling me that I shouldn't want to write that.
- lopatin 2y ago
  How did idiomatic Rust make it hard to implement a doubly-linked list? I don't know Rust, so asking out of curiosity.
  - Joker_vD 2y ago
    You can't very easily have two equivalently powerful pointers that point at the same node in Rust. It became somewhat of a meme in Rust community to the point that there is even a series called "Learn Rust With Entirely Too Many Linked Lists" [0]. [0] https://rust-unofficial.github.io/too-many-lists/ https://rust-unofficial.github.io/too-many-lists/
  - SkiFire13 2y ago
    Rust's ownership and borrowing rules really want tree-shaped data, i.e. where there are no cycles. But a doubly-linked list is exactly the opposite of that, each pair of adjacent nodes create a cycle.
  - whizzter 2y ago
    The memory ownership kinda expects all structures to be in a DAG (ie no cycles since ownership tracking doesn't understand that).
- 3np 2y ago
  I postponed my properly getting into Rust for way too long after inadvertently choosing to implement a doubly-linked list as an early learning excercise to familiarize myself with Rust ownership and mostly ending up confused and frustrated. Anything not involving recursive cyclic data structures turned out a lot more straightforward.
deleted 2y ago
[deleted]
binary132 2y ago
I think there are two parts to it. First, hating Go has been very popular with a certain segment who feel it’s not complicated enough to be useful, so maybe people are conditioned to be defensive. Second, Go had a huge hype wave, so a lot of clumsy, hapless users got into it, thinking it would make them into good programmers. These people tend to write bad articles and give Go a bad name as a “noob language” that’s hard to do useful things in. That makes clever, elite Go users want to signal how they’re not like the hapless bozo Go users who can’t get anything right. This phenomenon exists more broadly in computing and in general, but for some reason Go is a particularly concentrated microcosm of it.

inopinatus 2y ago

it is possible they fear being replaced with a few lines of erlang

tptacek 2y ago

I don't think this is defensiveness so much as that attempting to model promises in languages like Go will result in bad, nonidiomatic code, and that is a thing that happens semiregularly with Go in particular, as it has so many refugees from other languages with sharply different idioms. Here, we're discussing implementing future structs just to print DNS results in order. I don't think the UX proposed in the post is good, but stipulate that it is; this is not a hard problem to solve in idiomatic Go.

arethuza 2y ago
"refugees from other languages with sharply different idioms" Reminds me of the time I had to decipher some numerical analysis code written in Common Lisp but in the style of Occam...
surfingdino 2y ago
> refugees from other languages with sharply different idioms Mostly Java or JavaScript devs unable to make a dent in their main programming language space looking for a shortcut to jump to a better paying job by pretending to make a huge difference to the other programming language. I cringe every time a frontend dev who hasn't fully grasped React yet utters the words "I hear Rust is the future. I am going to port a JS package to it..." They have already started making inroads into Golang with half-implemented modules.
noapologies 2y ago
> this is not a hard problem to solve in idiomatic Go. Genuinely asking, what would the solution look like in idiomatic Go? Let's assume for a second that the premise of the article is valid and exactly the behavior we want - "asynchronous execution but to report the results in order, as each becomes available".
- logicchains 2y ago
  Send the results into a channel, with a separate goroutine that polls the channel, stores a buffer of results, and sorts and prints the latest results at a regular interval.
  - jcparkyn 2y ago
    > sorts and prints the latest results at a regular interval Slightly more complicated than that, because you can only sort and print elements once you have _all_ the elements that came before them. Once you add that layer you've got quite a lot more code (and potential for mistakes) than the promises version.
  - kbolino 2y ago
    You could also have N channels, one for each argument, and use reflect.Select to receive the results as soon as available, waiting to print any result until all of its predecessors have come in. You could also have a mutex-guarded block at the end of every worker goroutine to do the printing and a sync.WaitGroup to follow the workers in main.
    - yencabulator 2y ago
      No need for reflect.Select, just loop through the channels and wait on each. That'll do your "predecessors" part just by the sake that it's an in-order for loop.
      - kbolino 2y ago
        You're right, and for some reason I thought that solution had been ruled out.
3np 2y ago
Do you find OPs solution nonidiomatic? I do not. The sequence-number solution would probably have been fine too. How would an idiomatic solution look to you?

pif 2y ago

[flagged]

zer00eyz 2y ago

> But must its users be this defensive? Go is to programing what Brutalism is to Architecture. It is striped bare of everything down to the most basic of forms. It is structure is laid bare, put on display and free of decoration. If you come in and try to write Golang like other languages your going to be unhappy, your going to tell us how go sucks because NPM/PIP/Gems is better (a common lament). It's not defensive rolling up the news paper and wacking new devs to Golang and telling them "don't do it like its java/c/ruby/js/python do it like this..." Embrace the less is more of Go and it makes more sense and gets much more pleasant.

tsss 2y ago
I don't think that is a fair comparison for Brutalism. Programming's brutalism is more like Scheme: Simple, composable, sound and principled design. Golang is a "modern" McMansion: it tries to copy a modern style by unintelligently stripping away all ornamentation, but it doesn't understand the underlying theme of modernism and ultimately fails to achieve a coherent design.
- patrickjd 2y ago
  This is the HN thread I didn't know I needed until I saw it. I often wonder how many of Brutalism's ardent fans grew up in an environment dense with Brutalist structures. I'm not here to bash the movement (the finest examples are wonderful) but just a reminder that the median Brutalist building is often a bleak, bleak affair. There's probably an analogy in there somewhere for programming too. Perhaps the best of Golang is wonderful but the median just doesn't compare. ETA: Either way, thanks for the taking the discussion down this direction. Certainly made me chuckle.
binkethy 2y ago
Garbage collection screams: "look elsewhere if true brutalism is what you seek; maybe C or Pascal deserve that mantle more than a high level language like Go."

amelius 2y ago

Reminds me of how I once wanted to implement a doubly linked list in idiomatic Rust but then people started telling me that I shouldn't want to write that.

lopatin 2y ago
How did idiomatic Rust make it hard to implement a doubly-linked list? I don't know Rust, so asking out of curiosity.
- Joker_vD 2y ago
  You can't very easily have two equivalently powerful pointers that point at the same node in Rust. It became somewhat of a meme in Rust community to the point that there is even a series called "Learn Rust With Entirely Too Many Linked Lists" [0]. [0] https://rust-unofficial.github.io/too-many-lists/ https://rust-unofficial.github.io/too-many-lists/
- SkiFire13 2y ago
  Rust's ownership and borrowing rules really want tree-shaped data, i.e. where there are no cycles. But a doubly-linked list is exactly the opposite of that, each pair of adjacent nodes create a cycle.
- whizzter 2y ago
  The memory ownership kinda expects all structures to be in a DAG (ie no cycles since ownership tracking doesn't understand that).
3np 2y ago
I postponed my properly getting into Rust for way too long after inadvertently choosing to implement a doubly-linked list as an early learning excercise to familiarize myself with Rust ownership and mostly ending up confused and frustrated. Anything not involving recursive cyclic data structures turned out a lot more straightforward.

deleted 2y ago

[deleted]

binary132 2y ago

I think there are two parts to it. First, hating Go has been very popular with a certain segment who feel it’s not complicated enough to be useful, so maybe people are conditioned to be defensive. Second, Go had a huge hype wave, so a lot of clumsy, hapless users got into it, thinking it would make them into good programmers. These people tend to write bad articles and give Go a bad name as a “noob language” that’s hard to do useful things in. That makes clever, elite Go users want to signal how they’re not like the hapless bozo Go users who can’t get anything right. This phenomenon exists more broadly in computing and in general, but for some reason Go is a particularly concentrated microcosm of it.