Re: [go-nuts] A few thoughts on type parameters

['Carla Pfaff' via golang-nuts]

On Tuesday, 4 August 2020 at 00:34:12 UTC+2 ben...@gmail.com wrote:

> Which at first seems like a good idea, but then unless "any" is built in 
> or this becomes a well-known idiom, it won't be as self-documenting. Other 
> people will have to look up the definition to see "oh, I see, this is just 
> short-hand for an empty constraint".


I'm sure it would quickly become a well-known idiom, just like people know 
that "error" is "interface{Error() string}" or "fmt.Stringer" is 
"interface{String() string}".

Actually the current use of "interface{}" is a bit odd because it is the 
only case where an interface is commonly used as an anonymous type rather 
than by an identifier.

I assume that in current Go the empty interface is supposed to be an ugly 
duckling to discourage its overuse, but in a world with type parameters it 
will play an important role as the unbounded constraint and it should 
deserve its own identifier.

And I don't think that giving it a short name would encourage more use of 
the empty interface as a type for regular function parameters, because my 
estimate is that people are happy to use "generics" rather than the empty 
interface in function parameters when they can. Most Go programmers want to 
be type safe and avoid casting.

-- 
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/a4d6050c-5e44-4849-a682-80a808d12417n%40googlegroups.com.

Re: [go-nuts] "Interfaces" with type lists are a strange beast

[Randall O'Reilly]

FWIW, the "generic types" alternative syntax proposal: 
https://github.com/golang/go/issues/39669 includes an explicit distinction 
between generic interfaces and regular interfaces, and an earlier iteration of 
this idea included a new keyword, e.g., `prototype`, that would signal this 
distinction more clearly.  The current proposal instead just states that a 
generic interface must include a type list, and if there are no constraints, it 
is just a "fully generic" type list: `type type`, to signal that it is a 
generic interface.

In any case I do think that, conceptually, for the user's benefit and mental 
model of what is going on, it would be useful overall to have a clear 
distinction between generic and non-generic types, while also preserving the 
shared aspects as much as possible.  Interfaces *are* a form of generic-ness 
after all.

One additional idea would be that generic interfaces can embed regular 
interfaces, as a way to share code while also maintaining the clear conceptual 
distinction:

type GenericStringer interface {
   Stringer  // include standard Stringer interface
   type type // makes it a generic interface
}

If a separate keyword such as `prototype` were used to further distinguish from 
regular interfaces, it would be simpler and clearer:

type GenericStringer prototype {
Stringer  // prototypes can embed interfaces, but not the other way around
}

- Randy

> On Aug 3, 2020, at 4:00 PM, Ben Hoyt  wrote:
> 
> Per Ian's suggestion on the other thread I started
> (https://groups.google.com/g/golang-nuts/c/u9jqLPhEYO0/m/tnqezci8AwAJ),
> I'm breaking out this topic into a separate thread:
> 
> It seems strange to me that interfaces with type lists are really a
> different beast than regular interfaces, and aren't even meaningful as
> regular interfaces. (Trying to do that gives the error "interface type
> for variable cannot contain type constraints", which is relatively
> clear, at least.) As soon as an "interface" has a type list, it's not
> really a Go interface anymore (and interfaces with *only* type lists
> are not really interfaces at all, just type constraints). This seems
> confusing, though I'm not sure what the solution is.
> 
> Ian noted that this is mentioned very briefly at
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-lists-in-interface-types
> but that he can't recall much discussion on this point.
> 
> That section in the draft design notes starkly that "They may not be
> used as ordinary interface types." And then:
> 
> "This restriction may be lifted in future language versions. An
> interface type with a type list may be useful as a form of sum type,
> albeit one that can have the value nil. Some alternative syntax would
> likely be required to match on identical types rather than on
> underlying types; perhaps type ==. For now, this is not permitted."
> 
> That seems a little far-fetched to me, almost like a justification of
> what we know to be odd / confusing in this proposal.
> 
> In terms of a "solution" for this, one that I'm sure has been thought
> about: what about keeping type constraints and interfaces completely
> separate? They are half the time anyway (when there are type lists),
> so why not make them separate all the time.
> 
> I realize this may be heading back towards contracts (though without
> the funky syntax for operators). I think the "Featherweight Go" paper
> says "we don't need two different concepts here", but the paper
> doesn't seem to discuss "type lists" at all (and type lists seem very
> important to this proposal, and definitely are to this immediate
> discussion).
> 
> Anyway, instead of saying "interface" you'd say "constraint":
> 
> // this isn't really an interface, so don't call it one:
> type SignedInteger constraint {
>type int, int8, int16, int32, int64
> }
> 
> // this also can't be used as in interface, so don't call it one
> type ComparableHasher constraint {
>comparable
>Hash() uintptr
> }
> 
> // yes, this duplicates the Stringer interface for use as a type constraint
> type Stringable constraint {
>String() string
> }
> 
> I realize in the design draft the "Stringer" interface is used as a
> type constraint heavily, but that seems like a bit of an example/toy.
> In real-world code, how likely is it that we'll be using lots of
> existing interfaces as constraints? To me it seems like that won't be
> common, but I don't have much to go on.
> 
> -Ben
> 
> -- 
> 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/CAL9jXCHa5%2B4LreE7acP_r3QEBMGKN6qzgzkLFv4VXsW5aoXfcw%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.

Re: [go-nuts] "Interfaces" with type lists are a strange beast

[Ben Hoyt]

Thanks for the thoughtful response.

> I'm still strongly in favor of not having it. In particular, there is a large 
> section of conceptual overlap between interfaces and constrained 
> type-parameters. And at least as far as function parameters go, an interface 
> parameter can always be re-written into a constrained type-parameter. At 
> least as long as we live in this overlap, it seems very confusing to have two 
> separate names for what is very much the same thing - specifying a subset of 
> valid types to use. It also has technological downsides, because if you 
> already have an `io.Reader` interface, you also need to have an equivalent 
> contract (or whatever we call this constraint kind) and vice-versa, if a 
> concept is more naturally translated one way or another.

You make some very good points. I'm inclined to agree (leaving type
lists aside for now).

