FAQ
I agree. Coming from C++ and learning Go now, I am missing templates the
most (though generics as in Java would suffice given the cool interface
duck typing lark), followed soon after by things like a lack of function
overloading with different arguments (or any form of default arguments),
and lack of ternary operator.
On Tuesday, 26 July 2011 20:45:36 UTC+1, John Asmuth wrote:

I think there are many things that people would like to have as built-ins,
mostly because the built-ins are allowed to be generic.

I'd rather we just had generics.
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Kevin Gillette at Jul 7, 2013 at 8:04 pm

    On Friday, July 5, 2013 10:39:35 AM UTC-6, jam...@gmail.com wrote:

    I am missing templates the most (though generics as in Java would suffice
    given the cool interface duck typing lark), followed soon after by things
    like a lack of function overloading with different arguments (or any form
    of default arguments), and lack of ternary operator.

    All of which were considered and deliberately excluded from the language.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Robert Melton at Jul 7, 2013 at 9:00 pm

    On Sun, Jul 7, 2013 at 4:04 PM, Kevin Gillette wrote:
    On Friday, July 5, 2013 10:39:35 AM UTC-6, jam...@gmail.com wrote:

    I am missing templates the most (though generics as in Java would suffice
    given the cool interface duck typing lark), followed soon after by things
    like a lack of function overloading with different arguments (or any form
    of default arguments), and lack of ternary operator.

    All of which were considered and deliberately excluded from the language.
    Isn't the door for generics still open if they can find a way to implement
    them that isn't atrocious?

    As for the other three points.
    - Function overloading ... 1 function name, 27 implementations... left out
    for a reason.
    - Default arguments can be emulated in various ways if you really want
    them, but isn't being explicit nice?
    - Ternary operator ... if ternary operator comes up in a "top 4 gripes" the
    language is doing incredibly well -- also, they are both pointless and evil
    to my mind.

    --
    Robert Melton

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Jul 8, 2013 at 3:50 am

    On Sunday, July 7, 2013 2:59:54 PM UTC-6, Robert Melton wrote:

    Isn't the door for generics still open if they can find a way to implement
    them that isn't atrocious?
    That's pretty much the criterion for the inclusion of anything. Most things
    that C++ added to C are atrocious in their appearance and design, and many
    of those concepts are atrocious regardless of their particular language
    implementation, hence most things that C++ innovated will never make it
    into Go (and surely not in their C++ form).

    As for the other three points.
    - Function overloading ... 1 function name, 27 implementations... left out
    for a reason.
    More generally, it encourages the programmer to be non-deliberate in their
    API design. It also results in lack of clarity regarding behavior -- this
    would be somewhat mitigated if one of the implementations must designated
    as primary and all other overloaded implementations must call the primary,
    ensuring that behavior is equivalent regardless of arguments/types involved
    and that all other implementations are simply convenience wrappers.

    - Default arguments can be emulated in various ways if you really want
    them, but isn't being explicit nice?
    Being explicit is desirable for readability. If you mean that allowing
    explicit default arguments rather than emulating them is nicer, it'd be
    ironic since default arguments are all about implicitness.

    - Ternary operator ... if ternary operator comes up in a "top 4 gripes"
    the language is doing incredibly well -- also, they are both pointless and
    evil to my mind.
    The ternary operator is a bane to readability, has subtly different (and
    always subtle) semantics among different languages, especially in terms of
    associativity; most programmers don't know how they work, and expressions
    involving nested ternaries often lead to stowaway bugs for corner cases
    that start wreaking havok well after you've forgotten what the code was
    supposed to do in the first place. Several languages claim to "do them
    right" (in terms of associativity), but for readability sake, "doing them
    right" should involve *requiring* parentheses to surround each ternary
    expression.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • John Nagle at Jul 8, 2013 at 4:17 am

    On 7/7/2013 8:49 PM, Kevin Gillette wrote:
    On Sunday, July 7, 2013 2:59:54 PM UTC-6, Robert Melton wrote:

    Isn't the door for generics still open if they can find a way to implement
    them that isn't atrocious?
    That's pretty much the criterion for the inclusion of anything.
        It's really hard to fit user-defined generics into Go. Most of
    the obvious ways lead to horrid messes.

        Go does have parameterized types. Channels and maps are
    parameterized types. It just doesn't have user-defined parameterized
    types.

        Building in a few more generic functions might be worthwhile.
    "min" and "max" as built-ins would not be out of place.
    A few other useful operations:

    - a built-in "deep copy' for any type which is nonrecursive (i.e.
    cannot result in a pointer to itself, and thus represents at worst
    a tree of finite depth

    - a built-in conversion from a struct type to an array of interfaces

    - a built in conversion from an array of interfaces to a struct type

    These are all common operations which can be done with reflection,
    but slowly, and can be done very efficiently with code generated
    for the specific type involved. The last two come up in marshalling
    and unmarshalling, as when talking to a database or dissecting JSON
    or XML.

    Unless there's a significant performance win over a reflection-based
    solution, it's probably not worth the trouble to add a generic function.

         John Nagle

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Liigo Zhuang at Aug 21, 2013 at 4:58 am
    2013/7/8 Robert Melton <rmelton@gmail.com>
    On Sun, Jul 7, 2013 at 4:04 PM, Kevin Gillette <extemporalgenome@gmail.com
    wrote:
    On Friday, July 5, 2013 10:39:35 AM UTC-6, jam...@gmail.com wrote:

    I am missing templates the most (though generics as in Java would
    suffice given the cool interface duck typing lark), followed soon after by
    things like a lack of function overloading with different arguments (or any
    form of default arguments), and lack of ternary operator.

    All of which were considered and deliberately excluded from the language.
    Isn't the door for generics still open if they can find a way to implement
    them that isn't atrocious?

    As for the other three points.
    - Function overloading ... 1 function name, 27 implementations... left out
    for a reason.
    - Default arguments can be emulated in various ways if you really want
    them, but isn't being explicit nice?
    - Ternary operator ... if ternary operator comes up in a "top 4 gripes"
    the language is doing incredibly well -- also, they are both pointless and
    evil to my mind.
    +1
    +1
    +1
    +10086 for generics

    --
    Robert Melton

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.



    --
    by *Liigo*, http://blog.csdn.net/liigo/
    Google+ https://plus.google.com/105597640837742873343/

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan Kortschak at Aug 21, 2013 at 5:33 am
    The C++ room is down the corridor.
    On Wed, 2013-08-21 at 12:58 +0800, Liigo Zhuang wrote:
    +1
    +1
    +1
    +10086 for generics

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Tor Langballe at Jul 8, 2013 at 2:08 pm
    I notice I actually need a function Maximize(a*, b) more than anything
    else; (and Minimize)

    I need to set a value a to another value b if b > a. This avoids having to
    repeat a long variable name too:

    rect.min.x = Max(rect.min.x, x)

    becomes

    Maximize(&rect.min.x, x)

    Personally, I have a folder "util" of shadow-packages beginning with "u"
    and then the same word as a standard package, that adds functionality that
    might typically perhaps have belonged in that package; Thus I have:

    umath.MaxInt64(a, b int64) int64
    and umath.Maximize(a *int64, b int64)

    in my umath package

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Thomas Dybdahl Ahle at Aug 21, 2013 at 12:35 am
    Right, so the ideal situation would be to use interfaces.
    If we could make 'func max(interface{<}, interface{<}) bool' and have it
    work on basic types. How awesome would it be?
    On Monday, April 5, 2010 7:57:02 AM UTC+2, Daniel Smith wrote:

    Oh wow, you're right-- whoops, somehow I missed those. Sweet! And now that
    I think about it more, I wouldn't expect max/min to accept complex numbers,
    or any type that can't be compared with <.

    On Mon, Apr 5, 2010 at 12:28 AM, jimmy frasche <soapbo...@gmail.com<javascript:>
    wrote:
    On Sun, Apr 4, 2010 at 10:24 PM, Daniel Smith <luken...@gmail.com<javascript:>>
    wrote:
    I don't know off the top of my head what max/min mean on complex numbers,
    but it seems like that's an issue to be resolved when/if we get a complex
    number type.
    We do have complex numbers. The complex numbers are unordered.


    --
    Daniel Smith
    http://www.schaumburggoclub.org/
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kyle Lemons at Aug 21, 2013 at 2:15 am

    On Tue, Aug 20, 2013 at 5:35 PM, Thomas Dybdahl Ahle wrote:

    Right, so the ideal situation would be to use interfaces.
    If we could make 'func max(interface{<}, interface{<}) bool' and have it
    work on basic types. How awesome would it be?
    How would you interpret `max(3.5, "foo")`? Both of those types have a <
    operator.
    On Monday, April 5, 2010 7:57:02 AM UTC+2, Daniel Smith wrote:

    Oh wow, you're right-- whoops, somehow I missed those. Sweet! And now
    that I think about it more, I wouldn't expect max/min to accept complex
    numbers, or any type that can't be compared with <.
    On Mon, Apr 5, 2010 at 12:28 AM, jimmy frasche wrote:

    On Sun, Apr 4, 2010 at 10:24 PM, Daniel Smith <luken...@gmail.com>
    wrote:
    I don't know off the top of my head what max/min mean on complex numbers,
    but it seems like that's an issue to be resolved when/if we get a complex
    number type.
    We do have complex numbers. The complex numbers are unordered.


    --
    Daniel Smith
    http://www.schaumburggoclub.**org/ <http://www.schaumburggoclub.org/>
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Aug 21, 2013 at 5:50 am
    Syntax is generally not considered the "hard" part of putting any further
    kind of generic programming into Go. For those "generics" aspects that are
    not yet covered, there's a fundamental tradeoff that nobody knows an
    effective way around, and which the community as a whole is not willing to
    choose either of the existing implementation routes: explosion of generated
    code, or erasure-style with low runtime efficiency (albeit, yes, static
    verification).

    That said, the _syntactic_ difficulty in specifying a max is that you must
    also specify a relationship _between_ function parameters, specifically
    that all parameters are the same type.
    On Tuesday, August 20, 2013 6:35:28 PM UTC-6, Thomas Dybdahl Ahle wrote:

    Right, so the ideal situation would be to use interfaces.
    If we could make 'func max(interface{<}, interface{<}) bool' and have it
    work on basic types. How awesome would it be?
    On Monday, April 5, 2010 7:57:02 AM UTC+2, Daniel Smith wrote:

    Oh wow, you're right-- whoops, somehow I missed those. Sweet! And now
    that I think about it more, I wouldn't expect max/min to accept complex
    numbers, or any type that can't be compared with <.
    On Mon, Apr 5, 2010 at 12:28 AM, jimmy frasche wrote:

    On Sun, Apr 4, 2010 at 10:24 PM, Daniel Smith <luken...@gmail.com>
    wrote:
    I don't know off the top of my head what max/min mean on complex numbers,
    but it seems like that's an issue to be resolved when/if we get a complex
    number type.
    We do have complex numbers. The complex numbers are unordered.


    --
    Daniel Smith
    http://www.schaumburggoclub.org/
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Luke Mauldin at Aug 21, 2013 at 4:59 pm
    Kevin,

    I liked the way you differentiated between the runtime aspect of generics
    and the syntactic difficulty of adding them to the language. I have read
    several of the generic discussions and that is a good distinction that is
    not often clearly understood.


    All,

    For the runtime part of the discussion, what about implementing generics
    similar to Microsoft's approach with C#? If I understand it correctly,
    they generate separate runtime code for each value type but all pointer
    types share the same runtime code. For example, if a program constructs
    these four lists: List<int>, List<bool>, List<string>, List<CustomType>.
      List<int> and List<bool> would have unique code but List<string> and
    List<CustomType> would share a common "template" based on a pointer type.


    Luke
    On Wednesday, August 21, 2013 12:50:44 AM UTC-5, Kevin Gillette wrote:

    Syntax is generally not considered the "hard" part of putting any further
    kind of generic programming into Go. For those "generics" aspects that are
    not yet covered, there's a fundamental tradeoff that nobody knows an
    effective way around, and which the community as a whole is not willing to
    choose either of the existing implementation routes: explosion of generated
    code, or erasure-style with low runtime efficiency (albeit, yes, static
    verification).

    That said, the _syntactic_ difficulty in specifying a max is that you must
    also specify a relationship _between_ function parameters, specifically
    that all parameters are the same type.
    On Tuesday, August 20, 2013 6:35:28 PM UTC-6, Thomas Dybdahl Ahle wrote:

    Right, so the ideal situation would be to use interfaces.
    If we could make 'func max(interface{<}, interface{<}) bool' and have it
    work on basic types. How awesome would it be?
    On Monday, April 5, 2010 7:57:02 AM UTC+2, Daniel Smith wrote:

    Oh wow, you're right-- whoops, somehow I missed those. Sweet! And now
    that I think about it more, I wouldn't expect max/min to accept complex
    numbers, or any type that can't be compared with <.
    On Mon, Apr 5, 2010 at 12:28 AM, jimmy frasche wrote:

    On Sun, Apr 4, 2010 at 10:24 PM, Daniel Smith <luken...@gmail.com>
    wrote:
    I don't know off the top of my head what max/min mean on complex numbers,
    but it seems like that's an issue to be resolved when/if we get a complex
    number type.
    We do have complex numbers. The complex numbers are unordered.


    --
    Daniel Smith
    http://www.schaumburggoclub.org/
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • GreatOdinsRaven at Aug 21, 2013 at 5:22 pm
    The CLR/C# approach was already discussed and rejected. The approach that
    MS took (which I'm a big fan of) has a lot of nuances that make its
    implementation difficult. I've been trying fruitlessly to find the reasons
    for it, I could only find this:
    https://groups.google.com/forum/#!topic/golang-nuts/PYJayE50JZg%5B76-100-false%5D.
    There was another discussion that was more specific and it had something to
    do with how an "interface" in CLR land doesn't jive with an "interface" in
    Go land.

    Another interesting thread I remember had someone proposing Ada-style
    generics (wish I knew Ada better...)

    I think it's safe to say that generics are *not* going to make it into Go
    at least until Go 2, it doesn't seem to be even a blip on the radar. At
    this point, either we copy-pasta code, or we go the interface{} +
    reflection route and that's all there is to it.
    On Wednesday, August 21, 2013 10:59:04 AM UTC-6, Luke Mauldin wrote:

    Kevin,

    I liked the way you differentiated between the runtime aspect of generics
    and the syntactic difficulty of adding them to the language. I have read
    several of the generic discussions and that is a good distinction that is
    not often clearly understood.


    All,

    For the runtime part of the discussion, what about implementing generics
    similar to Microsoft's approach with C#? If I understand it correctly,
    they generate separate runtime code for each value type but all pointer
    types share the same runtime code. For example, if a program constructs
    these four lists: List<int>, List<bool>, List<string>, List<CustomType>.
    List<int> and List<bool> would have unique code but List<string> and
    List<CustomType> would share a common "template" based on a pointer type.


    Luke
    On Wednesday, August 21, 2013 12:50:44 AM UTC-5, Kevin Gillette wrote:

    Syntax is generally not considered the "hard" part of putting any further
    kind of generic programming into Go. For those "generics" aspects that are
    not yet covered, there's a fundamental tradeoff that nobody knows an
    effective way around, and which the community as a whole is not willing to
    choose either of the existing implementation routes: explosion of generated
    code, or erasure-style with low runtime efficiency (albeit, yes, static
    verification).

    That said, the _syntactic_ difficulty in specifying a max is that you
    must also specify a relationship _between_ function parameters,
    specifically that all parameters are the same type.
    On Tuesday, August 20, 2013 6:35:28 PM UTC-6, Thomas Dybdahl Ahle wrote:

    Right, so the ideal situation would be to use interfaces.
    If we could make 'func max(interface{<}, interface{<}) bool' and have it
    work on basic types. How awesome would it be?
    On Monday, April 5, 2010 7:57:02 AM UTC+2, Daniel Smith wrote:

    Oh wow, you're right-- whoops, somehow I missed those. Sweet! And now
    that I think about it more, I wouldn't expect max/min to accept complex
    numbers, or any type that can't be compared with <.
    On Mon, Apr 5, 2010 at 12:28 AM, jimmy frasche wrote:

    On Sun, Apr 4, 2010 at 10:24 PM, Daniel Smith <luken...@gmail.com>
    wrote:
    I don't know off the top of my head what max/min mean on complex numbers,
    but it seems like that's an issue to be resolved when/if we get a complex
    number type.
    We do have complex numbers. The complex numbers are unordered.


    --
    Daniel Smith
    http://www.schaumburggoclub.org/
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Luke Mauldin at Aug 21, 2013 at 5:43 pm
    I completely understand that we will not see generics in Go until at least
    Go 2. However, can anyone help me understand a high-level overview of some
    of the nuances that would make implementation of the CLR generic approach
    difficult in Go?

    Luke
    On Wednesday, August 21, 2013 12:21:38 PM UTC-5, GreatOdinsRaven wrote:

    The CLR/C# approach was already discussed and rejected. The approach that
    MS took (which I'm a big fan of) has a lot of nuances that make its
    implementation difficult. I've been trying fruitlessly to find the reasons
    for it, I could only find this:
    https://groups.google.com/forum/#!topic/golang-nuts/PYJayE50JZg%5B76-100-false%5D.
    There was another discussion that was more specific and it had something to
    do with how an "interface" in CLR land doesn't jive with an "interface" in
    Go land.

    Another interesting thread I remember had someone proposing Ada-style
    generics (wish I knew Ada better...)

    I think it's safe to say that generics are *not* going to make it into Go
    at least until Go 2, it doesn't seem to be even a blip on the radar. At
    this point, either we copy-pasta code, or we go the interface{} +
    reflection route and that's all there is to it.
    On Wednesday, August 21, 2013 10:59:04 AM UTC-6, Luke Mauldin wrote:

    Kevin,

    I liked the way you differentiated between the runtime aspect of generics
    and the syntactic difficulty of adding them to the language. I have read
    several of the generic discussions and that is a good distinction that is
    not often clearly understood.


    All,

    For the runtime part of the discussion, what about implementing generics
    similar to Microsoft's approach with C#? If I understand it correctly,
    they generate separate runtime code for each value type but all pointer
    types share the same runtime code. For example, if a program constructs
    these four lists: List<int>, List<bool>, List<string>, List<CustomType>.
    List<int> and List<bool> would have unique code but List<string> and
    List<CustomType> would share a common "template" based on a pointer type.


    Luke
    On Wednesday, August 21, 2013 12:50:44 AM UTC-5, Kevin Gillette wrote:

    Syntax is generally not considered the "hard" part of putting any
    further kind of generic programming into Go. For those "generics" aspects
    that are not yet covered, there's a fundamental tradeoff that nobody knows
    an effective way around, and which the community as a whole is not willing
    to choose either of the existing implementation routes: explosion of
    generated code, or erasure-style with low runtime efficiency (albeit, yes,
    static verification).

    That said, the _syntactic_ difficulty in specifying a max is that you
    must also specify a relationship _between_ function parameters,
    specifically that all parameters are the same type.
    On Tuesday, August 20, 2013 6:35:28 PM UTC-6, Thomas Dybdahl Ahle wrote:

    Right, so the ideal situation would be to use interfaces.
    If we could make 'func max(interface{<}, interface{<}) bool' and have
    it work on basic types. How awesome would it be?
    On Monday, April 5, 2010 7:57:02 AM UTC+2, Daniel Smith wrote:

    Oh wow, you're right-- whoops, somehow I missed those. Sweet! And now
    that I think about it more, I wouldn't expect max/min to accept complex
    numbers, or any type that can't be compared with <.
    On Mon, Apr 5, 2010 at 12:28 AM, jimmy frasche wrote:

    On Sun, Apr 4, 2010 at 10:24 PM, Daniel Smith <luken...@gmail.com>
    wrote:
    I don't know off the top of my head what max/min mean on complex numbers,
    but it seems like that's an issue to be resolved when/if we get a complex
    number type.
    We do have complex numbers. The complex numbers are unordered.


    --
    Daniel Smith
    http://www.schaumburggoclub.org/
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Luzon83 at Aug 21, 2013 at 6:07 pm

    On Wednesday, August 21, 2013 7:43:23 PM UTC+2, Luke Mauldin wrote:
    I completely understand that we will not see generics in Go until at least
    Go 2. However, can anyone help me understand a high-level overview of some
    of the nuances that would make implementation of the CLR generic approach
    difficult in Go?
    I'm no expert, and I didn't follow previous generics discussions, but the
    .NET JIT compiler generates the code at run time to avoid code bloat:

    "At run time, the actual machine code produced depends on whether the
    specified types are value or reference type. If the client specifies a
    value type, the JIT compiler replaces the generic type parameters in the IL
    with the specific value type, and compiles it to native code. However, the
    JIT compiler keeps track of type-specific server code it already generated.
    If the JIT compiler is asked to compile the generic server with a value
    type it has already compiled to machine code, it simply returns a reference
    to that server code."
    http://msdn.microsoft.com/en-us/library/aa479859.aspx#fundamentals_topic25

    AFAIK Go doesn't have a JIT compiler or intermediate language or runtime
    code generation.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Luke Mauldin at Aug 21, 2013 at 6:58 pm
    Although Go doesn't have a JIT compiler, I would think its regular compiler
    could generate all of the necessary code at compile time and the amount of
    code would be "as small as possible" due to features like code sharing,
    etc.
    How does Go support such efficient "generic" maps/slices? What are the
    factors limiting those solutions from solving the general runtime generic
    solution?

    Luke
    On Wednesday, August 21, 2013 1:07:49 PM UTC-5, luz...@gmail.com wrote:


    On Wednesday, August 21, 2013 7:43:23 PM UTC+2, Luke Mauldin wrote:

    I completely understand that we will not see generics in Go until at
    least Go 2. However, can anyone help me understand a high-level overview
    of some of the nuances that would make implementation of the CLR generic
    approach difficult in Go?
    I'm no expert, and I didn't follow previous generics discussions, but the
    .NET JIT compiler generates the code at run time to avoid code bloat:

    "At run time, the actual machine code produced depends on whether the
    specified types are value or reference type. If the client specifies a
    value type, the JIT compiler replaces the generic type parameters in the IL
    with the specific value type, and compiles it to native code. However, the
    JIT compiler keeps track of type-specific server code it already generated.
    If the JIT compiler is asked to compile the generic server with a value
    type it has already compiled to machine code, it simply returns a reference
    to that server code."
    http://msdn.microsoft.com/en-us/library/aa479859.aspx#fundamentals_topic25

    AFAIK Go doesn't have a JIT compiler or intermediate language or runtime
    code generation.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Aug 24, 2013 at 3:10 am
    Code sharing is computationally suboptimal most of the time -- type erasure
    (essentially treating everything like an interface{} value) has the most
    code sharing potential, but is more often than not considerably slower than
    specialization (which results in binary bloat, and potentially processor
    cache inefficiency). Some things can be done efficiently with respect to
    code sharing, such as slice element handling (e.g. reversing a slice),
    since the only type-dependent variable involved would be the size of the
    element type.

    On the other hand, something like a type-generic Max function is more
    involved... You could optimistically say that we only need one *primary*
    specialized version for each numeric type family (ints, uints, floats, and
    complex types), wherein each family's specialized version internally uses
    the greatest precision type in that familiy (i.e. all int handling uses
    int64 internally). However, to get to the point of using the family-generic
    implementation at runtime, the parameters must be converted to the
    internally-used type, meaning that the family-generic implementation must
    either, 1) be wrapped for each concrete type in that family, or 2) an
    erasure-style wrapper must be generated which takes something like an
    interface{} at runtime and type-asserts it to the internally used type.

    The problem with #1 is that comparison (and many things people pine over
    lack of generics for) do not require enough instructions compared to
    conversion to warrant any kind of code sharing (in this case, there'd be
    more code involved to adapt each type in a family to its implementation
    then there would be in making a self-contained specialized implementation
    for each type). People would also want to abuse the generics mechanism: if
    `func Less(x, y T) bool` can satisfy `func(x, y int8) bool`, then why not
    specify the generic implementation as `func Less(x T1, y T2) bool`, and
    have the compiler figure out every combination of inter-convertible types
    you ask for, so that it can satisfy `func(x int8, y int64) bool` and
    `func(x int64, y int8) bool` ? This could easily add megabytes worth of
    generated code just to satisfy the lazy/undisciplined whims of the
    programmer.

    The problem with #2 is that we already have that -- the language changes
    involved would pretty much just be a sugar coating on top of the reflection
    system, and compared to type-specific code, reflection is plain slow. Some
    of that slowness can be mitigated by the presence of a JIT optimizer, but
    that makes binaries a bit thicker and adds overhead in a number of places;
    to counteract the thickness, using shared libraries is often found to be an
    acceptable solution, but for a language ecosystem like Go's, where ease of
    deployment is considered a fundamental characteristic, for many of us the
    shared-library solution would be more trouble than it's worth.

    Regarding the .NET style solution (which I know nothing about): there may
    exist solutions with less drastic tradeoffs when used with a language
    designed around that solution. If it's said that there would be trouble
    adapting it for Go because of differing conceptualizations of interfaces, I
    would not be surprised (and would further be unsurprised if the .NET
    solution fundamentally could never be adapted to work with Go because of
    those differing assumptions). In this case, it's sounding like C# generics
    would have Java-esque memory problems if it generated all potentially
    needed specializations at compile time -- in many ways, Go tries to keep
    the role of the runtime light: handling anything related to
    scheduling/concurrency and garbage collection, but not much beyond that,
    while the .NET runtime seems to take a much more active role.
    On Wednesday, August 21, 2013 12:58:40 PM UTC-6, Luke Mauldin wrote:

    Although Go doesn't have a JIT compiler, I would think its regular
    compiler could generate all of the necessary code at compile time and the
    amount of code would be "as small as possible" due to features like code
    sharing, etc.
    How does Go support such efficient "generic" maps/slices? What are the
    factors limiting those solutions from solving the general runtime generic
    solution?

    Luke
    On Wednesday, August 21, 2013 1:07:49 PM UTC-5, luz...@gmail.com wrote:


    On Wednesday, August 21, 2013 7:43:23 PM UTC+2, Luke Mauldin wrote:

    I completely understand that we will not see generics in Go until at
    least Go 2. However, can anyone help me understand a high-level overview
    of some of the nuances that would make implementation of the CLR generic
    approach difficult in Go?
    I'm no expert, and I didn't follow previous generics discussions, but the
    .NET JIT compiler generates the code at run time to avoid code bloat:

    "At run time, the actual machine code produced depends on whether the
    specified types are value or reference type. If the client specifies a
    value type, the JIT compiler replaces the generic type parameters in the IL
    with the specific value type, and compiles it to native code. However, the
    JIT compiler keeps track of type-specific server code it already generated.
    If the JIT compiler is asked to compile the generic server with a value
    type it has already compiled to machine code, it simply returns a reference
    to that server code."
    http://msdn.microsoft.com/en-us/library/aa479859.aspx#fundamentals_topic25

    AFAIK Go doesn't have a JIT compiler or intermediate language or runtime
    code generation.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Luke Mauldin at Aug 26, 2013 at 2:11 pm
    Kevin,

    Thank you for the very detailed response. It was very helpful. I have one
    additional question, how were the problems you discussed resolved with the
    implementation of slices and maps?

    Luke
    On Friday, August 23, 2013 10:10:44 PM UTC-5, Kevin Gillette wrote:

    Code sharing is computationally suboptimal most of the time -- type
    erasure (essentially treating everything like an interface{} value) has the
    most code sharing potential, but is more often than not considerably slower
    than specialization (which results in binary bloat, and potentially
    processor cache inefficiency). Some things can be done efficiently with
    respect to code sharing, such as slice element handling (e.g. reversing a
    slice), since the only type-dependent variable involved would be the size
    of the element type.

    On the other hand, something like a type-generic Max function is more
    involved... You could optimistically say that we only need one *primary*
    specialized version for each numeric type family (ints, uints, floats, and
    complex types), wherein each family's specialized version internally uses
    the greatest precision type in that familiy (i.e. all int handling uses
    int64 internally). However, to get to the point of using the family-generic
    implementation at runtime, the parameters must be converted to the
    internally-used type, meaning that the family-generic implementation must
    either, 1) be wrapped for each concrete type in that family, or 2) an
    erasure-style wrapper must be generated which takes something like an
    interface{} at runtime and type-asserts it to the internally used type.

    The problem with #1 is that comparison (and many things people pine over
    lack of generics for) do not require enough instructions compared to
    conversion to warrant any kind of code sharing (in this case, there'd be
    more code involved to adapt each type in a family to its implementation
    then there would be in making a self-contained specialized implementation
    for each type). People would also want to abuse the generics mechanism: if
    `func Less(x, y T) bool` can satisfy `func(x, y int8) bool`, then why not
    specify the generic implementation as `func Less(x T1, y T2) bool`, and
    have the compiler figure out every combination of inter-convertible types
    you ask for, so that it can satisfy `func(x int8, y int64) bool` and
    `func(x int64, y int8) bool` ? This could easily add megabytes worth of
    generated code just to satisfy the lazy/undisciplined whims of the
    programmer.

    The problem with #2 is that we already have that -- the language changes
    involved would pretty much just be a sugar coating on top of the reflection
    system, and compared to type-specific code, reflection is plain slow. Some
    of that slowness can be mitigated by the presence of a JIT optimizer, but
    that makes binaries a bit thicker and adds overhead in a number of places;
    to counteract the thickness, using shared libraries is often found to be an
    acceptable solution, but for a language ecosystem like Go's, where ease of
    deployment is considered a fundamental characteristic, for many of us the
    shared-library solution would be more trouble than it's worth.

    Regarding the .NET style solution (which I know nothing about): there may
    exist solutions with less drastic tradeoffs when used with a language
    designed around that solution. If it's said that there would be trouble
    adapting it for Go because of differing conceptualizations of interfaces, I
    would not be surprised (and would further be unsurprised if the .NET
    solution fundamentally could never be adapted to work with Go because of
    those differing assumptions). In this case, it's sounding like C# generics
    would have Java-esque memory problems if it generated all potentially
    needed specializations at compile time -- in many ways, Go tries to keep
    the role of the runtime light: handling anything related to
    scheduling/concurrency and garbage collection, but not much beyond that,
    while the .NET runtime seems to take a much more active role.
    On Wednesday, August 21, 2013 12:58:40 PM UTC-6, Luke Mauldin wrote:

    Although Go doesn't have a JIT compiler, I would think its regular
    compiler could generate all of the necessary code at compile time and the
    amount of code would be "as small as possible" due to features like code
    sharing, etc.
    How does Go support such efficient "generic" maps/slices? What are the
    factors limiting those solutions from solving the general runtime generic
    solution?

    Luke
    On Wednesday, August 21, 2013 1:07:49 PM UTC-5, luz...@gmail.com wrote:


    On Wednesday, August 21, 2013 7:43:23 PM UTC+2, Luke Mauldin wrote:

    I completely understand that we will not see generics in Go until at
    least Go 2. However, can anyone help me understand a high-level overview
    of some of the nuances that would make implementation of the CLR generic
    approach difficult in Go?
    I'm no expert, and I didn't follow previous generics discussions, but
    the .NET JIT compiler generates the code at run time to avoid code bloat:

    "At run time, the actual machine code produced depends on whether the
    specified types are value or reference type. If the client specifies a
    value type, the JIT compiler replaces the generic type parameters in the IL
    with the specific value type, and compiles it to native code. However, the
    JIT compiler keeps track of type-specific server code it already generated.
    If the JIT compiler is asked to compile the generic server with a value
    type it has already compiled to machine code, it simply returns a reference
    to that server code."

    http://msdn.microsoft.com/en-us/library/aa479859.aspx#fundamentals_topic25

    AFAIK Go doesn't have a JIT compiler or intermediate language or runtime
    code generation.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Aug 26, 2013 at 8:50 pm

    On Monday, August 26, 2013 8:10:59 AM UTC-6, Luke Mauldin wrote:

    Kevin,

    Thank you for the very detailed response. It was very helpful. I have
    one additional question, how were the problems you discussed resolved with
    the implementation of slices and maps?
      The algorithms for handling maps and slices are comparatively simple.
    Slices can have a custom code generation per used type while maintaining a
    very small footprint, and the map implementation probably only needs a
    type-specific hash function and size-of-type information for each
    combination of key and value.

    Both of these, in their current implementation _could_ have had "generic"
    implementations if we had generics, but that doesn't mean the best approach
    would have been a "generics" implementation. If and when Go gets generics,
    that does not mean that it will include all aspects of generic programming
    that other languages have. For example, it's much less likely that we'll
    ever get operator overloading (we could have had those already, but we've
    intentionally avoided them).

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Luke Mauldin at Aug 26, 2013 at 11:34 pm
    So the Go compiler examines all of the slices in the program and generates
    a small amount of custom code for each unique slice type?

    Luke
    On Monday, August 26, 2013 3:50:27 PM UTC-5, Kevin Gillette wrote:
    On Monday, August 26, 2013 8:10:59 AM UTC-6, Luke Mauldin wrote:

    Kevin,

    Thank you for the very detailed response. It was very helpful. I have
    one additional question, how were the problems you discussed resolved with
    the implementation of slices and maps?
    The algorithms for handling maps and slices are comparatively simple.
    Slices can have a custom code generation per used type while maintaining a
    very small footprint, and the map implementation probably only needs a
    type-specific hash function and size-of-type information for each
    combination of key and value.

    Both of these, in their current implementation _could_ have had "generic"
    implementations if we had generics, but that doesn't mean the best approach
    would have been a "generics" implementation. If and when Go gets generics,
    that does not mean that it will include all aspects of generic programming
    that other languages have. For example, it's much less likely that we'll
    ever get operator overloading (we could have had those already, but we've
    intentionally avoided them).
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kyle Lemons at Aug 26, 2013 at 11:59 pm
    last time I checked, I thought it simply generated the code for a "copy" or
    "append" inline, based on the size of the type.

    On Mon, Aug 26, 2013 at 4:34 PM, Luke Mauldin wrote:

    So the Go compiler examines all of the slices in the program and generates
    a small amount of custom code for each unique slice type?

    Luke

    On Monday, August 26, 2013 3:50:27 PM UTC-5, Kevin Gillette wrote:
    On Monday, August 26, 2013 8:10:59 AM UTC-6, Luke Mauldin wrote:

    Kevin,

    Thank you for the very detailed response. It was very helpful. I have
    one additional question, how were the problems you discussed resolved with
    the implementation of slices and maps?
    The algorithms for handling maps and slices are comparatively simple.
    Slices can have a custom code generation per used type while maintaining a
    very small footprint, and the map implementation probably only needs a
    type-specific hash function and size-of-type information for each
    combination of key and value.

    Both of these, in their current implementation _could_ have had "generic"
    implementations if we had generics, but that doesn't mean the best approach
    would have been a "generics" implementation. If and when Go gets generics,
    that does not mean that it will include all aspects of generic programming
    that other languages have. For example, it's much less likely that we'll
    ever get operator overloading (we could have had those already, but we've
    intentionally avoided them).
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Aug 27, 2013 at 4:00 pm

    On Monday, August 26, 2013 5:58:38 PM UTC-6, Kyle Lemons wrote:

    last time I checked, I thought it simply generated the code for a "copy"
    or "append" inline, based on the size of the type.

    On Mon, Aug 26, 2013 at 4:34 PM, Luke Mauldin <lukem...@gmail.com<javascript:>
    wrote:
    So the Go compiler examines all of the slices in the program and
    generates a small amount of custom code for each unique slice type?
    @Luke: what Kyle said is what I meant. Slice operations are really *that *cheap
    -- for most of what you can do with a slice, the number of instructions
    involved are fewer (and cheaper) to do it inline than the number involved
    to push args on a stack and call either a type-specific or generic
    implementation (thus even if we had generics, it'd be hard to claim they'd
    be better for this purpose than what we're currently doing). Likewise, maps
    are also a solved problem, and last time I looked, they have enough
    differences to not be a useful reference of comparison to the problems with
    implementing generics in Go.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Atomly at Aug 26, 2013 at 4:02 pm
    What about option #3, generic template for the general case,, but JIT
    compiler makes specialized copies for types that are used often?

    Also, what do you mean by Java-esque memory problems?

    :: atomly ::

    [ atomly@atomly.com : www.atomly.com : http://blog.atomly.com/ ...
    [ atomiq records : new york city : +1.347.692.8661 ...
    [ e-mail atomly-news-subscribe@atomly.com for atomly info and updates ...

    On Fri, Aug 23, 2013 at 11:10 PM, Kevin Gillette wrote:

    Code sharing is computationally suboptimal most of the time -- type
    erasure (essentially treating everything like an interface{} value) has the
    most code sharing potential, but is more often than not considerably slower
    than specialization (which results in binary bloat, and potentially
    processor cache inefficiency). Some things can be done efficiently with
    respect to code sharing, such as slice element handling (e.g. reversing a
    slice), since the only type-dependent variable involved would be the size
    of the element type.

    On the other hand, something like a type-generic Max function is more
    involved... You could optimistically say that we only need one *primary*
    specialized version for each numeric type family (ints, uints, floats, and
    complex types), wherein each family's specialized version internally uses
    the greatest precision type in that familiy (i.e. all int handling uses
    int64 internally). However, to get to the point of using the family-generic
    implementation at runtime, the parameters must be converted to the
    internally-used type, meaning that the family-generic implementation must
    either, 1) be wrapped for each concrete type in that family, or 2) an
    erasure-style wrapper must be generated which takes something like an
    interface{} at runtime and type-asserts it to the internally used type.

    The problem with #1 is that comparison (and many things people pine over
    lack of generics for) do not require enough instructions compared to
    conversion to warrant any kind of code sharing (in this case, there'd be
    more code involved to adapt each type in a family to its implementation
    then there would be in making a self-contained specialized implementation
    for each type). People would also want to abuse the generics mechanism: if
    `func Less(x, y T) bool` can satisfy `func(x, y int8) bool`, then why not
    specify the generic implementation as `func Less(x T1, y T2) bool`, and
    have the compiler figure out every combination of inter-convertible types
    you ask for, so that it can satisfy `func(x int8, y int64) bool` and
    `func(x int64, y int8) bool` ? This could easily add megabytes worth of
    generated code just to satisfy the lazy/undisciplined whims of the
    programmer.

    The problem with #2 is that we already have that -- the language changes
    involved would pretty much just be a sugar coating on top of the reflection
    system, and compared to type-specific code, reflection is plain slow. Some
    of that slowness can be mitigated by the presence of a JIT optimizer, but
    that makes binaries a bit thicker and adds overhead in a number of places;
    to counteract the thickness, using shared libraries is often found to be an
    acceptable solution, but for a language ecosystem like Go's, where ease of
    deployment is considered a fundamental characteristic, for many of us the
    shared-library solution would be more trouble than it's worth.

    Regarding the .NET style solution (which I know nothing about): there may
    exist solutions with less drastic tradeoffs when used with a language
    designed around that solution. If it's said that there would be trouble
    adapting it for Go because of differing conceptualizations of interfaces, I
    would not be surprised (and would further be unsurprised if the .NET
    solution fundamentally could never be adapted to work with Go because of
    those differing assumptions). In this case, it's sounding like C# generics
    would have Java-esque memory problems if it generated all potentially
    needed specializations at compile time -- in many ways, Go tries to keep
    the role of the runtime light: handling anything related to
    scheduling/concurrency and garbage collection, but not much beyond that,
    while the .NET runtime seems to take a much more active role.
    On Wednesday, August 21, 2013 12:58:40 PM UTC-6, Luke Mauldin wrote:

    Although Go doesn't have a JIT compiler, I would think its regular
    compiler could generate all of the necessary code at compile time and the
    amount of code would be "as small as possible" due to features like code
    sharing, etc.
    How does Go support such efficient "generic" maps/slices? What are the
    factors limiting those solutions from solving the general runtime generic
    solution?

    Luke
    On Wednesday, August 21, 2013 1:07:49 PM UTC-5, luz...@gmail.com wrote:


    On Wednesday, August 21, 2013 7:43:23 PM UTC+2, Luke Mauldin wrote:

    I completely understand that we will not see generics in Go until at
    least Go 2. However, can anyone help me understand a high-level overview
    of some of the nuances that would make implementation of the CLR generic
    approach difficult in Go?
    I'm no expert, and I didn't follow previous generics discussions, but
    the .NET JIT compiler generates the code at run time to avoid code bloat:

    "At run time, the actual machine code produced depends on whether the
    specified types are value or reference type. If the client specifies a
    value type, the JIT compiler replaces the generic type parameters in the IL
    with the specific value type, and compiles it to native code. However, the
    JIT compiler keeps track of type-specific server code it already generated.
    If the JIT compiler is asked to compile the generic server with a value
    type it has already compiled to machine code, it simply returns a reference
    to that server code."
    http://msdn.microsoft.com/en-**us/library/aa479859.aspx#**
    fundamentals_topic25<http://msdn.microsoft.com/en-us/library/aa479859.aspx#fundamentals_topic25>

    AFAIK Go doesn't have a JIT compiler or intermediate language or runtime
    code generation.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Aug 26, 2013 at 8:44 pm

    On Monday, August 26, 2013 10:02:00 AM UTC-6, atomly wrote:

    What about option #3, generic template for the general case, but JIT
    compiler makes specialized copies for types that are used often?
    There are Go specific "cultural" downsides to this: 1) unless the JIT
    outputs bytecode to be interpreted rather than machine code to be directly
    executed, we'd have to give up non-executable memory pages, which is a
    security feature (we don't like trading security for features here, and
    it's not good enough for inclusion if it needs to be interpreted). 2)
    possibly with the exception of a completely non-optimizing JIT, or rather
    specialized JITs, they can be large enough that they'd warrant a shared lib
    (they can be larger than the rest of the current runtime combined), and
    most of us seem to like statically linked builds. Either one of those
    issues would be enough to make the option unattractive for use in Go.

    Also, what do you mean by Java-esque memory problems?
    I'm alluding to the JVM being known for having a comparatively very large
    memory overhead (a hello world program running in JVM can potentially cost
    dozens of megabytes in the resident set). Since the CLR allows for more
    (straightforward) runtime dynamism than something like C++, it'd be
    insufficient to only give the runtime access to those template
    specializations which are known at compile time to be needed, so within
    those requirements, either all possible specializations would need to be
    generated at compile time, or as they already do, a JIT system would be
    needed. Precompiling all possible specializations (which from what I've
    seen of .NET, could easily be combinatorial) could produce very large
    binaries.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJul 7, '13 at 3:13a
activeAug 27, '13 at 4:00p
posts24
users13
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase