Re: [go-nuts] Packages vs methods

[温博格]

If one is using gopls for Go support for an IDE (like vscode), with
semantic tokens enabled, the two cases are colored differently. It's
incrementally cheap, as gopls already typechecks source.

[to enable in vscode: in settings, in the gopls section,
"ui.semanticTokens": true]

I don't know that this satisfies the request for 'an easy way'

On Tue, Apr 4, 2023 at 8:36 AM 'Axel Wagner' via golang-nuts
 wrote:
>
> This ist actually a syntactical difference. Both are syntactically just 
> selector expressions.
>
> So you'd need *semantic* highlighting, which not a lot of highlighters do. 
> One reason is performance and another is that it means highlighting might 
> fail for incorrectly typed (but syntactically valid) programs.
>
> And if one does, you can tell the difference between literally anything (on a 
> type level) - if you are willing to rely on highlighting to tell the 
> difference between an import and a variable, you can also use it to 
> differentiate between, say, an interface and a concretely typed variable. Or 
> an int and a float type. Or whatever.
>
> So in the context of the question, this strikes me as a pretty unhelpful 
> response. Yes obviously you can use a tool to *tell* you the difference by 
> performing a type check. But obviously the question was about a syntactical 
> way to do so.
>
> On Tue, Apr 4, 2023, 14:17 Reto  wrote:
>>
>> On Mon, Apr 03, 2023 at 10:19:49PM -0700, joseph.p...@gmail.com wrote:
>> > Is there an easy way to make
>> > this determination?
>>
>> Sure, use syntax highlighting in your favor.
>>
>> --
>> 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/mhisvutsz54nkickwqcxw4n2gqn3ccexnidng5i3p43qusxrkh%40tkbismvv64hz.
>
> --
> 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/CAEkBMfHVwhsrKjZNFWY3a4QukeJS_QP3hE%3DxF-aEKNt7GNZgQQ%40mail.gmail.com.

-- 
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/CAOUkXSpVY%2Bq%3DHGsBZGj8T_brZFATcBL__bignJEaq9gAZdZswQ%40mail.gmail.com.

Re: [go-nuts] A goroutine question

[温博格]

A 100-long vector is way too short to show any benefit. goroutines have
start-up, scheduling, and shut-down costs. What happens if you try to
square the largest matrix you can fit into memory (10,000 by 1?)

On Fri, Feb 19, 2021 at 9:46 AM Yuwen Dai  wrote:

> Hi experts,
>
> I'm a newbie to golang.  One of my first ideas to use goroutine is to
> write a matrix multiplying programme:  C = A*B.I though the calculating
> of  every element of C:  c[i][j] = row i of A  *  column j of B could be
> run by a goroutine.  This is the skeleton of the code:
>
> t1 := time.Now().UnixNano()  //benchmark
> rand.Seed(t1)
> for i := 0; i < n; i++ {
> ai,_ := get_row(a,i)
> for j := 0; j < t; j ++ {
> bj, _ := get_column(b,j)
> //c[i][j],_ = dot_product(ai, bj)
> go func(element *int, ai,bj []int) {
> *element,_ = dot_product(ai,bj)
> wg.Done()
> }([i][j], ai, bj)
> }
> }
>
> wg.Wait()  // waiting for all the elements have been calculated
> t2 := time.Now().UnixNano()
> fmt.Printf("the dot_product using goroutine costs %v\n", t2 - t1)
>
> As the goroutines will run "concurrently" on my laptop with 8 CPU cores to
> calculate the element of matrix, I thought the code would ran faster than
> not using goroutine.  In fact, it ran slowlier than not using goroutine.
> Any explanation of this?By the way,  the dimension of  matrix is
> 100x100.
>
> Best regards,
> Yuwen
>
> --
> 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/52ef6c0f-7044-4b7e-968c-b894eb52d374n%40googlegroups.com
> 
> .
>

-- 
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/CAOUkXSpvBq9ctKGwXC4VHT-xfBm2j4vsODnYgUgeO_ivbG-uSw%40mail.gmail.com.