> IMO the discussion about this is purely based on the idea of type-lists which 
> exists purely so as to support operators on type-parameters. And personally I 
> feel a better way to solve this solution would be to just drop that from the 
> design. IMO, the utility of this isn't really worth the cost. Especially 
> given that there's no way to write a function to work with *either* methods 
> *or* operators, so the actual practical utility is pretty small. Arguably you 
> need two copies of any function working with - one for "primitel types" using 
> operators and one for "composite types" using methods. That seems… inelegant 
> to say the least and I'm not convinced that it's better than to require 
> people to add a method to "primitive types" to use them in generic code.

I also really don't like the fact you'll need two different versions
in a lot of cases (eg: Min for builtin types, and Min for complex
types). Given this, I think it's fair enough to want to drop type
lists from the design.

> And IMO a more orthogonal solution to allowing use with "primitive types" 
> would be some form of operator overloading or endowing predeclared types with 
> suitable methods - either would allow us to actually write generic code that 
> could work with both primitive and composite types, without needing us to 
> introduce a separate way to specify constraints.

Ian has said that adding operator overloading would be a "big change
to the language", which is true. But so is adding generics, so we
could try to do it "while we're at it", as it seems like these two
features (using interfaces as type constraints, and operator
overloading via methods/interfaces) would work really well together.

Alternatively, like you suggest, we could just drop type lists and
punt that problem for now. (I realize it doesn't allow using operators
in generic functions.) It seems much better to go with a restricted
feature set than to go with this whole new thing (type lists) that
just doesn't fit in very well. Go often punts useful features that
don't seem to fit, like handle {} for errors, or try(). We could
always add them in later once people have more experience with "basic
generics", or take a different track like operator overloading, or
maybe something completely different.

> I think that's very likely. So far, in the 6 weeks I've been thinking about 
> how I'd use generics in Go, I have not considered a single use-case that uses 
> operators - and they all either used no constraints at all or pre-existing 
> interfaces or `comparable` (but even there, only for use as map-keys, not for 
> the actual comparison operator).

Yeah, if we dropped type lists, "comparable" is the one constraint I
think we'd still need to be useful, because it enables you to use type
constraints for map keys, as well as for the likes of a slices.Equal()
function. So what about simplifying the proposal to only allow
interface constraints or the single built-in "comparable" constraint?

At least in my usage, being able to write type-safe generic containers
and channel functions would be a great start, and more important than
being able to write a Min() or an Add() function that works across
various built-in types.

> PS: Just for posterity, I do think this has been discussed at least a little 
> bit:
> https://groups.google.com/forum/#!searchin/golang-nuts/type-list|sort:date/golang-nuts/jpw7ndLrjtQ/w20lhwVIAQAJ
> https://groups.google.com/forum/#!searchin/golang-nuts/type-list|sort:date/golang-nuts/CYMIK-Ojvi8/P6eos__vAAAJ
> https://groups.google.com/forum/#!searchin/golang-nuts/type-list|sort:date/golang-nuts/IABU_sD6SsA/xjMNy73kBgAJ
> (maybe others, this is just a very cursory search)

Thanks! Appreciate those links. I had seen Brent Mills'
"Orthogonalizing Type Lists" a while back, but I'll read it again.

-Ben

-- 
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 

Re: [go-nuts] "Interfaces" with type lists are a strange beast

['Axel Wagner' via golang-nuts]

On Tue, Aug 4, 2020 at 1:01 AM Ben Hoyt  wrote:

