Re: [go-nuts] generics draft and specialization

[Jon Reiter]

sorry, previous is v unclear as it's assuming a solution to question 1 in
clarification on question 2.  amended below...

On Mon, Jun 22, 2020 at 12:40 PM Jon Reiter  wrote:

> On Mon, Jun 22, 2020 at 12:00 PM Ian Lance Taylor  wrote:
>
>> On Sat, Jun 20, 2020 at 10:48 PM Jon Reiter  wrote:
>> >
>> > the draft lays out an example function GeneralAbsDifference.  these
>> comments build around that.  i wanted to see how far i could get towards
>> working specialization within this framework.  the baseline assumption is
>> that when specialization is required today the acceptable amount of type
>> switching/assertion goes up a bit.
>> >
>> > so the simplest variation is
>> > func GeneralAbsDifference(a,b interface{}) interface{} {
>> >  ai, aiok := a.(int)
>> >  bi, biok := b.(int)
>> >  if aiok && biok {
>> >return OrderedAbsDifference(ai, bi)
>> >  }
>> >  // repeat for all types
>> > }
>> >
>> > that works but is, even given the qualifier above, not really
>> acceptable.  you can make it a bit cleaner with reflect but still, it's
>> bad.  changing interface{} to Numeric doesn't work with compile error
>> "interface type for variable cannot contain type constraints".  fair
>> enough, although i'm not convinced no such useful check is possible at
>> compile time.  with that facility available it's debatable whether some of
>> those otherwise-not-so-clean setups are worth it in exchange for only
>> having to write the underlying absdiff() functions once each.
>> >
>> > if we pretend the arguments can be of type Numeric we can try our type
>> logic as:
>> >  ao, aook := a.(OrderedNumeric)
>> >  ...
>> > in hopes of getting a somewhat-cleaner arrangement.  this, with a and b
>> using interface{} so it could otherwise compile, returns the entertaining
>> error message "OrderedNumeric does not satisfy OrderedNumeric."  and it is
>> true that type does not appear in the type list of the interface.  in this
>> case there are two arguments and we'd need to ensure they are of the same
>> acceptable type.  i was expecting this to compile and then to write some
>> logic using reflect and see how badly it turned out.  that's not an option.
>> >
>> > but consider this for a single-argument function.  then there is no
>> uncertainty -- the logic i'd need to write is straightforward and can
>> surely be automatically generated.  i think that is true whenever each type
>> parameter specifies only 1 argument's type.  multiple-argument
>> generic-specialization would then require creating "tuple interfaces" that
>> glue the params together but would be otherwise clean and explicit.  it's
>> certainly better than what you'd need to do today to handle any of this.
>> >
>> > so two specific questions:
>> >  - is there some part-way use of types in interfaces that can be used
>> in non-generic function arg specs?  in this case the return value would
>> require it but in general arguments-only would be useful too.
>>
>> Possibly such a thing could be defined, but it's not in the current
>> design draft.  And I'm not sure it would help.  If I write F(a, b
>> Ordered) then both a and b may be Ordered, but nothing requires that
>> they be the same ordered type.
>>
>
> yeah agree i only see a simple way for 1 argument (maybe i did not express
> that clearly).  you could rewrite multiple arguments using generic lists i
> guess, or explicit Pair, Triplet, etc types.
>
>
>>
>> >  - at least for cases where no ambiguity exists is it possible for a
>> type-containing interface to act like it's on it's own type list?
>>
>> I guess I'm not sure why you need this.  If you have a type list, it
>> seems feasible to type switch on each possible type.  I'm sure I'm
>> missing something.
>>
>
> so the code looks like:
> if x1,ok1 := a.(first) ; ok {
>   Generic1(x1)
>
>> } else if x2, ok2 := a.(second) {
>
  Generic2(x2)

> ...
> } else {
>  // never get here as long as every type is covered
> }
>
> but that "never get here" is only true as long as the if/elses match every
> type in the type list.  you could get halfway with something like:
>
for t := range reflect.TypesOnTheList(a) { // maybe
> reflect.TypesOnTheList(reflect.GenericTypeOf(a))
>
  if t == A || t == B || ... {

>  if x,ok := a.(t) ; ok {
>   GenericFunction(x)
>  }
>
} else if t == C || t== D || ... {
if x,ok := a.(t) ; ok {

>   GenericFunction2(x)
>  }
>
}

> }
>
> this is a step more than syntactic sugar wrt the spec as it automates some
> maintenance.  with that function in reflect it's just convenience.  the
> reflect version here is similar to your "reflection on type arguments"
> section and could be done that way too.  here i think you can get the
> compiler to reject GenericTypeOf() on a non-generic type and ensure the
> loop always hits it's mark.
>

punting on question 1, you can do this with something like what is proposed
in the reflection on type arguments section, i think quite safely.


>
>
>
>>
>> Ian
>>
>

-- 
You received this message because you are 

[go-nuts] [generics] probably should also try inferring from the use of returned values

[b97tsk]

https://go2goplay.golang.org/p/QP2REBLl5f5

The code doesn't compile. But I would like to see it does.