Re: [go-nuts] What is The compiler's -json optimization logging

[温博格]

And gopls will compute them as diagnostics. For instance, if using vscode
and gopls, then in setting.json:
"gopls": {
  "codelens": {
"gc_details": true,
  }
}

and a clickable 'Toggle gc annotation details' should appear just above the
package statement.

On Fri, Sep 4, 2020 at 4:28 PM Ian Lance Taylor  wrote:

> [ + drchase ]
>
> On Fri, Sep 4, 2020 at 1:16 PM Falco Wockenfuß  wrote:
> >
> > sorry if this is a dumb question, but the Release Notes for go 1.15 have
> the Note:
> > The compiler's -json optimization logging now reports large (>= 128
> byte) copies and includes explanations of escape analysis decisions.
> >
> > But I didn't find anything about "-json" as a flag for go build or
> similar and google dind't yield anything for go compiler json optimization
> logging or similar.
> >
> > Can anyone clarify what this json optimiziation logging is and how it
> can be used/invoked ?
>
> It does seem that this option should be mentioned in cmd/compile/doc.go.
>
> To use it, try "go build -gcflags=json=0,/my/json/dir".
>
> 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/CAOyqgcVB-pJUf6AxSDsAqoEJbzBm_h7Qt4%2BTJyUg0mE63RyDcQ%40mail.gmail.com
> .
>

-- 
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/CAOUkXSr%3D9DRQ4qjjc4pfEha7QVqhuBntQrhz8TEmqtKqu%2Ba9Pw%40mail.gmail.com.

Re: [go-nuts] Re: keep just 2 decimal places in a float64

[温博格]

And from Wikipedia on the Vancouver Stock Exchange.
"The history of the exchange's index provides a standard case example of
large errors  arising from
seemingly innocuous floating point calculations. In January 1982 the index
was initialized at 1000 and subsequently updated and truncated
 to three decimal places on each
trade. Such a thing was done about 3000 times each day. The accumulated
truncations led to an erroneous loss of around 25 points per month. Over
the weekend of November 25–28, 1983, the error was corrected, raising the
value of the index from its Friday closing figure of 524.811 to 1098.892"

On Sun, Jan 26, 2020 at 11:20 AM Robert Engels 
wrote:

> Just an FYI, often that is not correct. Many financial systems require
> fractional pennies due to the volume of transactions. Think about taxing
> stock exchanges the pennies add up quickly at any tax rate, so they use
> fractional pennies to reduce the size of the error bucket.
>
> On Jan 26, 2020, at 8:50 AM, Pat Farrell  wrote:
>
> 
> never use floating point if you are trying to represent money, say dollars
> and cents or decimal values of the euro.
> Store the money as integer number of pennies.
>
> --
> 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/cc852ce3-6f88-40fd-8b19-877c76deec10%40googlegroups.com
> 
> .
>
> --
> 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/AF9827F5-C849-4F4E-8229-005D6C9A0E03%40ix.netcom.com
> 
> .
>

-- 
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/CAOUkXSptfibw5D4UqwORhZLH8%2BV9s24Os-SjSp5RH2OLUN%2Bn1g%40mail.gmail.com.

Re: [go-nuts] Get tmp stuff in $GOTMPDIR instead of /tmp?

[温博格]

This is routinely happening to me too, on linux. My go commands are go
build *.go
The left-over directories are empty
I'm on go1.12.5 linux/amd64

On Fri, Aug 23, 2019 at 10:04 AM Ian Lance Taylor  wrote:

> On Thu, Aug 22, 2019 at 7:55 AM  wrote:
> >
> > I get a bloated /tmp-dir (in just a few days I get tens of thousands of
> folders named /tmp/go-build828718408 etc.)
>
> That is odd in itself.  The go-buildN directories should normally
> be deleted when the go command completes.  Are you routinely killing
> your go commands before they complete and have a chance to remove the
> temporary directory?
>
>
> > so I tried to set $GOTMPDIR, but nothing ends up there. (From what I
> understand of the documentation the purpose of GOTMPDIR is to move tmp
> stuff, see e.g. line 1471 of
> https://golang.org/src/cmd/go/alldocs.go?h=GOTMPDIR, or release notes of
> 1.10 https://golang.org/doc/go1.10).
> >
> > Am I using things wrong?
> >
> > $ go version
> > go version go1.12.6 linux/amd64
> >
> > $ echo $GOTMPDIR
> > /tmp/go-builds
> >
> > $ ls $GOTMPDIR
> > please-end-up-here.txt
> >
> > $ go build/test/this/that/etc
> > [...]
> >
> > $ ls $GOTMPDIR
> > please-end-up-here.txt
>
> Setting GOTMPDIR should work.  What shell are you using?  Did you
> "export GOTMPDIR"?
>
> Note that, as mentioned above, an ordinary go build will create a
> temporary directory in GOTMPDIR and then delete it.  So it's normal to
> not see anything there after the go command completes.  You can verify
> the directory it uses by running "go build -work" (in which case it
> will not delete the temporary directory).
>
> 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/CAOyqgcU-U_2Rz6UB1TUijdVyRSR-BJxxQdXgGVbJz4dX2p3vaA%40mail.gmail.com
> .
>

-- 
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/CAOUkXSpJ-qDqR15JcQETYFnR9FJGGbiji-iRz_qJsAQyevN14w%40mail.gmail.com.

Re: [go-nuts] Generating LSP protocol Go types

[温博格]

I'm responsible for some of that code but other than that, I'm just giving
my personal opinion.  There's no fundamental reason it couldn't be public,
but,
1. They change all the time (weekly for some of it, more slowly for
tsprotocol.go, which follows the Microsoft code)
2. They are adapted to the repository's version of gopls, and changes in
gopls cause changes in these files.

One way to try things out is to clone the repository, and then in master,
add your own git project. It has access to the internal files, but you'd
push and pull it independently. That doesn't solve your problem, but maybe
it delays it.

On Sat, Jul 13, 2019 at 7:43 AM  wrote:

> Hi there,
>
> I am trying to write a Go client for gopls.  Ideally I would like to be
> able to to import a package that defines Go types for all the messages that
> can be sent to / received from the server, which is something that
> obviously the gopls server also has to do.  Unfortunately the protocol
> files are not in a public package (
> https://github.com/golang/tools/tree/master/internal/lsp/protocol
> ).
> There are instructions to generate the Go files at
> https://github.com/golang/tools/blob/master/internal/lsp/protocol/typescript/README.md
>  but
> they require some files from that repository so that is not very useful.
>
> Would it make sense for this to be extracted as a public package?  If so,
> how would I go about achieving this?  If not, what would be a sensible
> approach for me?
>
> Regards,
>
> Arnaud Delobelle
>
> --
> 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/8fdc691a-345a-4162-a6cf-2e9b5cb078ec%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAOUkXSqVC07hpiPty3Yvi3g79itOWfg%2Br2Oz96NztDA10%2BLbTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

[温博格]

I agree that ? for simple choices is nice. But my C experience with nested
?s and with long expressions for one or both branches has not been nice.
The mandatory {}s make Go's nested ifs more readable (but vertical).

On Wed, Jun 12, 2019 at 2:42 PM Michael Jones 
wrote:

> Roger, here's the same thing, but for Russ's corpus v0.01:
>
> https://gist.github.com/MichaelTJones/609589e05017da4be52bc2810e9df4e8
>
> I've been comparing the two side by side and it's fascinating.
>
> Bakul, more good arguments. I have another motivation in the "?" world
> that I've not argued because it is personal/not general, but a decade ago I
> had two detached retinas, surgeries, and imperfect recovery. Part of my
> vision that I lost is just below the center...maybe -15 degrees to -40
> degrees. The brain knows when I want to see things things there and moves
> the eyes around to gather that part of the visual field. This "hunting" is
> tiring of the muscles and causes issues. left-to-right density is easy for
> me, vertical is very bad. Your:
>
> x := b? 2 : 1
>
> is instantaneous, a sight read; while the:
>
> var x int
> if b {
>   x = 2
> } else {
>   x = 1
> }
>
> and
>
> x := 1
> if b {
>   x = 2
> }
>
> ...feel like climbing Everest. It is hard to explain the difficulty.
> Fortunately it is not a widespread problem. Certainly not Go's problem, but
> I'd pay double for a "wide" mode where gofmt tolerated "var x int; if b { x
> = 2 } else { x = 1 }". In fact, now that i've just seen this, I am going
> to make a local version and hook it to vs code. Why did I not think of this
> before! Wow.
>
> On Wed, Jun 12, 2019 at 9:24 AM Bakul Shah  wrote:
>
>> On Jun 12, 2019, at 8:24 AM, Michael Jones 
>> wrote:
>> >
>> > Bakul, these are good points.
>> >
>> > On the second, I used to always write (C/C++):
>> >
>> > If (things are good) {
>> > happy case
>> > } else {
>> > sad case
>> > }
>> >
>> > so the nesting was that the all-good was the first code block even when
>> multiply nested and the exceptions came later. A blunt kind of literate
>> programming that wants to talk about the 99% case first and the weird
>> things later. In Go I've converted to talk about problems all the way to
>> the bitter end and then when you run out of problems, do the job. Now that
>> you point it out, "else" falls by the wayside in this situation because it
>> is else when you did not return already. Each Go-style if-err-die "clause"
>> is consuming an else. Thank you. I had not thought of it so clearly.
>>
>> It's just a different style. Here you are chopping off "sad cases" until
>> you are left with the big fat happy case! And by returning ASAP for the
>> sad cases, you reduce indentation quite a bit, which helps readability.
>>
>> >
>> > The first is a good point too. The debate about the ternary operator
>> might be better viewed as a completion of short variable declaration. Block
>> scope means is not possible to write...
>> >
>> > if b {
>> > x := 1
>> > } else {
>> > x := 2
>> > }
>> > :
>> > use X
>> >
>> > ...so the benefits of short variable declaration are lost to a choice
>> between redundancy as you show:
>> >
>> > x := 1
>> > if b {
>> > x = 2
>> > }
>> >
>> > which hides the intent -- the if b is the intent and that's not evident
>> from x := 1. The intent is "x := either 1 or 2 depending" and that is well
>> expressible only when the := is in the outer scope and the "1 or 2" are
>> expressions from an inner one being transported across the lexical boundary
>> by an operator -- the "depending" operator whatever its name or form might
>> be.
>>
>> You can almost speed-read straight line code but as soon as you
>> encounter if or switch (or other control flow changing part) you
>> have to stop and regroup. This is why (for me)
>>
>> x := b? 2 : 1
>>
>> is far easier to read than either
>>
>> var x int
>> if b {
>>   x = 2
>> } else {
>>   x = 1
>> }
>>
>> or worse,
>>
>> x := 1
>> if b {
>>   x = 2
>> }
>>
>>
>> > x := {1,2}[b]
>>
>> This requires evaluating both alternatives. This may not
>> even be possible:
>>
>> x := p == nil? 10 : p.val
>>
>> or may had extra side-effects:
>>
>> x := {f1(), f2()}[b]
>>
>> This can also a problem with
>>
>> x := f1()
>> if b { x = f2() }
>>
>>
>>
>>
>
> --
>
> *Michael T. jonesmichael.jo...@gmail.com *
>
> --
> 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/CALoEmQw10H-t1GdVG_PDxiPVtaUGJ3uvsBUXyt6adMiPOAAnow%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google 