> In terms of a "solution" for this, one that I'm sure has been thought
> about: what about keeping type constraints and interfaces completely
> separate? They are half the time anyway (when there are type lists),
> so why not make them separate all the time.
>

They used to be. That's essentially what contracts used to be in the
previous iteration of the design.
Of course they also used a completely different syntax and way to define
the constraints, but this separation was one of the major changes between
the original contracts design and this new draft. At the time I (and
others) have argued against this separation:
https://blog.merovius.de/2018/09/05/scrapping_contracts.html#scrapping-contracts

I'm still strongly in favor of not having it. In particular, there is a
large section of conceptual overlap between interfaces and constrained
type-parameters. And at least as far as function parameters go, an
interface parameter can *always* be re-written into a constrained
type-parameter. At least as long as we live in this overlap, it seems very
confusing to have two separate names for what is very much the same thing -
specifying a subset of valid types to use. It also has technological
downsides, because if you already have an `io.Reader` interface, you also
need to have an equivalent contract (or whatever we call this constraint
kind) and vice-versa, if a concept is more naturally translated one way or
another.

So, just as it can be argued that certain kinds of constraints are very
different from interfaces, so it's confusing to conflate them, it can also
be argued that many (if not most) constraints are exactly the same thing as
interfaces, so it's confusing to separate them. AIUI, the evolution of the
design then basically progressed from "so maybe we should allow interfaces
as constraints as well as contracts, to simplify things" to "it turns out
we don't really need contracts as a separate concept after all, so it is
cleaner to leave them out".

IMO the discussion about this is purely based on the idea of type-lists
which exists purely so as to support operators on type-parameters. And
personally I feel a better way to solve this solution would be to just drop
that from the design. IMO, the utility of this isn't really worth the cost.
Especially given that there's no way to write a function to work with
*either* methods *or* operators, so the actual practical utility is pretty
small. Arguably you need two copies of any function working with - one for
"primitel types" using operators and one for "composite types" using
methods. That seems… inelegant to say the least and I'm not convinced that
it's better than to require people to add a method to "primitive types" to
use them in generic code. And IMO a more orthogonal solution to allowing
use with "primitive types" would be some form of operator overloading or
endowing predeclared types with suitable methods - either would allow us to
actually write generic code that could work with both primitive and
composite types, without needing us to introduce a separate way to specify
constraints.

That being said, I know that the people driving the design consider being
able to write generic code using operators non-optional, so I know that
this likely won't happen. But I do think it's important to allow using
interfaces as constraints and I do think that any benefit of separating the
concepts would probably vanish, as long as you allow that - being able to
have both seems to me the prototypical compromise, in that it combines the
downside of both ideas. So, personally, I still strongly believe that
re-using interfaces is the right design.

I realize in the design draft the "Stringer" interface is used as a
> type constraint heavily, but that seems like a bit of an example/toy.

In real-world code, how likely is it that we'll be using lots of
> existing interfaces as constraints?


I think that's very likely. So far, in the 6 weeks I've been thinking about
how I'd use generics in Go, I have not considered a single use-case that
uses operators - and they all either used no constraints at all or
pre-existing interfaces or `comparable` (but even there, only for use as
map-keys, not for the actual comparison operator).

I also don't think "pre-existing" is the right lense. More interesting is:
How many constraints would *also* be useful as types? And I'd argue that
probably *every* constraint that is implemented mostly by composite types
(for example any abstract data structure, which is a *huge* chunk of
use-cases for generics) would also be useful as a type in its own right
(and obviously can't be used with operators then).

If you want a constraint to also be useable as a type, you either end up
a) having to write down two declarations which are identical, except one
says "interface" and one "constraint" - which seems confusing, because if
the declarations are identical, why do you both of them? Or
b) making it 

Re: [go-nuts] A few thoughts on type parameters

['Dan Kortschak' via golang-nuts]

On Mon, 2020-08-03 at 10:45 -0700, Ian Lance Taylor wrote:
> Another possibility is constraints.Any, although that is no shorter
> than interface{}.  I'm not sure _ is best; currently _ fairly
> consistently means "ignore this value," but in this usage it would
> mean something different.

Another possibility would be `...` which at least in the context of
arrays means "fill this in with the information you have elsewhere";
`var a [...]int{1,2,3,4}`. There is no other use of the ellipsis
operator in the type parameters, so this should work.

Dan


-- 
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/9918b7c7fe023f40f56874e2de1b42eb67297041.camel%40kortschak.io.

[go-nuts] "Interfaces" with type lists are a strange beast

[Ben Hoyt]

