
conc
A Go library that makes goroutine handling safer: scoped waits, panic capture, and simple worker pools.
- Stars
- 10.4k
- Forks
- 366
- Licence
- MIT
- Language
- Go
- Last update
- 2 months ago
- Type
- Library
What it is
conc is a Go library for running concurrent work in a more structured way. Its main type, WaitGroup, makes every goroutine have an owner that must wait for it, which helps prevent leaked goroutines. It also catches panics in spawned goroutines and re-raises them on Wait(), with a stack trace, so failures are not silently lost.
- Replace a sync.WaitGroup with conc.WaitGroup so panics in workers surface on Wait()
- Run a set of tasks with a maximum number of concurrent goroutines using pool.Pool
- Collect results from concurrent tasks with pool.ResultPool
- Cancel remaining tasks when one fails using a context-aware pool
Great for
- Go developers who use goroutines in long-running services
- Teams that want fewer leaked goroutines and clearer concurrent code
- Developers who need a concurrency-limited task runner or ordered parallel streams
Not ideal for
- Non-Go users, since it is only a Go package
- Projects that need only the standard library and want no dependencies, because the README does not discuss dependency footprint
- Beginners learning Go basics, as the library assumes familiarity with goroutines and sync.WaitGroup
How to get it
- 1
Install with a package manager
You'll need: Go
Add the library to your Go project
go get github.com/sourcegraph/conc - 2
Run it
- Install the package with go get in your Go module
- Import github.com/sourcegraph/conc in your code
- Replace a sync.WaitGroup with conc.WaitGroup and call wg.Go for each task
- Call wg.Wait() to block until all tasks finish and re-raise any panic
- 3
Get the most out of it
- Use pool.New().WithMaxGoroutines() to cap concurrency for limited resources
- Use pool.NewWithResults to collect task output in a concurrent pool
- Use WithErrors or WithContext pools when tasks can fail and should cancel on first error
- Use iter.Map or iter.ForEach to parallelize operations over slices
- Use panics.Catcher when you want to catch panics in your own goroutines
Downloads
Strengths
- Goroutines have a clear owner, which makes leaks easier to avoid
- Panics in spawned goroutines are caught and reported with a stack trace
- Common patterns like worker pools and parallel map are provided as short APIs
Trade-offs
- Library only; it does not run as a standalone program
- The README is truncated, so full API coverage and version stability are unclear from this source
- Latest release v0.3.0 has no binaries, which is normal for a Go library but worth knowing
How it compares
| Project | Stars | Type | Level | Updated | Best for |
|---|---|---|---|---|---|
| conc (this) | 10.4k | Library | intermediate | 2 months ago | Go developers who use goroutines in long-running services |
| ants | 14.5k | Library | intermediate | 2 months ago | Go developers who need to limit concurrent goroutines in a service |
| go-zero | 33.4k | Library | intermediate | 5 days ago | Go developers building REST APIs or microservices |
| kit | 27.4k | Library | advanced | 2.3 years ago | Go developers building service-oriented or microservice backends |
| kratos | 26k | Library | intermediate | 5 days ago | Go developers building a set of backend services that talk over HTTP or gRPC |
| zap | 24.7k | Library | beginner | 2 months ago | Go developers building services that log heavily |
Stats synced from GitHub. The assessment above was drafted with AI from the project's README on 2026-10-29 and may miss recent changes — check the README before relying on a command. MIT licence: free to use, modify and distribute, including commercially, as long as you keep the copyright notice.