Hacker News Reader

Comment by eptcyka | Hacker News Reader

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?

View on HN

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.

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

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

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

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.

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

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.

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.

You're right, and for some reason I thought that solution had been ruled out.

No. Channels sent over channel is the correct idiom here. No need for a sort.

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?

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

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.

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.

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

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.

How did idiomatic Rust make it hard to implement a doubly-linked list? I don't know Rust, so asking out of curiosity.

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/

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.

The memory ownership kinda expects all structures to be in a DAG (ie no cycles since ownership tracking doesn't understand that).

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.

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.

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

Reply on news.ycombinator.com