Re: [go-nuts] Re: adding context.Context to new code

[温博格]

the comment was for libraries without context parameters but which would
need to have them added.


On Sun, May 14, 2017 at 11:46 AM, Sameer Ajmani <sam...@golang.org> wrote:

> Specifically: don't pass nil Contexts. They are not valid, and most code
> that uses Contexts don't check for nil and will panic.
>
> On Sun, May 14, 2017 at 11:43 AM Sameer Ajmani <sam...@golang.org> wrote:
>
>> Generally I'd suggest passing context.Background() when calling functions
>> that need a context from main or tests.
>> On Sat, May 13, 2017 at 8:27 AM Peter Weinberger (温博格) <p...@google.com>
>> wrote:
>>
>>> Hi. I was one of the people who failed in an attempt to auto-insert
>>> contexts in all of google3. I no longer remember all the obstacles I failed
>>> to overcome, but would encourage others to take on the project.
>>>
>>> One issue was libraries that were used both in paths from http requests
>>> (so they needed the context propagated through them) but were also used in
>>> places where their callers (starting at main) didn't have any contexts at
>>> all. Sitting by my coffee this morning this no longer seems like an
>>> insuperable obstacle (e.g., pass nils and change them to
>>> context.Background() inside, or, like appengine's log, split packages into
>>> one that requires contexts and one that doesn't). But I had lots of what I
>>> thought were plausible ideas that broke on the hard rock of google3, and I
>>> suspect these would too.
>>>
>>> (The project wasn't a total failure. It did plumb contexts through a
>>> bunch of packages. But the general case was too hard for me.)
>>>
>>> On Sat, May 13, 2017 at 3:50 AM, <mhhc...@gmail.com> wrote:
>>>
>>>> A reference i found about "reactive programming"
>>>> https://github.com/dsyer/reactive-notes/blob/master/intro.adoc
>>>>
>>>> Hope this introduced the concept correctly, thanks for pointing that.
>>>>
>>>> Following are only some thoughts,
>>>>
>>>> Two things surprising here,
>>>> 1/ a programmer prefers not to solve a problem
>>>> 2/ one failed attempt mean the end of all attempts**
>>>>
>>>> That being said, my little understanding so far is that current context
>>>> is used for two purposes,
>>>> - cancellation
>>>> - data (transmission? not sure) (+/- ts, have not checked i expect so
>>>> in regards to previous referenceS cited)
>>>>
>>>> While cancellation is a feature i really want to take advantage of,
>>>> the other one is much more arguable in the sense that
>>>> it can remains expressed purely by the end user without bloating
>>>> his productivity and quality (you don t really need it everywhere, just
>>>> where it is needed),
>>>> it seems to be highly software context dependent.
>>>>
>>>> Whereas cancellation, while it looks likes simple, is maybe more subtle.
>>>> After all it is about assigning uuid to a chain of call and
>>>> appropriately propagate, disjoint/rejoin new uuids with the previous
>>>> one,
>>>> so that we can ask to stop execution of a sub selection of a chain of
>>>> calls
>>>> via an handle.
>>>> Am i too simplistic?
>>>>
>>>> Its difficulty reside in its requirement to be passed absolutely
>>>> everywhere,
>>>> That reveals an important fact about the nature of cancellation,
>>>> it is there, it is everywhere, at all time (...within the program
>>>> lifetime),
>>>> it is somewhere in the background of every ops since the very beginning
>>>> the program began,
>>>> but not necessarily enabled, and certainly not a straight line.
>>>>
>>>> That is where the syntax might help to establish the plots
>>>> that the runtime consumes to connect the dots
>>>> and support what the developers want to achieve,
>>>> in my understanding so far.
>>>>
>>>> My best comparison to cancellation is
>>>> request rays tracing in micro services oriented architecture,
>>>> on both end it is a multi-tenant,
>>>> it always start with one ray,
>>>> the ray always split into multiple rays,
>>>> because we do programming, we need ways
>>>> to create, control distribute existing/new rays,
>>>> and possibly let the userland introduce a new behavior for the rays.
&g

Re: [go-nuts] Re: adding context.Context to new code

[温博格]

Hi. I was one of the people who failed in an attempt to auto-insert
contexts in all of google3. I no longer remember all the obstacles I failed
to overcome, but would encourage others to take on the project.

One issue was libraries that were used both in paths from http requests (so
they needed the context propagated through them) but were also used in
places where their callers (starting at main) didn't have any contexts at
all. Sitting by my coffee this morning this no longer seems like an
insuperable obstacle (e.g., pass nils and change them to
context.Background() inside, or, like appengine's log, split packages into
one that requires contexts and one that doesn't). But I had lots of what I
thought were plausible ideas that broke on the hard rock of google3, and I
suspect these would too.

(The project wasn't a total failure. It did plumb contexts through a bunch
of packages. But the general case was too hard for me.)

On Sat, May 13, 2017 at 3:50 AM,  wrote:

> A reference i found about "reactive programming"
> https://github.com/dsyer/reactive-notes/blob/master/intro.adoc
>
> Hope this introduced the concept correctly, thanks for pointing that.
>
> Following are only some thoughts,
>
> Two things surprising here,
> 1/ a programmer prefers not to solve a problem
> 2/ one failed attempt mean the end of all attempts**
>
> That being said, my little understanding so far is that current context is
> used for two purposes,
> - cancellation
> - data (transmission? not sure) (+/- ts, have not checked i expect so in
> regards to previous referenceS cited)
>
> While cancellation is a feature i really want to take advantage of,
> the other one is much more arguable in the sense that
> it can remains expressed purely by the end user without bloating
> his productivity and quality (you don t really need it everywhere, just
> where it is needed),
> it seems to be highly software context dependent.
>
> Whereas cancellation, while it looks likes simple, is maybe more subtle.
> After all it is about assigning uuid to a chain of call and
> appropriately propagate, disjoint/rejoin new uuids with the previous one,
> so that we can ask to stop execution of a sub selection of a chain of calls
> via an handle.
> Am i too simplistic?
>
> Its difficulty reside in its requirement to be passed absolutely
> everywhere,
> That reveals an important fact about the nature of cancellation,
> it is there, it is everywhere, at all time (...within the program
> lifetime),
> it is somewhere in the background of every ops since the very beginning
> the program began,
> but not necessarily enabled, and certainly not a straight line.
>
> That is where the syntax might help to establish the plots
> that the runtime consumes to connect the dots
> and support what the developers want to achieve,
> in my understanding so far.
>
> My best comparison to cancellation is
> request rays tracing in micro services oriented architecture,
> on both end it is a multi-tenant,
> it always start with one ray,
> the ray always split into multiple rays,
> because we do programming, we need ways
> to create, control distribute existing/new rays,
> and possibly let the userland introduce a new behavior for the rays.
>
> So yeah basically main has a ray,
> if you process an http request,
> you to create a new ray
> to be able to cancel only that request,
> but it needs to be connected to the main ray
> because if main should be canceled,
> that signals should propagate to all rays connected with it,
> probably.
>
> ** i want to put emphasis because in the description provided
> by Sameer, as i tried to summarize, It has been tried to handle
> the problem via the type system as if it was
> a completely defined set of types.
> Which in go is wrong (yeah i m very affirmative here :),
> from my understanding, that might be correct in other oop languages.
> Technically it is possible to rewrite interfaces, methods signatures,
> taken individually,
> as a whole, and from the consumer pov,
> i d say it is an impossible task in go because it it goes against its
> nature.
> And i confirm/understand that by reading to Sameer feedback.
>
> Notes: i m a strong lover of go type system (not talking about values and
> pointers ;)
>
>
> On Friday, May 12, 2017 at 4:42:54 PM UTC+2, Henrik Johansson wrote:
>>
>> With the whole "Reactive" movement thread locals have started to vanish
>> at least in the Java ecosystem.
>> I agree with Sameer that, while convenient, it comes with a whole set of
>> obscure bugs.
>>
>> On Fri, May 12, 2017, 14:57 Sameer Ajmani  wrote:
>>
>>> Hmm, I'm not finding good open-source examples of ThreadLocal context
>>> propagation in C++ and Java.  My experience with this is based on what
>>> Google uses internally.  Perhaps someone more familiar with context use
>>> (tracing?) outside Google can chime in? +Jaana Burcu Dogan
>>>
>>> On Thu, May 11, 2017 at 7:02 AM  wrote:
>>>
 thanks,