Per Ian's suggestion on the other thread I started
(https://groups.google.com/g/golang-nuts/c/u9jqLPhEYO0/m/tnqezci8AwAJ),
I'm breaking out this topic into a separate thread:

It seems strange to me that interfaces with type lists are really a
different beast than regular interfaces, and aren't even meaningful as
regular interfaces. (Trying to do that gives the error "interface type
for variable cannot contain type constraints", which is relatively
clear, at least.) As soon as an "interface" has a type list, it's not
really a Go interface anymore (and interfaces with *only* type lists
are not really interfaces at all, just type constraints). This seems
confusing, though I'm not sure what the solution is.

Ian noted that this is mentioned very briefly at
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-lists-in-interface-types
but that he can't recall much discussion on this point.

That section in the draft design notes starkly that "They may not be
used as ordinary interface types." And then:

"This restriction may be lifted in future language versions. An
interface type with a type list may be useful as a form of sum type,
albeit one that can have the value nil. Some alternative syntax would
likely be required to match on identical types rather than on
underlying types; perhaps type ==. For now, this is not permitted."

That seems a little far-fetched to me, almost like a justification of
what we know to be odd / confusing in this proposal.

In terms of a "solution" for this, one that I'm sure has been thought
about: what about keeping type constraints and interfaces completely
separate? They are half the time anyway (when there are type lists),
so why not make them separate all the time.

I realize this may be heading back towards contracts (though without
the funky syntax for operators). I think the "Featherweight Go" paper
says "we don't need two different concepts here", but the paper
doesn't seem to discuss "type lists" at all (and type lists seem very
important to this proposal, and definitely are to this immediate
discussion).

Anyway, instead of saying "interface" you'd say "constraint":

// this isn't really an interface, so don't call it one:
type SignedInteger constraint {
type int, int8, int16, int32, int64
}

// this also can't be used as in interface, so don't call it one
type ComparableHasher constraint {
comparable
Hash() uintptr
}

// yes, this duplicates the Stringer interface for use as a type constraint
type Stringable constraint {
String() string
}

I realize in the design draft the "Stringer" interface is used as a
type constraint heavily, but that seems like a bit of an example/toy.
In real-world code, how likely is it that we'll be using lots of
existing interfaces as constraints? To me it seems like that won't be
common, but I don't have much to go on.

-Ben

-- 
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/CAL9jXCHa5%2B4LreE7acP_r3QEBMGKN6qzgzkLFv4VXsW5aoXfcw%40mail.gmail.com.

Re: [go-nuts] A few thoughts on type parameters

[Ben Hoyt]

> That is an experiment.  We don't seem to need the type keyword for
> generic functions.  But we do need it for generic types, to avoid
> confusion with an array type (but only if there is exactly one type
> parameter with no constraint).  I'm not personally a big fan of
> optional syntax, so we will probably make a decision one way or
> another.

Yeah, I agree -- I think having it optional for functions but not for
types is a bit confusing. I do like the fact that you don't need to
write "type" or list the constraints on the type in methods, though --
that would be really verbose.

> Another possibility is constraints.Any, although that is no shorter
> than interface{}.  I'm not sure _ is best; currently _ fairly
> consistently means "ignore this value," but in this usage it would
> mean something different.

Yeah, I don't think 'import "constraints"' and then "constraints.Any"
is any (ahem) better. Maybe slightly more self-documenting.

> Yet another possibility, going back to the syntax question above, is
> requiring that a type parameter for a type alway have a constraint,
> which would mean that we would never use the "type" keyword for type
> parameters, and define a predeclared identifier "any = interface{}".

Interesting idea, I kinda like that. At first thought, when there's no
constraints I think "[type T]" is slightly clearer than "[T any]". But
then again, this latter syntax parallels normal types where you always
have to specify it, e.g., "v int", "x interface{}", etc.

I notice in one of the examples in the repo you define a short name:
"type any interface{}". Which at first seems like a good idea, but
then unless "any" is built in or this becomes a well-known idiom, it
won't be as self-documenting. Other people will have to look up the
definition to see "oh, I see, this is just short-hand for an empty
constraint".

> > (b) When I left off the "comparable" constraint the error message was
> > a bit cryptic: "invalid map key type K". "But why?", was my immediate
> > thought. Hopefully it'd be fairly easy to improve that error message.
> > Maybe something like "type K can't be used as map key; need
> > 'comparable' constraint?"
>
> Thanks.  Filed https://golang.org/issue/40551.

Thanks!

> It's mentioned very briefly at
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-lists-in-interface-types
> .  I can't recall much discussion on this point.  Perhaps any
> discussion should go in a different thread, though.

Thanks. I might start that as a separate thread, then, and see if
anyone has any thoughts.

> There have been several examples posted to this list, and of course
> there is 
> https://go.googlesource.com/go/+/refs/heads/dev.go2go/src/cmd/go2go/testdata/go2path/src
> .  But I can't recall seeing any really large real world examples.

Thanks. I actually didn't know about / had forgotten about this
repository of examples. I realize parts of many of them are in the
draft design, but it's nice to see them all in one place.