(I could make it compiles, of course. But then, it wouldn't look nice.)

-- 
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/9c368975-e073-4b89-9b9b-7513fa01f628o%40googlegroups.com.

Re: [go-nuts] generics draft and specialization

[Jon Reiter]

On Mon, Jun 22, 2020 at 12:00 PM Ian Lance Taylor  wrote:

> On Sat, Jun 20, 2020 at 10:48 PM Jon Reiter  wrote:
> >
> > the draft lays out an example function GeneralAbsDifference.  these
> comments build around that.  i wanted to see how far i could get towards
> working specialization within this framework.  the baseline assumption is
> that when specialization is required today the acceptable amount of type
> switching/assertion goes up a bit.
> >
> > so the simplest variation is
> > func GeneralAbsDifference(a,b interface{}) interface{} {
> >  ai, aiok := a.(int)
> >  bi, biok := b.(int)
> >  if aiok && biok {
> >return OrderedAbsDifference(ai, bi)
> >  }
> >  // repeat for all types
> > }
> >
> > that works but is, even given the qualifier above, not really
> acceptable.  you can make it a bit cleaner with reflect but still, it's
> bad.  changing interface{} to Numeric doesn't work with compile error
> "interface type for variable cannot contain type constraints".  fair
> enough, although i'm not convinced no such useful check is possible at
> compile time.  with that facility available it's debatable whether some of
> those otherwise-not-so-clean setups are worth it in exchange for only
> having to write the underlying absdiff() functions once each.
> >
> > if we pretend the arguments can be of type Numeric we can try our type
> logic as:
> >  ao, aook := a.(OrderedNumeric)
> >  ...
> > in hopes of getting a somewhat-cleaner arrangement.  this, with a and b
> using interface{} so it could otherwise compile, returns the entertaining
> error message "OrderedNumeric does not satisfy OrderedNumeric."  and it is
> true that type does not appear in the type list of the interface.  in this
> case there are two arguments and we'd need to ensure they are of the same
> acceptable type.  i was expecting this to compile and then to write some
> logic using reflect and see how badly it turned out.  that's not an option.
> >
> > but consider this for a single-argument function.  then there is no
> uncertainty -- the logic i'd need to write is straightforward and can
> surely be automatically generated.  i think that is true whenever each type
> parameter specifies only 1 argument's type.  multiple-argument
> generic-specialization would then require creating "tuple interfaces" that
> glue the params together but would be otherwise clean and explicit.  it's
> certainly better than what you'd need to do today to handle any of this.
> >
> > so two specific questions:
> >  - is there some part-way use of types in interfaces that can be used in
> non-generic function arg specs?  in this case the return value would
> require it but in general arguments-only would be useful too.
>
> Possibly such a thing could be defined, but it's not in the current
> design draft.  And I'm not sure it would help.  If I write F(a, b
> Ordered) then both a and b may be Ordered, but nothing requires that
> they be the same ordered type.
>

yeah agree i only see a simple way for 1 argument (maybe i did not express
that clearly).  you could rewrite multiple arguments using generic lists i
guess, or explicit Pair, Triplet, etc types.


>
> >  - at least for cases where no ambiguity exists is it possible for a
> type-containing interface to act like it's on it's own type list?
>
> I guess I'm not sure why you need this.  If you have a type list, it
> seems feasible to type switch on each possible type.  I'm sure I'm
> missing something.
>

so the code looks like:
if x1,ok1 := a.(first) ; ok {
} else if x2, ok2 := a.(second) {
...
} else {
 // never get here as long as every type is covered
}

but that "never get here" is only true as long as the if/elses match every
type in the type list.  you could get halfway with something like:
for t := range reflect.TypesOnTheList(a) { // maybe
reflect.TypesOnTheList(reflect.GenericTypeOf(a))
 if x,ok := a.(t) ; ok {
  GenericFunction(x)
 }
}

this is a step more than syntactic sugar wrt the spec as it automates some
maintenance.  with that function in reflect it's just convenience.  the
reflect version here is similar to your "reflection on type arguments"
section and could be done that way too.  here i think you can get the
compiler to reject GenericTypeOf() on a non-generic type and ensure the
loop always hits it's mark.



>
> 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/CABZtUk7s07jbDBexwMQO_xeQAajd4CX3RPG1kM-VZgLzF8RC1g%40mail.gmail.com.

Re: [go-nuts] generics draft and specialization

[Ian Lance Taylor]

On Sat, Jun 20, 2020 at 10:48 PM Jon Reiter  wrote:
>
> the draft lays out an example function GeneralAbsDifference.  these comments 
> build around that.  i wanted to see how far i could get towards working 
> specialization within this framework.  the baseline assumption is that when 
> specialization is required today the acceptable amount of type 
> switching/assertion goes up a bit.
>
> so the simplest variation is
> func GeneralAbsDifference(a,b interface{}) interface{} {
>  ai, aiok := a.(int)
>  bi, biok := b.(int)
>  if aiok && biok {
>return OrderedAbsDifference(ai, bi)
>  }
>  // repeat for all types
> }
>
> that works but is, even given the qualifier above, not really acceptable.  
> you can make it a bit cleaner with reflect but still, it's bad.  changing 
> interface{} to Numeric doesn't work with compile error "interface type for 
> variable cannot contain type constraints".  fair enough, although i'm not 
> convinced no such useful check is possible at compile time.  with that 
> facility available it's debatable whether some of those 
> otherwise-not-so-clean setups are worth it in exchange for only having to 
> write the underlying absdiff() functions once each.
>
> if we pretend the arguments can be of type Numeric we can try our type logic 
> as:
>  ao, aook := a.(OrderedNumeric)
>  ...
> in hopes of getting a somewhat-cleaner arrangement.  this, with a and b using 
> interface{} so it could otherwise compile, returns the entertaining error 
> message "OrderedNumeric does not satisfy OrderedNumeric."  and it is true 
> that type does not appear in the type list of the interface.  in this case 
> there are two arguments and we'd need to ensure they are of the same 
> acceptable type.  i was expecting this to compile and then to write some 
> logic using reflect and see how badly it turned out.  that's not an option.
>
> but consider this for a single-argument function.  then there is no 
> uncertainty -- the logic i'd need to write is straightforward and can surely 
> be automatically generated.  i think that is true whenever each type 
> parameter specifies only 1 argument's type.  multiple-argument 
> generic-specialization would then require creating "tuple interfaces" that 
> glue the params together but would be otherwise clean and explicit.  it's 
> certainly better than what you'd need to do today to handle any of this.
>
> so two specific questions:
>  - is there some part-way use of types in interfaces that can be used in 
> non-generic function arg specs?  in this case the return value would require 
> it but in general arguments-only would be useful too.

