Jason, thanks for the reply and advice, but I don't think I wrote anything about the semantics of channels being ambiguous. I think your reply is taking the discussion a bit off-track
вторник, 19 августа 2025 г. в 04:16:20 UTC+3, Jason E. Aten: > Obviously channel semantics aren't ambiguous. > > Ruslan, channels do require perhaps an hour of careful study > and memorization to use effectively. > > You cannot yolo-code or guess your way to working with channels. There > isn't anything to build intuition on--nothing prior to compare to. > > You simply must memorize the rules for buffered and unbuffered channels, > both naked and inside a select statement. There is a 3x3 table for each. > See the link below. > > It helps to write little programs to test each scenario. > > You can see my notes and an exercise that should clear things up pretty > quickly here. > > https://github.com/glycerine/thinkgo?tab=readme-ov-file#channel-lifecycle > > Best wishes, > Jason > > > On Monday, August 18, 2025 at 9:28:02 AM UTC+1 Bushnell, Thomas wrote: > >> What part of the semantics of a channel are “ambiguous”? >> >> >> >> *From:* 'Axel Wagner' via golang-nuts <golan...@googlegroups.com> >> *Sent:* Sunday, August 17, 2025 6:45 AM >> *To:* Ruslan Semagin <pixel....@gmail.com> >> *Cc:* golang-nuts <golan...@googlegroups.com> >> *Subject:* Re: [go-nuts] Slice expansion in channel send statements (ch >> <- X...) >> >> >> >> This message was sent by an external party. >> >> >> >> On Sun, 17 Aug 2025 at 07:14, Ruslan Semagin <pixel....@gmail.com> wrote: >> >> What I meant to highlight is the *mental model* programmers already use: >> when reading `f(xs...)` it is commonly understood as “take all the elements >> and pass them along.” My thought was that `ch <- xs...` extends that same >> intuition into channel sends, even though the mechanics differ internally. >> >> >> >> So the comparison was more about readability and consistency from the >> user’s perspective >> >> >> >> I really do not think this is consistent semantically. ch <- x... means, >> in your suggestion >> >> >> >> ch <- x[0] >> >> ch <- x[1] >> >> … >> >> ch <- x[len(x)-1] >> >> >> >> That is not what f(x...) means at all. Functions don't even always range >> over their varargs - fmt.Printf, for example, really does use its argument >> as a slice with random accesses. >> >> >> >> In that sense, `ch <- xs...` is intended as a lightweight, expressive >> shorthand for a very common loop >> >> >> >> I also would like to say that in more than ten years of using almost >> exclusively Go, I think I have written that loop less than ten times. Of >> course, it all depends on what kind of Go code you write. >> >> >> >> But I would actually argue that if this is a very common loop to write, >> we are doing something wrong. I don't think people should use channels >> directly very often, because they have pretty ambiguous semantics and it >> tends to be hard to get channel code right. So if people very commonly >> (commonly enough to justify this language change) use raw channels, that's >> an indication that there probably is some easier to use primitive of >> structured concurrency (akin to errgroup.Group) that we are missing and >> should be adding instead. >> >> >> >> >> >> воскресенье, 17 августа 2025 г. в 02:25:47 UTC+3, Ian Lance Taylor: >> >> On Sat, Aug 16, 2025 at 1:21 AM Ruslan Semagin <pixel....@gmail.com> >> wrote: >> > >> > I understand the concern about implicit loops and the general bias >> against them in the language design. >> > My thought here was that this case might be closer to the existing >> slice expansion at call sites (f(xs...)). In both cases we’re conceptually >> saying “apply this operation elementwise.” One is a function call, the >> other is a channel send. >> >> But the function call is not applied elementwise. As I tried to >> explain, the slice is passed directly, not element by element. See >> https://go.dev/play/p/R4B1wHZMTuL. >> >> 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...@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/golang-nuts/9e3f90a5-5c3f-444f-a2b8-0b93840253d7n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/9e3f90a5-5c3f-444f-a2b8-0b93840253d7n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> -- >> 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...@googlegroups.com. >> >> To view this discussion visit >> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHXKxBxUfaWmYJkEdMT6nshYSkd%2B-K0Y45H2PoiRswdCQ%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHXKxBxUfaWmYJkEdMT6nshYSkd%2B-K0Y45H2PoiRswdCQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 visit https://groups.google.com/d/msgid/golang-nuts/6aea6960-cb1f-4aa5-84fd-2c2c31394d5an%40googlegroups.com.