-Ben

-- 
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/CAL9jXCEpUiyHn3nw%3D1n8FuFZi2rM0Sc%3Durw%3D8RJXEOFy0vcBrQ%40mail.gmail.com.

Re: [go-nuts] A few thoughts on type parameters

['Carla Pfaff' via golang-nuts]

On Monday, 3 August 2020 at 19:46:05 UTC+2 Ian Lance Taylor wrote:

> Yet another possibility, going back to the syntax question above, is 
> requiring that a type parameter for a type alway have a constraint, 
> which would mean that we would never use the "type" keyword for type 
> parameters, and define a predeclared identifier "any = interface{}". 
>

Thanks for considering this possibility. Why I like it:

   - Type parameter lists and function parameter lists have the same 
   structure. Constraint is to type parameter as type is to function parameter.
   - Even more symmetry between declaration and instantiation than before: 
   No "type" keyword at instantiation, no "type" keyword at declaration.
   - Type parameter lists do not suddenly take on a different shape when 
   they are a mixture of constrained and unconstrained type parameters 
   compared to fully unconstrained type parameter lists:
  - Without "type" keyword
 - [A, B any] and [A any, B comparable] // No surprise
  - With "type" keyword
 - [type A, B] and [type A interface{}, B comparable] // A wild 
 interface{} appears!
  

-- 
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/177f43c1-70d9-4c24-8eee-e2e02cc81925n%40googlegroups.com.

[go-nuts] Re: How to allow library callers to control logging

[Tamás Gulácsi]