Possibly such a thing could be defined, but it's not in the current
design draft.  And I'm not sure it would help.  If I write F(a, b
Ordered) then both a and b may be Ordered, but nothing requires that
they be the same ordered type.

>  - at least for cases where no ambiguity exists is it possible for a 
> type-containing interface to act like it's on it's own type list?

I guess I'm not sure why you need this.  If you have a type list, it
seems feasible to type switch on each possible type.  I'm sure I'm
missing something.

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/CAOyqgcXpAU0k-uMncrgbRpjMTyoeiui-po%2B35zvzJD3nYnXktg%40mail.gmail.com.

Re: [go-nuts] Help with code reproducing a change in Go 1.15 CL 229578

[Florin Pățan]

Hi Ian,

Thank you for your reply.

At the moment, I don't have any data about this. The question raised from 
the fact that the language in the documentation suggests that a compiler 
error would occur, at least to me as a user with English as a second 
language.

So, when I created some test scenarios to know if we should add similar 
checks for this in GoLand, I was a bit surprised that there's nothing that 
would happen, either with `go build` or with `go vet`.

I'll see if I can find any such usages and report back here. For now, it 
seems we can omit to create such a check in the IDE / other static analysis 
tools.

Thank you,
Florin

On Friday, June 19, 2020 at 8:13:37 AM UTC+3 Ian Lance Taylor wrote:

> On Thu, Jun 18, 2020 at 1:54 AM Florin Pățan wrote: 
> > 
> > According to the Go 1.15 documentation, the change introduced in 
> https://golang.org/cl/229578 should change the program behavior, and 
> users are expected to perform modifications to their code. 
> > 
> > > Package unsafe's safety rules allow converting an unsafe.Pointer into 
> uintptr when calling certain functions. Previously, in some cases, the 
> compiler allowed multiple chained conversions (for example, 
> syscall.Syscall(…, uintptr(uintptr(ptr)), …)). The compiler now requires 
> exactly one conversion. Code that used multiple conversions should be 
> updated to satisfy the safety rules. 
> > 
> > After reading that paragraph, I expect that the compiler fails to 
> compile code after that change. When running `go build` or `go build 
> -gcflags="-d=checkptr"` neither produce a failure. I used `go vet`, and 
> that doesn't catch this change either. 
> > 
> > The example I used is https://play.golang.org/p/a0B4kxLEAjb. 
> > 
> > Perhaps I failed to construct a correct example, in which case help 
> would be appreciated. 
> > 
> > I was not sure if this belongs to the mailing list or the issue tracker, 
> so I started here. 
>
> What has changed is that the compiler does not keep multiply-casted 
> pointers live across the call to syscall.Syscall. 
>
> Our assumption was that nobody actually wrote code like that. Why 
> would they? Do you know of any real code that does this? If there is 
> no real code, then it doesn't seem worth spending the time to write 
> checks. If we were going to do that, we might as well instead spend 
> the time to let the code continue to work. 
>
> 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/3545930b-1b40-44b3-89c7-3ba24a5be797n%40googlegroups.com.

Re: [go-nuts] Can you have multiple go routines waiting on a socket?

[Kurtis Rader]

On Sun, Jun 21, 2020 at 8:05 PM Robert Engels  wrote:

> Most webservers use multiple threads per socket - this is commonly
> observed with async IO. IO in Go is async behind the scenes so you don’t
> need to worry about this. You probably will use a Go routine to read the
> socket; and probably another to do the writing - so you can treat the IO as
> synchronous. That is a wonderful aspect of Go.
>

That is true but it's not clear the O.P. is ready to appreciate that
distinction. Note that their question was about having multiple readers
running in parallel. Something that, in general, is not safe for TCP
connections. It's not safe even if additional constraints, such as fixed
size structures, are in effect. That's because TCP does not preserve
message boundaries and a given structure might be broken up and received in
pieces. Thus resulting in different readers of the socket reading different
pieces of the structure.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD-3U%3DA0A9%2BO7%2BCAKLUVLA0s7Gn%3DrfGfwxDhu5PHA70_Fg%40mail.gmail.com.

Re: [go-nuts] Re: [generics] how to constraint a type must be a map or a slice?

[Ian Lance Taylor]

On Sat, Jun 20, 2020 at 8:08 PM T L  wrote:
>
>
>
> On Saturday, June 20, 2020 at 3:08:42 PM UTC-4, David Finkel wrote:
>>
>>
>>
>> On Sat, Jun 20, 2020 at 11:03 AM T L  wrote:
>>>
>>>
>>>
>>> On Saturday, June 20, 2020 at 10:21:56 AM UTC-4, Axel Wagner wrote:

 I would assume it's

 type MapConstraint(type K comparable, V interface{}) interface {
 type map[K]V
 }

 func F(type M MapConstraint(K, V), K comparable, V interface{}) (m M) {
 }

 Note that you are under no obligation to make use of a type-parameter if 
 you don't need it.
