IMHO the discussed example is way better as it is now than complicating it with sync.WaitGroup.

• The functionality of sync.WaitGroup would have to be explained - in detail.
• sync.WaitGroup has issues the simple channel solution does not suffer from.

The full power of sync.WaitGroup does not have to be explained, just the restricted idiom of using it to count and wait on a known number of completion signals.

What are the issues that using sync.WaitGroup would have that the channel solution does not?

For this kind of synchronization(if using a channel), one would normally choose a chan struct{}, to make clear that one is only interested in the synchronization events and not the content transported through the channel. At least this could be changed.

It's rather easy to understand what's going on when sending 1 to a chan int. Some (many?) newbies may not have (yet) any idea what struct{} and/or struct{}{} even means.

Why make stuff less comprehensible? The discussed example is just fine as it is now. It's goal is to explain/illustrate some principle, not to teach how to write the most effective/performant/shortest/you-name-it code possible.

The example ought to at least close with a mention of WaitGroup. Otherwise newcomers (like myself) are left with the impression that Go's support for task-based parallelism is circuitous.

I think that's reasonable.