I'm using the  go-kit/kit/log 
(https://pkg.go.dev/github.com/go-kit/kit/log?tab=doc#Logger) abstraction:

Log(keyvals ...interface{}) error

This can be set in my library, and uses with logfmt, if given.

leo.b...@npo-data.nl a következőt írta (2020. augusztus 3., hétfő, 18:33:11 
UTC+2):

> Not sure if this is what you are looking for, but 
> https://github.com/go-logr/logr seems to address log abstraction.
>
> On Friday, July 31, 2020 at 3:05:03 AM UTC+2 fai...@google.com wrote:
>
>> I have a library that is used by cross platform binaries running in corp. 
>> Some of these binaries don't necessary run google.Init.
>>
>> My library is using base/go/log package but this doesn't work when 
>> google.Init isn't called. It prints to stderr with a message "ERROR: 
>> logging before google.Init". This crashes windows services which crash if 
>> there is anything written to stdout or stderr.
>>
>> My first thought was to have the callers provide a standard log.Logger 
>> instance which could be used instead of the base/go/log package. Most 
>> binaries could use the base/go/log NewStandardLogger function to get this. 
>> While windows services could have a logger instance which just writes out 
>> to ioutil.Discard. The downside is I will need multiple *log.Logger 
>> instances for different log levels which doesn't seem great.  
>>
>> Is there a better way to do 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/8bd69f3d-ed56-416e-8362-6d5f5d599009n%40googlegroups.com.

[go-nuts] [security] Go 1.14.7 and Go 1.13.15 pre-announcement

[Katie Hockman]

Hello gophers,

We plan to issue Go 1.14.7 and Go 1.13.15 on Thursday, August 6.

These are minor releases that include a security fix.



Following our policy at https://golang.org/security,

this is the pre-announcement of those releases.



Cheers,

Katie and Filippo on behalf of the Go team

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

Re: [go-nuts] Is it possible to build without TLS (thread local storage)?

[Evan Mesterhazy]

Thanks for confirming Ian, this is very helpful. I agree with the
implication that hacking Go on x86 to avoid TLS would not be a productive
use of time compared to adding TLS support to the operating system.

Thanks again.

On Sat, Aug 1, 2020 at 6:27 PM Ian Lance Taylor  wrote:

> On Sat, Aug 1, 2020 at 2:46 PM  wrote:
> >
> > You're right - after re-reading this I realize I could have been more
> specific.
> >
> > I am working with a custom OS kernel that supports a subset of Linux
> syscalls. However, it does not support TLS, which on i386 I believe
> typically requires OS support to set up and restore the GDT and %gs segment
> register between context switches.
> >
> > My understanding is that TLS using segment registers on i386 is largely
> a speed and syntax optimization, but that thread specific data can be
> managed without it (see glibc's pthread_setspecific() api). I am currently
> building C programs for this OS by compiling for Linux / i386 using
> uClibc-ng configured to disable TLS. I'm wondering if there is a similar
> configuration option to build Go programs without TLS so that I can run
> them on my OS.
> >
> > Please let me know if I can clarify anything further.
>
> While technically it might be possible to use something like
> pthread_setspecific to handle Go's needs, 1) there is no support for
> that in the current toolchain; 2) the execution time cost would be
> significant.  On x86 Go currently stores the stack guard in an offset
> from the TLS segment register, and it checks that value at the entry
> to (almost) every function.  Requiring some sort of function call
> would be a big slowdown at every function call.  Also, come to think
> of it, I'm not sure how to implement it; even pthread_setspecific
> relies on TLS.
>
> One option would be to change Go on x86 to store the required
> information in a register.  That is how it works on some other
> processors, so it would be feasible, but not at all simple.  And you
> would be using a custom port of Go that would not interoperate with
> standard Go.
>
> Ian
>


-- 
Evan Mesterhazy
evan.mesterh...@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/CAN2qZSPFhR-RW3_bvGfnr-Lzdd2QDDiMn6W3ZRb-5_B0JDvYQw%40mail.gmail.com.

Re: [go-nuts] A few thoughts on type parameters

[Ian Lance Taylor]

On Mon, Aug 3, 2020 at 1:48 AM Ben Hoyt  wrote:
>
> I've played with generics a bit more, including the new square
> brackets syntax. A few notes (some of the threads have been long, so
> apologies if I'm doubling up):

Thanks for the extensive feedback.


> Related question: why does the current go2go playground allow "func
> Ptr[T](v T) *T { return  }"? Though it turns [T] into [type T] when
> you click "Format". Is the former syntax without the "type" keyword
> (func Ptr[T]) going to be allowed, even if not encouraged?

That is an experiment.  We don't seem to need the type keyword for
generic functions.  But we do need it for generic types, to avoid
confusion with an array type (but only if there is exactly one type
parameter with no constraint).  I'm not personally a big fan of
optional syntax, so we will probably make a decision one way or
another.



> (a) Needing "interface{}" (on the V type) just feels klunky. I kinda
> understand why -- if any of them have a constraint, all of them have
> to -- but I wonder if there's a way to avoid this. Maybe "_" instead
> of "interface{}"?

Another possibility is constraints.Any, although that is no shorter
than interface{}.  I'm not sure _ is best; currently _ fairly
consistently means "ignore this value," but in this usage it would
mean something different.

Yet another possibility, going back to the syntax question above, is
requiring that a type parameter for a type alway have a constraint,
which would mean that we would never use the "type" keyword for type
parameters, and define a predeclared identifier "any = interface{}".


> (b) When I left off the "comparable" constraint the error message was
> a bit cryptic: "invalid map key type K". "But why?", was my immediate
> thought. Hopefully it'd be fairly easy to improve that error message.
> Maybe something like "type K can't be used as map key; need
> 'comparable' constraint?"

Thanks.  Filed https://golang.org/issue/40551.


> 4) It seems strange to me that interfaces with type lists are really a
> different beast than regular interfaces, and aren't even meaningful as
> regular interfaces. (Trying to do that gives the error "interface type
> for variable cannot contain type constraints", which is relatively
> clear, at least.) As soon as an "interface" has a type list, it's not
> really a Go interface anymore (and interfaces with *only* type lists
> are not really interfaces at all, just type constraints). This seems
> confusing, though I'm not sure what the solution is. Has this been
> discussed elsewhere?

It's mentioned very briefly at
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-lists-in-interface-types
.  I can't recall much discussion on this point.  Perhaps any
discussion should go in a different thread, though.


> 5) The ordered Map type shown in the draft design uses a "compare"
> function. Won't that mean there's always the performance hit of
> calling a function via pointer? Or will the compiler be smart enough
> to inline that if you're passing in a function literal (seems
> unlikely, as it probably doesn't know it won't change). Then again, I
> guess it's only going to be a small performance hit, and is similar to
> the "issue" with sort, which isn't actually an issue for most use
> cases.

I really don't know what the performance effect of this approach will
be.  I agree that inlining doesn't seem too likely here.  But for more
performance sensitive uses we could perhaps require that the Key type
have a Compare method, in which case inlining would be more likely
under certain implementation techniques.


> A more general question while I'm here: Ian or Robert mentioned on
> that recent Go Time podcast something to the effect that people are
> pushing generics to its limits. However, most of the examples in the
> draft design, and most examples I've seen on the mailing list, are
> pretty small examples of simple things. Is there a compilation of
> larger or more real-world examples?

There have been several examples posted to this list, and of course
there is 
https://go.googlesource.com/go/+/refs/heads/dev.go2go/src/cmd/go2go/testdata/go2path/src
.  But I can't recall seeing any really large real world examples.

To be clear, pushing generics to its limits is fine too.

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/CAOyqgcXkhpps8gxJMt_yGeye8h6Yv_JNU%2Btd9rLJ2%3DCyfzH88g%40mail.gmail.com.

[go-nuts] Re: How to allow library callers to control logging

[leo.b...@npo-data.nl]

Not sure if this is what you are looking for, but 
https://github.com/go-logr/logr seems to address log abstraction.

