Am I using channels incorrectly with golang?

I've came from a Node.js background where its super easy to do some async work and then do some more work upon that long running task completing, and I'm sure its the same in Go but I just haven't quite wrapped my head around how channels work yet.

I'm building a parser for an old game that I play which analyses lines from auction data logs and parses them to stream to a live feed on a website over socket io. A file could send 100 lines at a time and my parser has to analyse each line one at a time and extract meta information from each line (such as the items, item prices etc.)

Each single line has this for loop run against it (this assumes the section where a list of items has been derived from a regexp):

itemChannel := make(chan Item)

for _, itemName := range itemList {
	item := Item {
		Name: itemName,
	}

    // Long running method which does parsing for the item such as pricing, quantity and makes some http calls (runs 75ms on average)
	go item.FetchData(itemChannel)

	// Read from the channel when its done
	raw := <-itemChannel
	auction.Items = append(auction.Items, raw)
	auction.Seller = seller
}

auctions = append(auctions, auction)
fmt.Println("Appended auction: ", auction)
go c.publishToRelayService(auction)

Right now (from observation) it seems as if raw := <-itemChannel causes the loop to block until the goroutine finishes and passes its data back (which surely means running as item.FetchData(itemChannel) would do the same thing. How can I read from the channel as data comes back into it but break out of the loop iterations as quick as possible. Some lines have 15-20 items in them which causes the program to halt for ~2-3 seconds before parsing the next line. I'd like to be able to break out and process the next line sooner than that to keep the parser as fast as possible. Is there any mechanism similar to Promises in Node where I can just chain a completion handler on to each completion of item.FetchData()?

NOTE fetchChannel is written to inside of my Item type when all fetch work has been completed.

You may write a different go routine that waits for new data in the channels and process it.
This way producer and consumer are running parallel and when the producer is done with producing consumer must be done as here the consumer is a light process

You can use a done channel to indicate that the consumer is done

Here is how you may change the code

itemChannel := make(chan Item)
done := make(chan bool)
//Consumer
go func(channel chan Item) {
	for raw := range channel {
		auction.Items = append(auction.Items, raw)
		auction.Seller = seller
		auctions = append(auctions, auction)
	}
	done <- true
}(itemChannel)

//Producer
for _, itemName := range itemList {
	item := Item{
		Name: itemName,
	}

	// Long running method which does parsing for the item such as pricing, quantity and makes some http calls (runs 75ms on average)
	go item.FetchData(itemChannel)

}

<-done
fmt.Println("Appended auction: ", auction)
go c.publishToRelayService(auction)

In terms of the broader question, moving from Node.js to Go/CSP channels, you need to start by putting aside thinking of callbacks. Every reactive/async paradigm I've used has been some form of dressing up of callbacks to be easy to use. But CSP does not try to be like this.

The key thing in Go that's different is that the cooperative scheduling of light-weight goroutines happens broadly independently of the operating system threads (although the implementers usually try hard to make this use the CPU cores as best as possible via OS thread tricks under the hood). There is no real comparison with actioning callbacks.

Each goroutines has its own independent life-cycle. It may be quite short. Or, if a goroutine includes some looping, it may exist for a period of time and look rather like an actor (in the actor model).

This is the thinking you need in order to explore Communicating Sequential Processes (CSP). Thinking of goroutines along the lines of digital electronics building blocks can also be a helpful analogy. Gates and wires are similar to goroutines and channels.

Also, flip-flops can be built from several gates - in the same way, goroutines can be composed from 'smaller' goroutines joined by internal channels. If you get this right, the external channels on the 'bigger' goroutine are the only thing of concern to its collaborators (the internal channels are hidden).

This opens up new ways for designing software and is one of the things that Rob Pike has advocated: Concurrency is not Parallelism. Think differently.

An example might be simulation software (Conway's Game of Life on a larger scale). I saw a very compelling simulation of blood flowing and clotting in blood vessels based upon modelling the individual behaviour of each cell involved. The demo had 40 million concurrent entities, a very impressive use of this approach, running on an ordinary laptop.