Thanks Ian, it's nice to know that we're using Go correctly.
I agree that more code doesn't really matter, and I think I'd be completely
fine with this situation had there been a vet check that ensured that no
selects are forgotten.
Let's see if generics change something in this area.
On Monday, June 8, 2020 at 10:46:05 PM UTC+3, Ian Lance Taylor wrote:
>
> On Mon, Jun 8, 2020 at 9:59 AM Yegor Roganov <yego...@gmail.com
> <javascript:>> wrote:
> >
> > My team is developing a cloud-based data processing application, and a
> large bulk of the application's job is doing network calls to other
> services.
> > Go's goroutines and channel-based communication are an excellent fit,
> but in order for the application to be able to properly shut down,
> > simple construct of sending to a channel `myChan <- value` needs to
> actually be something like:
> >
> > ```
> >
> > select {
> > case myChan <- value:
> > case <-ctx.Done():
> > return ctx.Err()
> > }
> >
> > ```
> >
> > As you see, a simple one line construct needs to be replaced with a
> select on context.Done EVERYWHERE.
> > My two gripes with this situation are:
> >
> > 1) It's more code and "clutter" which makes code less clear
> > 2) It's easy to forget to do a select on context.Done, and then an
> application is unable to shut down.
> >
> > Am I doing something wrong? Does someone relate with me?
>
> You are not doing anything wrong, and, you're right: it's more code.
>
> In general, Go prefers code to be explicit rather than implicit, so I
> don't really agree that this makes the code less clear. I think that
> this code is clear to anybody who knows Go, and with more experience
> it becomes fairly idiomatic.
>
> But you're absolutely right that it's easy to forget to do a select.
>
> Personally I think that this is an area where generics can help. For
> example, from the design draft published last year, see
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-contracts.md#channels
>
> . I think the right step here is going to be see how generics can
> help with these common patterns before trying other approaches. I
> acknowledge that that is a slow process.
>
> Ian
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/5e27f46d-44c9-41b1-a49e-c51021e0e906o%40googlegroups.com.