On Friday, July 31, 2020 at 3:05:03 AM UTC+2 fai...@google.com wrote:

> I have a library that is used by cross platform binaries running in corp. 
> Some of these binaries don't necessary run google.Init.
>
> My library is using base/go/log package but this doesn't work when 
> google.Init isn't called. It prints to stderr with a message "ERROR: 
> logging before google.Init". This crashes windows services which crash if 
> there is anything written to stdout or stderr.
>
> My first thought was to have the callers provide a standard log.Logger 
> instance which could be used instead of the base/go/log package. Most 
> binaries could use the base/go/log NewStandardLogger function to get this. 
> While windows services could have a logger instance which just writes out 
> to ioutil.Discard. The downside is I will need multiple *log.Logger 
> instances for different log levels which doesn't seem great.  
>
> Is there a better way to do 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/48b1f7ab-949d-4aa3-81e3-c92a784b11can%40googlegroups.com.

[go-nuts] Re: directory name and module name not same, go tool pprof, list function faild

[Lee Rick]

se the combination of "-source_path" and "-trim_path"  still not work


my project dir tree

macbookpro:tejia_analysis fredlee$ pwd

/Users/fredlee/Documents/xxx/tool/tejia_analysis

macbookpro:tejia_analysis fredlee$ tree util

util

├── analysis.go

├── configure.go

├── cron.go

├── job_discount.go

├── kv_bolt.go

├── mongo_client.go

├── mongo_globalairport.go

├── mysql_aircompany.go

├── mysql_client.go

├── mysql_convertcode.go

├── mysql_icmmgt_top_route.go

└── redis_client.go


0 directories, 12 files



go mod  name

macbookpro:tejia_analysis fredlee$ cat go.mod 

module app_server


go 1.14


在 2020年7月31日星期五 UTC+8下午8:00:02，Vladimir Varankin写道：
>
> Hey,
>
> In your example, "~/Documents/tool/tejia_analysis" is your module's source 
> root, right? Could you show where "app_server/util/analysis.go" is on the 
> FS and what is the name of the module?
>
> pprof has a coupe flags to manipulate with the path, helping it to search 
> for the source code. I used to use the combination of "-source_path" and 
> "-trim_path" to map my local source code to the paths that were embedded 
> into the app's binary.
>
> On Thursday, July 30, 2020 at 8:09:29 AM UTC+2 blade...@gmail.com wrote:
>
>> hi, i create a project, directory name and module name not same, and i 
>> profile it , use list command  to print code and profile, it tips me not 
>> find the file,  how to make it works?
>>
>>
>> macbookpro:tejia_analysis fredlee$ go tool pprof 
>> http://ip:6065/debug/pprof/heap
>>
>> Fetching profile over HTTP from http://ip:6065/debug/pprof/heap
>>
>> Saved profile in 
>> /Users/fredlee/pprof/pprof.tejia_analysis.alloc_objects.alloc_space.inuse_objects.inuse_space.006.pb.gz
>>
>> File: tejia_analysis
>>
>> Type: inuse_space
>>
>> Time: Jul 30, 2020 at 2:03pm (CST)
>>
>> Entering interactive mode (type "help" for commands, "o" for options)
>>
>> (pprof) top20 -cum
>>
>> Showing nodes accounting for 2509.12MB, 98.97% of 2535.11MB total
>>
>> Dropped 37 nodes (cum <= 12.68MB)
>>
>>   flat  flat%   sum%cum   cum%
>>
>>  0 0% 0%  2533.11MB 99.92%  
>> app_server/util.(*Analysis).Job
>>
>>  0 0% 0%  2533.11MB 99.92%  
>> app_server/util.(*Analysis).Start
>>
>>  1007.72MB 39.75% 39.75%  2523.10MB 99.53%  
>> app_server/util.(*Analysis).LoadSearchLog
>>
>>  0 0% 39.75%  1466.37MB 57.84%  
>> go.mongodb.org/mongo-driver/bson.(*Decoder).Decode
>>
>>  0 0% 39.75%  1466.37MB 57.84%  
>> go.mongodb.org/mongo-driver/bson.UnmarshalWithRegistry
>>
>>  0 0% 39.75%  1466.37MB 57.84%  
>> go.mongodb.org/mongo-driver/bson.unmarshalFromReader
>>
>>  0 0% 39.75%  1466.37MB 57.84%  
>> go.mongodb.org/mongo-driver/bson/bsoncodec.(*StructCodec).DecodeValue
>>
>>  0 0% 39.75%  1466.37MB 57.84%  
>> go.mongodb.org/mongo-driver/mongo.(*Cursor).Decode (inline)
>>
>>  0 0% 39.75%  1457.37MB 57.49%  
>> go.mongodb.org/mongo-driver/bson/bsoncodec.(*StringCodec).DecodeValue
>>
>>  0 0% 39.75%  1457.37MB 57.49%  
>> go.mongodb.org/mongo-driver/bson/bsonrw.(*valueReader).ReadString
>>
>>  1457.37MB 57.49% 97.24%  1457.37MB 57.49%  
>> go.mongodb.org/mongo-driver/bson/bsonrw.(*valueReader).readString 
>> 
>>
>>  0 0% 97.24%44.03MB  1.74%  net/url.ParseQuery (inline)
>>
>>44.03MB  1.74% 98.97%44.03MB  1.74%  net/url.parseQuery
>>
>> (pprof) list LoadSearchLog
>>
>> Total: 2.48GB
>>
>> ROUTINE  
>> app_server/util.(*Analysis).LoadSearchLog in app_server/util/analysis.go
>>
>>  1007.72MB 2.46GB (flat, cum) 99.53% of Total
>>
>>  Error: could not find file app_server/util/analysis.go on path 
>> /Users/fredlee/Documents/tool/tejia_analysis
>>
>>
>>