>>>
>>>
>>> I don't very understand this. Can a slice value be used as the argument of 
>>> the F function?
>>
>> For that, I think you'd need the interface to be:
>> type MapSliceConstraint(type K comparable, V interface{}) interface {
>> type map[K]V, []V
>> }
>>
>> I'm not quite sure how to eliminate the useless K type-param for slices, 
>> though.
>>
>> Note: the relevant draft design section is: 
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-parameters-in-type-lists
>>
>> Here's an almost working example:
>> https://go2goplay.golang.org/p/qcdfl0tuHlb
>>
>> It looks like there's a bug in the type-parameter constraint checking 
>> because in the above example code, I get:
>>
>> type checking failed for main
>>
>> prog.go2:11:39: K does not satisfy comparable
>>
>> This, despite the type parameter definition literally requiring that K be 
>> comparable:
>> func genLen(type T MapSliceConstraint(K, V), K comparable, V 
>> interface{})(collection T) int {
>> return len(collection)
>> }
>> (example without a main() to reduce clutter: 
>> https://go2goplay.golang.org/p/1gqiYuDELuI)
>
>
>
> Thanks for making this example.
>
> However, it almost reach my upper limit understanding ability to get the 
> implementation.
> I looks some bad practices in using C++ template.
>
> Is it good to add a Kind list constraint? For example,
>
> type MapOrSlice interface {
>kind map, []
> }

We've already decided in this design draft that we are not going to
permit all possible constraints.  Therefore, this is the kind of
question that needs to be answered based on experience using real
code.  Do people want or need to write real code that permits
declaring that some type parameter is a map or a slice, without
knowing anything else about the type?  I don't see how such
information would be useful at all.  Without knowing anything about
the key or element types of the map/slice, it would be very difficult
to use such a type parameter in any useful way.  And quite apart from
that, when is it useful for people to write a function that takes
either a map or a slice, but nothing else?   We need real examples of
real code that people want to write, not theoretical ideas for code
that people might in theory want to write.  Thanks.

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/CAOyqgcV0h_enPJSHkx80D7SM-7vOSYKwQGJU6VdKvNjM_vLyRQ%40mail.gmail.com.

Re: [go-nuts] Re: go get with vanity import path and 404: fails

['Dan Kortschak' via golang-nuts]

As a follow-up to the follow-up, I have filed golang.org/issue/39748;
the error is apparently not in minification, but in the go command's
handling of html. The workaround remains the same.

On Sun, 2020-06-21 at 03:23 +, Dan Kortschak wrote:
> Thanks to Tim and Eric Bajumpaa on slack.
> 
> The issue was due to an error in minification where the quotes around
> the name attribute value are stripped. Turning off minification is an
> interim workaround while that is broken.
> 
> Dan
> 
> On Sat, 2020-06-20 at 18:10 -0700, Tim Heckman wrote:
> > Closing the loop on this. They reached out in the Gopher Slack and
> > we
> > pieced it together:
> > 
> > - https://gophers.slack.com/archives/C029RQSEE/p1592699134083700
> > 
> > It has to do with this section of code:
> > 
> > - 
> > 
https://github.com/golang/go/blob/60f78765022a59725121d3b800268adffe78bde3/src/cmd/go/internal/get/vcs.go#L804-L810
> > 
> > This chooses to swallow parsing errors if the HTTP response looks
> > to
> > be invalid (bad status code), which is what's happening here.
> > Another
> > user managed to find that the meta tags on the page look malformed:
> > 
> > https://github.com/gonum/exp;>;;
> > 
> > Notice that go-import is missing quotes around it. I think fixing
> > those up should solve the issue here. There is a larger question as
> > to whether this code should return both, as it's hard to know which
> > is correct and in this case it shared the wrong context.
> > 
> > Cheers!
> > -Tim
> > 
> 
> 


-- 
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/22ed6b3a00d994d154b2188c5d239072d17e08a6.camel%40kortschak.io.

Re: [go-nuts] [generics] Should convertibility and comparibility of two types be two kinds of constraints?

[Ian Lance Taylor]

On Sat, Jun 20, 2020 at 7:30 PM T L  wrote:
>
> On Saturday, June 20, 2020 at 4:48:07 PM UTC-4, Ian Lance Taylor wrote:
>>
>> On Sat, Jun 20, 2020 at 8:26 AM T L  wrote:
>> >
>> > For example, if there is a builtin convertible(from, to) constraint,
>> > We can define a slice conversion function as
>> >
>> > func Convert(type Ta, Tb converitble(Ta, Tb)) (avs []Ta, _Tb) (bvs []Tb) {
>> >bvs = make([]Tb, 0, len(avs)
>> >for _, v := range avs {
>> >   bvs = append(bvs, Tb(v))
>> >}
>> >return bvs
>> > }
>> >
>> > We can use it as:
>> >
>> > iValues := Convert([]int{}{1, 2, 3}, interface{}(nil))
>>
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#no-way-to-express-convertability
>>
>> Ian
>
>
> What are the rationales behind this?

I'm not sure I understand your question.  The section I mentioned is
under "Issues".  There is nothing here that seems to need a rationale.
It's an issue that needs to be considered before making a language
change proposal.

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/CAOyqgcV4u1vrhEXASg8og9TeUQxLx--%3DcuAB6wUEpfh53JMXuw%40mail.gmail.com.

Re: [go-nuts] Channel receive operator. Untyped boolean result.

[Ian Lance Taylor]

On Sun, Jun 21, 2020 at 2:11 PM Laevus Dexter  wrote:
>>
>> A receive expression used in an assignment or initialization of the special 
>> form
>>
>> x, ok = <-ch
>> x, ok := <-ch
>> var x, ok = <-ch
>> var x, ok T = <-ch
>>
>> yields an additional untyped boolean result reporting whether the 
>> communication succeeded. The value of ok is true if the value received was 
>> delivered by a successful send operation to the channel, or false if it is a 
>> zero value generated because the channel is closed and empty.
>
>
> Why it's untyped? And how to make the last expression to work? Seems I can't 
> use anything but bool.

It's untyped mainly because there is no reason to make it typed.

You can use a different type by writing code like (untested):

type MyBool bool

func F(c chan int) {
var (
x  int
ok MyBool
)
x, ok = <-c
}

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/CAOyqgcVhm0ZC-Q4joeFAh%2BM7JMUzS9iWaPZEdAmLtasUqpaWvw%40mail.gmail.com.

Re: [go-nuts] Can you have multiple go routines waiting on a socket?

[Robert Engels]

Most webservers use multiple threads per socket - this is commonly observed 
with async IO. IO in Go is async behind the scenes so you don’t need to worry 
about this. You probably will use a Go routine to read the socket; and probably 
another to do the writing - so you can treat the IO as synchronous. That is a 
wonderful aspect of Go. 

> On Jun 21, 2020, at 7:57 PM, Kurtis Rader  wrote:
> 
> On Sun, Jun 21, 2020 at 5:11 PM  wrote:
>>> Yes, the exact use case I'm thinking of is reading UDP datagrams. I just 
>>> want to read them as fast as possible then hand them off to other 
>>> goroutines for further processing. I was just thinking I would get better 
>>> speed/throughput if I had a couple of go routines listening, waiting to 
>>> pick up a packet. 
>> 
>> What manner of unpredictable behavior do TCP sockets exhibit of you have 
>> multiple reading processes?  Does anyone know how high performance web 
>> servers deal with this?
>> (I'm thinking of Apache/Caddy, etc)
> 
> Web servers don't use UDP. They use TCP which is a stream of bytes without 
> message boundaries. They also don't have multiple goroutines reading from the 
> same socket. They bind a socket to an address then listen for incoming 
> connections. When a connection is established the listen call returns a new 
> socket over which communication with the client takes place. In a web server 
> written in Go a goroutine would be spun up to handle communication with that 
> client. The goroutine that handles new connections immediately goes back to 
> listening for another connection from a client.
> 
> To answer your question about why what you're trying to do can result in 
> unpredictable behavior when TCP (SOCK_STREAM) sockets are used consider a 
> simpler model. Since a TCP connection is just a bidirectional stream of bytes 
> we can model their behavior using pipes. Consider what happens if you have 
> one or more processes writing lines (i.e., variable number of bytes 
> terminated by a newline) into the pipe. Your process has two goroutines each 
> reading lines from the pipe. Each goroutine processes one line at a time by 
> reading one byte at a time until it sees a newline. Assume the line "abcd\n" 
> is written into the pipe. Each goroutine reads one char. This means one of 
> them will receive the "a" and the other the "b". Oops! It's even worse than 
> that because depending on which one is first to read another char either of 
> the goroutines will see the "c". That is obviously a contrived example but 
> illustrates the problem.
> 
> It's not clear you actually understand the difference between UDP and TCP and 
> the characteristics of each. I don't know what books or resources are good 
> references today. Back in the 1990's when I was learning network programming 
> I used "TCP/IP Illustrated" and "UNIX Network Programming", both by W. R. 
> Stevens, as well as several other books.
> 
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
> -- 
> 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/CABx2%3DD_voTyO5jynkx58i-Le5t7d8Ve3qSXy-Xk97gfZCyTspA%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/4F0B4332-46B4-4E21-B72B-7D0C7EBD0C57%40ix.netcom.com.

Re: [go-nuts] Can you have multiple go routines waiting on a socket?

[Kurtis Rader]

On Sun, Jun 21, 2020 at 5:11 PM  wrote:

> Yes, the exact use case I'm thinking of is reading UDP datagrams. I just
>> want to read them as fast as possible then hand them off to other
>> goroutines for further processing. I was just thinking I would get better
>> speed/throughput if I had a couple of go routines listening, waiting to
>> pick up a packet.
>
>
> What manner of unpredictable behavior do TCP sockets exhibit of you have
> multiple reading processes?  Does anyone know how high performance web
> servers deal with this?
> (I'm thinking of Apache/Caddy, etc)
>

Web servers don't use UDP. They use TCP which is a stream of bytes without
message boundaries. They also don't have multiple goroutines reading from
the same socket. They bind a socket to an address then listen for incoming
connections. When a connection is established the listen call returns a new
socket over which communication with the client takes place. In a web
server written in Go a goroutine would be spun up to handle communication
with that client. The goroutine that handles new connections immediately
goes back to listening for another connection from a client.

To answer your question about why what you're trying to do can result in
unpredictable behavior when TCP (SOCK_STREAM) sockets are used consider a
simpler model. Since a TCP connection is just a bidirectional stream of
bytes we can model their behavior using pipes. Consider what happens if you
have one or more processes writing lines (i.e., variable number of bytes
terminated by a newline) into the pipe. Your process has two goroutines
each reading lines from the pipe. Each goroutine processes one line at a
time by reading one byte at a time until it sees a newline. Assume the line
"abcd\n" is written into the pipe. Each goroutine reads one char. This
means one of them will receive the "a" and the other the "b". Oops! It's
even worse than that because depending on which one is first to read
another char either of the goroutines will see the "c". That is obviously a
contrived example but illustrates the problem.

It's not clear you actually understand the difference between UDP and TCP
and the characteristics of each. I don't know what books or resources are
good references today. Back in the 1990's when I was learning network
programming I used "TCP/IP Illustrated" and "UNIX Network Programming",
both by W. R. Stevens, as well as several other books.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD_voTyO5jynkx58i-Le5t7d8Ve3qSXy-Xk97gfZCyTspA%40mail.gmail.com.

Re: [go-nuts] Can you have multiple go routines waiting on a socket?

[hardconnect . joe]

>
> Yes, the exact use case I'm thinking of is reading UDP datagrams. I just 
> want to read them as fast as possible then hand them off to other 

goroutines for further processing. I was just thinking I would get better 
speed/throughput if I had a couple of go routines listening, waiting to 
pick up a packet. 

What manner of unpredictable behavior do TCP sockets exhibit of you have 
multiple reading processes?  Does anyone know how high performance web 
servers deal with this?
(I'm thinking of Apache/Caddy, etc)

Thanks!

Joe

-- 
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/b098a47e-85dd-44fa-bdc7-3b5c0fe5f798o%40googlegroups.com.

[go-nuts] Channel receive operator. Untyped boolean result.

[Laevus Dexter]

>
> A receive expression used in an assignment 
>  or initialization of the 
> special form
>
> x, ok = <-ch
> x, ok := <-ch
> var x, ok = <-ch
> var x, ok T = <-ch
>
> yields an additional untyped boolean result reporting whether the 
> communication succeeded. The value of ok is true if the value received 
> was delivered by a successful send operation to the channel, or false if 
> it is a zero value generated because the channel is closed and empty.
>

Why it's untyped? And how to make the last expression to work? Seems I 
can't use anything but bool. 

-- 
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/0713b282-00ae-4119-bbe9-559ca912aa82o%40googlegroups.com.

Re: [go-nuts] Re: [generics] I think it's better have higher perfomance than lower compiling time

[David Skinner]

Tyler Compton is correct. In the early 90s, the plethora of C++
optimization switches resulted in obscure memory errors which resulted in
major software houses shipping bad products, declaring bankruptcy, and
disappearing from the face of the earth like dinosaurs. I am totally
opposed to optimization switches, reliability is number one, productivity
is number two, speed is number three.

Fast compile times are not so fast on my machine because of comprehensive
unit tests, but I am not willing to give up my unit tests.

I am only suggesting that we have a fast and slow compile.

On Sun, Jun 21, 2020 at 12:49 AM Tyler Compton  wrote:

> The idea of having development and release compilation modes sounds
> appealing at first, though I'm a bit skeptical about how it would turn out.
> This would mean that, during development, you wouldn't have a full
> understanding of the performance characteristics of your program.
> Admittedly, that's not something you *always* care about, but when you do
> care you'll have to deal with slow compilation times.
>
> I've found that in C++ certain memory safety bugs will only rear their
> ugly head after a certain compiler optimization level, meaning that these
> bugs can be missed during development. Go's memory safety would probably
> make this significantly less of a problem, but it still concerns me
> somewhat.
>
> On Fri, Jun 19, 2020 at 6:46 PM David Skinner 
> wrote:
>
>> I remember going on a two-hour lunch break at a Cajun restaurant and
>> returning to my office to discover that my precompiled C++ headers were
>> still compiling. I really love that Go compiles quickly and links quickly.
>>
>> The day comes when code needs to ship, final compile, and final quality
>> control tests,  why not have a final build that compiles quite slowly and
>> optimizes to the max. There is no need to do either/or and compromise, just
>> do both.
>>
>> On Friday, June 19, 2020 at 12:23:46 PM UTC-5, Ronald Davilla wrote:
>>>
>>> Just if perfomance will decrease with every release/version, it'd be not
>>> really good, and it's might be necessary to pay more attention to this
>>>
>> --
>> 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/fd72210d-5a04-4be3-b51c-50b8313bf3dao%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/CAGe8nGHcT%2Bo-XwsQOzfSJwXrutK-cquoY%3DvxmvR_LWaiT07r_Q%40mail.gmail.com.

Re: [go-nuts] Block-based data structures and the Type Parameters - Draft Design

[Andrew Werner]

Thanks for the reply! If I read it correctly, it is already possible to 
specify a type constraint as an Array of a given size and so the first part 
of the "What I might have expected" actually does work. I noticed that it 
works in that it works as a type constraint but I found that types 
constrained that way do not support indexing or slicing. Perhaps that's 
just a limitation of the prototype and not the proposal.

The other thing that I think I'm proposing (thanks for the correction) is a 
way to represent all arrays of a given type:

type Array(type T) interface {
type [...]T
}

Thanks for dealing with my very long-winded way of saying that. 

On Sunday, June 21, 2020 at 12:35:53 PM UTC-4, David Finkel wrote:
>
>
>
> On Sat, Jun 20, 2020 at 1:22 AM Andrew Werner  > wrote:
>
>> [The body of this email is a duplication of the README in 
>> https://github.com/ajwerner/go2dequeue/ 
>> which also contains the sample implementation]
>>
>> Exercise building a dequeue with the go2 Type Parameter Draft 
>>
>> This project is an exploration with the go2go / Type Parameters - Design 
>> Draft 
>> 
>>  
>> with an eye towards block-based data structures which promote access 
>> locality.
>>
>> Such data structures traditionally utilize blocks of objects laid out 
>> contiguously in memory. In go, today, one generally specializes such data 
>> structures which are performance critical. This is especially important in 
>> the case of reducing allocations which occur on critical paths. Using a 
>> sync.Pool can help with allocations in some cases but can be clunky to use 
>> and, well, do create more pointers for GC to worry about and don't have the 
>> access locality.
>>
>> Whether it's really important to have data structures which include 
>> arrays of other data structures laid out contiguously in RAM is really 
>> important is sort of orthogonal. Let's just assume that it is for now and 
>> look at how we'd do it. We only need to consider rejecting the importance 
>> of this case if we can't find a good solution or idiom to support it. The 
>> google/btree  library README links this 
>> Google 
>> Open Source Blog Post on block-based container 
>> 
>>  
>> performance indicating it does matter. The interesting thing about that 
>> library is it hardly gets the access locality of the C++ library in the 
>> blog post it references.
>>
>> The challenge this library explores is to layout blocks in structures 
>> contiguously in RAM while allowing the user to have some control over that 
>> block size.
>> This example 
>>
>> The approach this experiment takes is to allow the users to specify the 
>> block size by providing a function to map an array type to a slice. The 
>> allows the blocks to contain a slice which references the array. The 
>> overhead to maintain the slice header is 3 words but the cost is probably 
>> less in memory and more in the optimizations the compiler will be less able 
>> to perform. In particular, it probably will need to do bounds checking on 
>> that slice and there are probably some opportunities to avoid the pointer 
>> interactions. The interface ends up being pretty reasonable though a little 
>> bit ... opaque?
>>
>> What this looked like in this demo is*
>>
>> // Say we want to create a dequeue of things.type Thing struct { Foo int64, 
>> Bar int64, ID [16]byte }// The below incantation will create one with blocks 
>> of 37 elements.d := NewWithArray(func(a *[37]Thing) []Thing { return (*a)[:] 
>> })// The nodes in the linked list of this structure are 1240 bytes, not 
>> that// that's a great number or anything like that, just saying it's pretty 
>> big.// Maybe there'd be something good to get out of aligning things are 
>> cache line// sizes. See TestNodeSize.
>>
>> Other things you could do Use a slice for the buffer 
>>
>> A different approach would be to just have the array in the node, take a 
>> buffer size and then keep a sync.Pool or freelist of slices. Today's 
>> github.com/google/btree does this but way worse in that it just keeps a 
>> slice of btree.Item. So fine, it's be two objects, the nodes and their item 
>> buffers. Maybe that is the answer but it's pretty lame. My feeling is once 
>> somebody is optimizing a data structure for access locality they are trying 
>> to optimize as far as they can go.
>> Ignore or augment the language generics with manual or automatic 
>> specialization 
>>
>> Today, in performance critical cases, people use a variety of automatic 
>> or manual specialization. There are tools like 
>> https://github.com/cheekybits/genny or 
>> https://github.com/mmatczuk/go_generics. Note that the latter has been 
>> used to good effect in CockroachDB for building specialized copy-on-write, 
>> interval B-trees.
>>
>> One answer 

Re: [go-nuts] Block-based data structures and the Type Parameters - Draft Design

[David Finkel]

On Sat, Jun 20, 2020 at 1:22 AM Andrew Werner  wrote:

> [The body of this email is a duplication of the README in 
> https://github.com/ajwerner/go2dequeue/
> which also contains the sample implementation]
>
> Exercise building a dequeue with the go2 Type Parameter Draft
>
> This project is an exploration with the go2go / Type Parameters - Design
> Draft
> 
> with an eye towards block-based data structures which promote access
> locality.
>
> Such data structures traditionally utilize blocks of objects laid out
> contiguously in memory. In go, today, one generally specializes such data
> structures which are performance critical. This is especially important in
> the case of reducing allocations which occur on critical paths. Using a
> sync.Pool can help with allocations in some cases but can be clunky to use
> and, well, do create more pointers for GC to worry about and don't have the
> access locality.
>
> Whether it's really important to have data structures which include arrays
> of other data structures laid out contiguously in RAM is really important
> is sort of orthogonal. Let's just assume that it is for now and look at how
> we'd do it. We only need to consider rejecting the importance of this case
> if we can't find a good solution or idiom to support it. The google/btree
>  library README links this Google Open
> Source Blog Post on block-based container
> 
> performance indicating it does matter. The interesting thing about that
> library is it hardly gets the access locality of the C++ library in the
> blog post it references.
>
> The challenge this library explores is to layout blocks in structures
> contiguously in RAM while allowing the user to have some control over that
> block size.
> This example
>
> The approach this experiment takes is to allow the users to specify the
> block size by providing a function to map an array type to a slice. The
> allows the blocks to contain a slice which references the array. The
> overhead to maintain the slice header is 3 words but the cost is probably
> less in memory and more in the optimizations the compiler will be less able
> to perform. In particular, it probably will need to do bounds checking on
> that slice and there are probably some opportunities to avoid the pointer
> interactions. The interface ends up being pretty reasonable though a little
> bit ... opaque?
>
> What this looked like in this demo is*
>
> // Say we want to create a dequeue of things.type Thing struct { Foo int64, 
> Bar int64, ID [16]byte }// The below incantation will create one with blocks 
> of 37 elements.d := NewWithArray(func(a *[37]Thing) []Thing { return (*a)[:] 
> })// The nodes in the linked list of this structure are 1240 bytes, not 
> that// that's a great number or anything like that, just saying it's pretty 
> big.// Maybe there'd be something good to get out of aligning things are 
> cache line// sizes. See TestNodeSize.
>
> Other things you could do Use a slice for the buffer
>
> A different approach would be to just have the array in the node, take a
> buffer size and then keep a sync.Pool or freelist of slices. Today's
> github.com/google/btree does this but way worse in that it just keeps a
> slice of btree.Item. So fine, it's be two objects, the nodes and their item
> buffers. Maybe that is the answer but it's pretty lame. My feeling is once
> somebody is optimizing a data structure for access locality they are trying
> to optimize as far as they can go.
> Ignore or augment the language generics with manual or automatic
> specialization
>
> Today, in performance critical cases, people use a variety of automatic or
> manual specialization. There are tools like
> https://github.com/cheekybits/genny or
> https://github.com/mmatczuk/go_generics. Note that the latter has been
> used to good effect in CockroachDB for building specialized copy-on-write,
> interval B-trees.
>
> One answer to this problem might just be that go's generics solution
> doesn't solve for the problem of specializing block-based data structures.
> That's not a particularly satisfying answer.
> What I might have expected / guess I'm proposing
>
> Type lists are a thing for utilizing language features which only apply to
> certain kinds of types. There should be a way to create a type list for
> arrays of types.
>
As a first pass I would have anticipated that there would be a way to
> inform this package of a buffer size maybe drawn from a fixed number of
> sizes. For example:
>
> type BlockSize int
> const (
> _ BlockSize = 1 << (4*iota)
> Block16
> Block256
> )
> // Array here allowstype Array(type T) interface {
> type [Block16]T, [Block256]T
> }
> func New(type T)(blockSize BlockSize) Dequeue(T) {
>
> Hmm, this function signature would require being able 

Re: [go-nuts] Reading multi line input from user

[Miguel Angel Rivera Notararigo]

Hi! you may try this https://play.golang.org/p/hDDyzm6IfED or this
https://play.golang.org/p/MoKAbIbtR_J, but the user cannot edit previous
lines and he/she have to hit Ctrl + D when is done

-- 
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/CAF9DLCkK-ouMP%2BDiPcpswO1qBQzP8XPNS45zpa3L%2BbhtmE5zvA%40mail.gmail.com.

[go-nuts] Reading multi line input from user

[Durga Someswararao G]

Hi,

I am trying to read multi line user input, which I don't know the count of 
those lines. Is there any way to do it.

Eg:

User will give one sample piece of code like below we have to read complete 
code without skipping content. As it is a piece of code we cannot get 
number of lines we have to read.

import java.io.*;

public class SquareNum {

   public static void main(String args[]) throws IOException
   {
  System.out.println("This is a small Java Program!");
   }
}

Thanks

-- 
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/05b21718-f600-44a8-a46c-d22561ed9776o%40googlegroups.com.

Re: [go-nuts] [design] HTTP server serving heavy computing : Handle HTTP request closed prematurely

[Thomas S]

Thank you, that helps a lot.



Le vendredi 19 juin 2020 15:49:22 UTC+2, Andrei Tudor Călin a écrit :
>
> Goroutines can only be stopped if they cooperate. They have no user-facing 
> identity or a handle by which they can be stopped. To cooperate, they need 
> to be checking some kind of cancellation flag or channel, periodically. 
> These days, for HTTP servers, that channel is the request context, since 
> CloseNotifier is deprecated.
>
> To reduce the potential cost of using select in a tight processing loop, 
> you could select on the channel only every N iterations, or maybe after T 
> time has passed since you last checked. If selects are prohibitively 
> expensive for you, you could check an atomic flag instead, and control the 
> flag through an external goroutine which waits for <-ctx.Done(). There is a 
> little bit more machinery here, but I expect this to be at least a little 
> faster than a select.
>
> In any case, these things must happen explicitly: code that wants to be 
> responsive to cancellation signals must be programmed as such.
>
>
> On Fri, Jun 19, 2020 at 3:58 PM Thomas S > 
> wrote:
>
>> Hello,
>>
>> I have an HTTP server providing heavy algorithms. Sometimes, the clients 
>> closes the connection prematurely, before the end of computing.
>>
>> Note : Sometimes the client consuming these algorithms want to stop the 
>> process if the solution is not found before X minutes for example.
>>
>> This article : 
>> https://gianarb.it/blog/go-http-cleanup-http-connection-terminated
>> shows how to use the "http.CloseNotifier" chan to receive the signal 
>> about the premature end of connection.
>>
>> *However*,
>>
>> The algorithm is made of several thousands of lines, called proceduraly, 
>> and sometimes even calling parallel computing on goroutines and recursive 
>> functions.
>>
>> It means that I should share the chan everywhere, to every functions or 
>> almost, insert a boilerplate of channel check frequently in the algorithm, 
>> and make an exit if needed.
>>
>> It seems to me pretty awful. Am I missing something ?
>>
>>
>> Thanks a lot,
>>
>> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/ad1221ad-0ac6-4282-a708-20ab8d49fa5co%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Andrei Călin
>

-- 
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/98a4a95a-5a08-4ff7-85d9-0c02869e6a43o%40googlegroups.com.

Re: [go-nuts] Re: [generics] I think it's better have higher perfomance than lower compiling time

['Axel Wagner' via golang-nuts]

Why not just build your release-build with gccgo? It often already gives
better performance than gc, AIUI. If enough of the people who really care
about it would focus their energy on it, that could probably get even more
pronounced. There's no reason that gc needs to grow optimization knobs, if
you can just use a different compiler.

On Sun, Jun 21, 2020 at 7:50 AM Tyler Compton  wrote:

> The idea of having development and release compilation modes sounds
> appealing at first, though I'm a bit skeptical about how it would turn out.
> This would mean that, during development, you wouldn't have a full
> understanding of the performance characteristics of your program.
> Admittedly, that's not something you *always* care about, but when you do
> care you'll have to deal with slow compilation times.
>
> I've found that in C++ certain memory safety bugs will only rear their
> ugly head after a certain compiler optimization level, meaning that these
> bugs can be missed during development. Go's memory safety would probably
> make this significantly less of a problem, but it still concerns me
> somewhat.
>
> On Fri, Jun 19, 2020 at 6:46 PM David Skinner 
> wrote:
>
>> I remember going on a two-hour lunch break at a Cajun restaurant and
>> returning to my office to discover that my precompiled C++ headers were
>> still compiling. I really love that Go compiles quickly and links quickly.
>>
>> The day comes when code needs to ship, final compile, and final quality
>> control tests,  why not have a final build that compiles quite slowly and
>> optimizes to the max. There is no need to do either/or and compromise, just
>> do both.
>>
>> On Friday, June 19, 2020 at 12:23:46 PM UTC-5, Ronald Davilla wrote:
>>>
>>> Just if perfomance will decrease with every release/version, it'd be not
>>> really good, and it's might be necessary to pay more attention to this
>>>
>> --
>> 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/fd72210d-5a04-4be3-b51c-50b8313bf3dao%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/CAA%3DXfu1mBzN6YJJLtAOb1ZBPuDgXoCDzuG34x5XGPwTk1u-q8A%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/CAEkBMfEUp-x67iC6m3kH_0MQtG60WYArXg5QFEdcGOr5NgKi_g%40mail.gmail.com.