It's not entirely clear to me when

[dense violet]

As an example, I was hoping that since dagger can identify Sleep5 and Sleep10 as dagger functions that it would handle the concurrency for me

func (m *mod) Sleep5() (string, error) {
    fmt.Println("In Sleep5")
    sa := time.Now()
    time.Sleep(5 * time.Second)
    fa := time.Now()
    return fmt.Sprintf("Slept for 5 seconds. \nStart: %v\nEnd: %v", sa, fa), nil

}

func (m *mod) Sleep10() (string, error) {
    fmt.Println("In Sleep5")
    sa := time.Now()
    time.Sleep(10 * time.Second)
    fa := time.Now()
    return fmt.Sprintf("Slept for 10 seconds. \nStart: %v\nEnd: %v", sa, fa), nil
}

func (m *mod) Sleep() (string, error) {
    fmt.Println("In Sleep")
    m.Sleep5()
    m.Sleep10()
    return "done!", nil
}

[queen pumice]

See https://github.com/dagger/dagger/issues/4766. Basically, think about requests. When you use a dagger method that requires ctx and returns an error you're making an API request then. If you're doing that multiple times in the same function for things that take a while to run and could run concurrently, then it pays to use the language's concurrency.

But it's best to rely on the lazy nature of the dagger client whenever possible. For example, if you're building a go app for multiple platforms, you can lazily declare that by adding the resulting binary dagger.File to a dagger.Directory.

Same with native go code, ok to use Go's concurrency to not block a dagger api request if necessary.

[dense violet]

Gotcha that generally makes sense and lines up with what I was thinking. If I'm making dagger api requests dagger should generally handle the concurrency for me. If I'm using native go code I should use Go's concurrency.

Thanks!

[queen pumice]

Yeah but to be clear, dagger handles concurrency per request. If you’re making multiple api requests you may need go’s concurrency to make them non-blocking.