-- 
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/91c42518-f47c-471b-b32c-767a0a0e3225o%40googlegroups.com.

[go-nuts] A few thoughts on type parameters

[Ben Hoyt]

I've played with generics a bit more, including the new square
brackets syntax. A few notes (some of the threads have been long, so
apologies if I'm doubling up):

1) I definitely prefer the square brackets syntax. It makes it clear
where you're using type parameters, and IMO it sets them off much more
nicely than parentheses -- especially in method definitions where it
would be parens inside parens.

Related question: why does the current go2go playground allow "func
Ptr[T](v T) *T { return  }"? Though it turns [T] into [type T] when
you click "Format". Is the former syntax without the "type" keyword
(func Ptr[T]) going to be allowed, even if not encouraged?

2) Speaking of "func Ptr", I'll be really glad when we can write that
simple function generically, rather than all these libraries
implementing this for dozens of different types (e.g., the AWS SDK,
protobufs, a version in our own utility library at work, and I'm sure
we're not the only ones...). See also the proposal to allow the syntax
(v) natively to solve this problem:
https://github.com/golang/go/issues/9097 ... I am still a fan of that
proposal, but it'll be much less necessary if this proposal goes
ahead.

3) Defining new container types is fairly straight-forward (here's me
playing with a Map type: https://go2goplay.golang.org/p/y2dGXqsgfEb).
Obviously a basic map type like this isn't needed as Go already has
one, but it'd be similar to build a type-parameterized,
concurrency-safe Map, some kind of ordered dictionary, a set type,
etc. But a couple of things I didn't love:

(a) Needing "interface{}" (on the V type) just feels klunky. I kinda
understand why -- if any of them have a constraint, all of them have
to -- but I wonder if there's a way to avoid this. Maybe "_" instead
of "interface{}"?

(b) When I left off the "comparable" constraint the error message was
a bit cryptic: "invalid map key type K". "But why?", was my immediate
thought. Hopefully it'd be fairly easy to improve that error message.
Maybe something like "type K can't be used as map key; need
'comparable' constraint?"

At work, we've definitely wanted a Set type fairly often; we ended up
defining IntSet, StringSet, and InterfaceSet. So it'll be really nice
to not have to write N set types, or fall back on an interface{}
version. Or maybe there will even be a simple generic set type added
to the stdlib.

4) It seems strange to me that interfaces with type lists are really a
different beast than regular interfaces, and aren't even meaningful as
regular interfaces. (Trying to do that gives the error "interface type
for variable cannot contain type constraints", which is relatively
clear, at least.) As soon as an "interface" has a type list, it's not
really a Go interface anymore (and interfaces with *only* type lists
are not really interfaces at all, just type constraints). This seems
confusing, though I'm not sure what the solution is. Has this been
discussed elsewhere?

5) The ordered Map type shown in the draft design uses a "compare"
function. Won't that mean there's always the performance hit of
calling a function via pointer? Or will the compiler be smart enough
to inline that if you're passing in a function literal (seems
unlikely, as it probably doesn't know it won't change). Then again, I
guess it's only going to be a small performance hit, and is similar to
the "issue" with sort, which isn't actually an issue for most use
cases.

Note that of the above points, #1 and #2 are positives, and #3-5 are
issues. #3a and #3b seem minor or easily fixed, and #5 is probably not
an issue unless it's really performance-sensitive code. But #4 seems
to me like a fairly significant oddity / concern.

A more general question while I'm here: Ian or Robert mentioned on
that recent Go Time podcast something to the effect that people are
pushing generics to its limits. However, most of the examples in the
draft design, and most examples I've seen on the mailing list, are
pretty small examples of simple things. Is there a compilation of
larger or more real-world examples?

Thanks,
Ben

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