Live data from Hacker News

The 4-chan Go programmer

dolthub.com

151–160 of 177 posts

Re: The 4-chan Go programmer

#151
post #42

Earlier quoted context omitted.

when I was learning Go, I read a guide that told you to fire off a goroutine to walk a tree and send the values back to the main goroutine via a channel. I think about that "just an example" guide a lot when I see bad channel code. For me the biggest red flag is somebody using a channel as part of an exported library function signature, either as a param or a return value. Almost never the right call.

> when I was learning Go, I read a guide that told you to fire off a goroutine to walk a tree and send the values back to the main goroutine via a channel. Okay, I gotta ask - what exactly is wrong with this approach? Unless you're starting only a single goroutine[1], this seems to me like a reasonable approach. Think about recursively finding all files in a directory that match a particular filter, and then performi…

Assuming latest Go 1.13 I would write an iterator and used goroutines internally.

The caller would do:

    for f := range asyncDirIter(dir) {
    }
Better than exposing channel.

But my first question would be: is it really necessary? Are you really scanning such large directories to make async dir traversal beneficial?

I actually did that once but that that was for a program that scanned the whole drive. I wouldn't do it for scanning a local drive with 100 files.

Finally, you re-defined "traversing a tree" into "traversing a filesystem".

I assume that the post you're responding to was talking about traversing a tree structure in memory. In that context using goroutines is an overkill. Harder to implement, harder to use and slower.

Re: The 4-chan Go programmer

#152
post #151

Earlier quoted context omitted.

> when I was learning Go, I read a guide that told you to fire off a goroutine to walk a tree and send the values back to the main goroutine via a channel. Okay, I gotta ask - what exactly is wrong with this approach? Unless you're starting only a single goroutine[1], this seems to me like a reasonable approach. Think about recursively finding all files in a directory that match a particular filter, and then performi…

Assuming latest Go 1.13 I would write an iterator and used goroutines internally. The caller would do: for f := range asyncDirIter(dir) { } Better than exposing channel. But my first question would be: is it really necessary? Are you really scanning such large directories to make async dir traversal beneficial? I actually did that once but that that was for a program that scanned the whole drive. I wouldn't do it for…

> In that context using goroutines is an overkill. Harder to implement, harder to use and slower.

I agree with this, but my assumption was very different to yours: that the tree was sufficiently large and/or the processing was sufficiently long to make the caller wait unreasonably long while walking the tree.

For scanning For even 20 files on a network filesystem, I'd make it async.

Re: The 4-chan Go programmer

#153

Earlier quoted context omitted.

> I realized that some junior engineer had been using some design pattern they didn't really understand, and that added zero actual value to the routine. £3.50p says it was the Generic Repository pattern implemented over Entity Framework dbContext, right? -------- Speaking of design-patterns, I subscribe to the opinon that _Design-patterns are idioms to work-around missing features in your programmign language_, whic…

FP has design patterns too, just different ones, and they don't all have tidy names. Also some GoF design patterns map pretty closely to FP equivalents... pattern-matching on ADTs + traverse/fold + ReaderT ends up looking a lot like the visitor pattern.

> pattern-matching on ADTs + traverse/fold + ReaderT ends up looking a lot like the visitor pattern.

...that sounds like hand-written tedium; isn't `replicate` meant to avoid that?

Re: The 4-chan Go programmer

#155
The irony of the comments in this thread decrying this as a classic example of too much abstraction is that the reason you rarely see three-star variables in C is that, while it's common to have long chains of pointers (and in languages where ~everything is a pointer~ most things are pointers by default, like Python, Java, or JavaScript, you definitely have pointer chains that are much longer than 4!), what is uncommon (but not nonexistent) is the need to manipulate more than two levels at once — you'll have one, maybe two, levels of pointers, but anything deeper is probably going to be hidden in a struct whose internals you don't have to care about (i.e. abstracted away). The same argument applies to channels, which are roughly to concurrent code what pointers are to sequential code: the fatal flaw here, if there is one, is not too much abstraction, but perhaps too little abstraction.

But then, I don't know the codebase — maybe a `chan chan` was exactly the right abstraction for what they were trying to write :) Certainly in highly-concurrent languages like Erlang, it is very standard practice to send a PID to another PID, for example to identify the process that should receive the reply to the message.

Re: The 4-chan Go programmer

#156

Earlier quoted context omitted.

There's an element of what you might call "taste" in choosing abstractions in software. Like all matters of taste, there are at least two things to keep in mind: (1) You can't develop good taste until you have some experience. It's hard to learn software abstractions, and we want engineers to learn about and practice them. Mistakes are crucial to learning, so we should expect some number of abstraction mistakes from…

A crucial thing to remember in a shared code base is that taste is ultimately subjective, and to let it go when people do something different from you so long as the code is understandable and not objectively incorrect. Remember you're making something functional at the end of the day, not ASCII art.

Yes absolutely. I think harmonizing with things around you is part of good taste. It's one of the things that separates for example a professionally designed interior from a college dorm room filled with an eclectic array of things the occupants like.

Re: The 4-chan Go programmer

#158
I did end up using a `chan chan` when implementing a threadpool: https://github.com/PeerDB-io/peerdb/pull/1613/files#diff-427...

The inner channel represents a future, while the outer channel is fed by threadpool workers to a finalization reader. This way the ordering doesn't get corrupted by parallelism

Re: The 4-chan Go programmer

#159
post #65

Earlier quoted context omitted.

I think something people forget is that computer programming is a craft which must be honed. A lot of people are introduced to it because computers are such an important part of every discipline, but unfortunately the wealth of mistakes maintaining many a code base occur from those who, quite honestly, simply lack experience. In the authors case, they don’t explain the simple understanding that every pointer is simpl…

”every pointer is simply adding a dimension to the data.” No, it’s not. The concept of having a pointer to a pointer has nothing to do with the concept of dimensionality. You must be thinking of lists of lists (of lists…), which can be implemented using pointers. The dimensionality, however, comes from the structure of the list, not from the pointers.

I guess you skimmed over: “Which is one way to interpret things”

I’m certainly not thinking of a list-of-lists. In actuality, pointers ARE dimensionality, regardless of the intended use.

I’m not going to spell that out further. If you can’t see that, then you’ve got some work to do if you’re maintaining a C codebase.

Re: The 4-chan Go programmer

#160
post #43

Earlier quoted context omitted.

Can someone explain this for people who don't want to do it?

You won't be scarred for life after searching for some random dude. You are on a hackers forum and are afraid of a web search?

I didn't even reference myself, first of all. Second of all, some people are at work or otherwise aren't in a position to click.
Post reply on HN