FAQ
Hi all.

I'm trying to implement a Linq-alike for Go, mainly for practice but also
because I find Enumerables really easy to work with. Unfortunately, I have
hit several walls, all due to missing features in the language.


    1. *Generics.* Yeah, I know Google doesn't like them. But how else are
    you gonna define a function that takes a parameter of type T along with a
    function that takes a T and returns a T? Answer: You can't. It must take an
    interface{} and a function that takes an interface{} and returns an
    interface{}. And then you can't call this function and pass in an int and a
    function taking an int and returning an int. No, you have to write a
    specifically non-type-safe function and pass *that* in, even if you had
    a perfectly good int->int function kicking around. Madness!

    2. *Overloading.* I decided to start by writing Ana, Cata and Bind, a la
    MinLINQ. Unfortunately, due to the lack of generics, I need to write an
    Ana() that deals with interface{}s, along with specialised versions for
    ints, strings and floats. But... you can't have functions with the same
    name and different parameters, so that's out too.

    3. *Methods. *So, I figured I'd make each overload of Ana be a method on
    the relevant type, but the compiler spits out "cannot define new methods on
    non-local type int". So I can't do that either.


Don't get me wrong: It's great to see the number of modern native-compiled
languages exceed "1", but seriously guys, how's a fellow supposed to get
anything done without generics?

I want a function like this:

func Ana(seed T, condition func(T) bool, next func(T) T) FEnumerable<T> {
    ... code ...
}

Is that really so unreasonable? Are you seriously telling me that writing
out loops and such at the call site is better than having a reusable *
*cough** "class library"? I don't want to be declaring lists and slices all
over the place every time I want to query something. I want to simply say
"From(something).Where(filter).Select(transformation)". You can do that in
C++, C#, D, VB.NET and pretty much any other modern language. If you're
going to have types, you must also have generics. Period. Otherwise we're
just back in the dark ages casting everything back and forth, or writing
the same code over and over again.

Again, let me say that I'm not knocking Go specifically. I'm sick of being
locked into C++ whether I like it or not (yeah, I know there's D, but it's
riddled with bugs). But what use are "first-class functions" when you have
neither generics nor polymorphism? The whole point of first-class functions
is to plug specific *strongly-typed* sorting or filtering functionality
into an otherwise generic *untyped* process. In other words, the function
you're calling doesn't need to know or care what kind of objects its
dealing with, because you've provided a function object that can do the
type-specific bit of work. But here I can't, because a func(int)int won't
be accepted by a function expecting a func(interface{})interface{}.

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

  • James Bardin at May 17, 2013 at 8:36 pm
    No one is likely to debate this with you: http://golang.org/doc/faq#generics

    There may be generics is the future, but in the meantime most of us are
    happy with no generics vs poor generics.


    On Friday, May 17, 2013 3:23:13 PM UTC-4, Sod Almighty wrote:

    Hi all.

    I'm trying to implement a Linq-alike for Go, mainly for practice but also
    because I find Enumerables really easy to work with. Unfortunately, I have
    hit several walls, all due to missing features in the language.


    1. *Generics.* Yeah, I know Google doesn't like them. But how else are
    you gonna define a function that takes a parameter of type T along with a
    function that takes a T and returns a T? Answer: You can't. It must take an
    interface{} and a function that takes an interface{} and returns an
    interface{}. And then you can't call this function and pass in an int and a
    function taking an int and returning an int. No, you have to write a
    specifically non-type-safe function and pass *that* in, even if you
    had a perfectly good int->int function kicking around. Madness!

    2. *Overloading.* I decided to start by writing Ana, Cata and Bind, a
    la MinLINQ. Unfortunately, due to the lack of generics, I need to write an
    Ana() that deals with interface{}s, along with specialised versions for
    ints, strings and floats. But... you can't have functions with the same
    name and different parameters, so that's out too.

    3. *Methods. *So, I figured I'd make each overload of Ana be a method
    on the relevant type, but the compiler spits out "cannot define new methods
    on non-local type int". So I can't do that either.


    Don't get me wrong: It's great to see the number of modern native-compiled
    languages exceed "1", but seriously guys, how's a fellow supposed to get
    anything done without generics?

    I want a function like this:

    func Ana(seed T, condition func(T) bool, next func(T) T) FEnumerable<T> {
    ... code ...
    }

    Is that really so unreasonable? Are you seriously telling me that writing
    out loops and such at the call site is better than having a reusable *
    *cough** "class library"? I don't want to be declaring lists and slices
    all over the place every time I want to query something. I want to simply
    say "From(something).Where(filter).Select(transformation)". You can do that
    in C++, C#, D, VB.NET and pretty much any other modern language. If
    you're going to have types, you must also have generics. Period. Otherwise
    we're just back in the dark ages casting everything back and forth, or
    writing the same code over and over again.

    Again, let me say that I'm not knocking Go specifically. I'm sick of being
    locked into C++ whether I like it or not (yeah, I know there's D, but it's
    riddled with bugs). But what use are "first-class functions" when you have
    neither generics nor polymorphism? The whole point of first-class functions
    is to plug specific *strongly-typed* sorting or filtering functionality
    into an otherwise generic *untyped* process. In other words, the function
    you're calling doesn't need to know or care what kind of objects its
    dealing with, because you've provided a function object that can do the
    type-specific bit of work. But here I can't, because a func(int)int won't
    be accepted by a function expecting a func(interface{})interface{}.
    --
    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.
  • Sod Almighty at May 17, 2013 at 8:47 pm

    On Friday, May 17, 2013 9:36:10 PM UTC+1, James Bardin wrote:
    No one is likely to debate this with you:
    http://golang.org/doc/faq#generics

    There may be generics is the future, but in the meantime most of us are
    happy with no generics vs poor generics.
    Then either you're happy writing loops and type casts over and over again,
    instead of using nice reusable queries like LINQ; or you know a way to
    achieve same in Go as it stands.

    I'm all ears.

    --
    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.
  • Ian Lance Taylor at May 17, 2013 at 8:41 pm

    On Fri, May 17, 2013 at 12:23 PM, wrote:
    Generics. Yeah, I know Google doesn't like them. But how else are you gonna
    define a function that takes a parameter of type T along with a function
    that takes a T and returns a T? Answer: You can't. It must take an
    interface{} and a function that takes an interface{} and returns an
    interface{}. And then you can't call this function and pass in an int and a
    function taking an int and returning an int. No, you have to write a
    specifically non-type-safe function and pass that in, even if you had a
    perfectly good int->int function kicking around. Madness!
    I'm not going to pretend that Go is good at this, because it's not.
    But you actually can do this: http://play.golang.org/p/emiuPJwfCS .

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Aaron France at May 17, 2013 at 8:43 pm
    Troll detected
    On May 17, 2013 10:42 PM, "Ian Lance Taylor" wrote:
    On Fri, May 17, 2013 at 12:23 PM, wrote:

    Generics. Yeah, I know Google doesn't like them. But how else are you gonna
    define a function that takes a parameter of type T along with a function
    that takes a T and returns a T? Answer: You can't. It must take an
    interface{} and a function that takes an interface{} and returns an
    interface{}. And then you can't call this function and pass in an int and a
    function taking an int and returning an int. No, you have to write a
    specifically non-type-safe function and pass that in, even if you had a
    perfectly good int->int function kicking around. Madness!
    I'm not going to pretend that Go is good at this, because it's not.
    But you actually can do this: http://play.golang.org/p/emiuPJwfCS .

    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+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.
  • Sod Almighty at May 17, 2013 at 8:55 pm

    On Friday, May 17, 2013 9:43:03 PM UTC+1, Aaron France wrote:
    Troll detected
    Troll yourself. Didn't you read what I wrote? As I said, I'm in favour of
    new native languages and would like to use Go, but I feel my objections are
    valid. If you disagree, why not explain why you think generics aren't
    necessary, rather than just sitting there and hurling insults for no reason.

    Some people seem to define a troll as anyone who comes on a forum and
    complains about something. I consider that a stupid definition. Go is a
    language currently under development. Surely it's constructive to point out
    where I think the language is lacking, and give examples; rather than just
    give up on it without a word? If nobody ever complained about the
    shortcomings of anything, nothing would ever get done.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • James Bardin at May 17, 2013 at 9:07 pm

    On Friday, May 17, 2013 4:55:25 PM UTC-4, Sod Almighty wrote:
    On Friday, May 17, 2013 9:43:03 PM UTC+1, Aaron France wrote:

    Troll detected
    Troll yourself. Didn't you read what I wrote? As I said, I'm in favour of
    new native languages and would like to use Go, but I feel my objections are
    valid. If you disagree, why not explain why you think generics aren't
    necessary, rather than just sitting there and hurling insults for no reason.

    Oh geez, I was hoping a polite pointer to the FAQ (which covers overloading
    too BTW) would be enough to prevent this usual progression.

    For the record, though you may not intend too, you are coming off as very
    antagonistic. It's not going to lead to a useful discussion. Lot's of
    useful things are done with go without using generics. Maybe there's
    something we can help with.

    Another method for "generifying" code is to wrap things in interfaces. See
    the code in Sort for an example: http://golang.org/pkg/sort/

    --
    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.
  • Sod Almighty at May 17, 2013 at 9:18 pm

    On Friday, May 17, 2013 10:07:18 PM UTC+1, James Bardin wrote:
    Oh geez, I was hoping a polite pointer to the FAQ (which covers
    overloading too BTW) would be enough to prevent this usual progression.

    I've read the faq. Yes, all of it. And the other documentation too. As I
    said, I'm trying to *use* it. I've not just come here to get up everyone's
    noses.

    For the record, though you may not intend too, you are coming off as very
    antagonistic.
    People often tell me that. But, as I have no idea why, there's not a lot I
    can do about it. I look at my original post, and I see a polite criticism
    and a request for change. I insulted nobody, used no foul language, didn't
    say the language sucked, and gave every impression that I liked it in
    general and would appreciate some added functionality. All I wanted was a
    sensible adult discussion.

    It doesn't seem to matter how hard I try to be nice and polite, people
    always jump down my throat and accuse me of being angry or antagonistic. I
    really don't know why I bother.

    I can rewrite my original post again, this time *intending* to annoy
    people, if you think it'll help.

    It's not going to lead to a useful discussion.
    Yeah, I noticed that. "It's how it is, shut up and go away". Same as usual,
    then.

    Lot's of useful things are done with go without using generics. Maybe
    there's something we can help with.
    I doubt it. What normally happens at about this point is half a dozen other
    people hurl abuse at me and tell me to leave. And then I do, and throw the
    language in the trash on my way out.

    Another method for "generifying" code is to wrap things in interfaces. See
    the code in Sort for an example: http://golang.org/pkg/sort/
    See my other post.

    --
    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.
  • Ian Lance Taylor at May 17, 2013 at 9:51 pm

    On Fri, May 17, 2013 at 2:18 PM, Sod Almighty wrote:
    On Friday, May 17, 2013 10:07:18 PM UTC+1, James Bardin wrote:

    For the record, though you may not intend too, you are coming off as very
    antagonistic.

    People often tell me that. But, as I have no idea why, there's not a lot I
    can do about it. I look at my original post, and I see a polite criticism
    and a request for change. I insulted nobody, used no foul language, didn't
    say the language sucked, and gave every impression that I liked it in
    general and would appreciate some added functionality. All I wanted was a
    sensible adult discussion.

    It doesn't seem to matter how hard I try to be nice and polite, people
    always jump down my throat and accuse me of being angry or antagonistic. I
    really don't know why I bother.
    Do you really not know? If this has occurred to you multiple times,
    and it's not intentional, then perhaps you should investigate your
    style of communication. Much as you said yourself farther down the
    thread, if many people tell you something, then perhaps it is true.
    Even if it's hard for you to see it yourself.

    In this case, since you said it so nicely, I'll give you a couple of tips.

    In describing what you have to do in Go to work around the lack of
    generics, you said "Madness!" Exclamation points are seen as
    aggressive. Accusing people and/or projects of insanity is seen as
    aggressive.

    You said "seriously guys, how's a fellow supposed to get anything done
    without generics?" Here you are posting in a forum for people who use
    Go, and saying, not just that one can't use Go without generic, but
    that the lack of generics means that the language is not serious. You
    may very well believe that; it may even be true; but when you come
    into a forum and tell people that they can not do what they are doing,
    it is seen as aggressive.

    You said "Is that really so unreasonable? Are you seriously telling me
    that...." Same sort of thing here. Rather than phrasing the issues
    in a neutral or helpful way, you are phrasing them in a way that
    implies that the people who use Go are unreasonable and unserious.
    This is seen as aggressive.

    I hope this helps.

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Sod Almighty at May 17, 2013 at 10:22 pm

    On Friday, May 17, 2013 10:51:50 PM UTC+1, Ian Lance Taylor wrote:

    Do you really not know? If this has occurred to you multiple times,
    and it's not intentional, then perhaps you should investigate your
    style of communication. Much as you said yourself farther down the
    thread, if many people tell you something, then perhaps it is true.
    Even if it's hard for you to see it yourself.
    I have tried to comprehend why I seem to speak a different language to
    everyone else on the planet; and have got precisely *nowhere*. I honestly
    cannot see anything wrong with my original post. Granted, some of my *other*posts have been a little snappish, but generally in response to unhelpful
    posts. Occasionally, when someone is helpful, you will notice that I thank
    them.

    In this case, since you said it so nicely, I'll give you a couple of tips.

    In describing what you have to do in Go to work around the lack of
    generics, you said "Madness!" Exclamation points are seen as
    aggressive. Accusing people and/or projects of insanity is seen as
    aggressive.
    Uh...but having to drop type-safety and pass in a type-agnostic closure *is*madness. I didn't say the language or the developers were insane, just that
    the hoops I'd have to jump through to achieve anything resembling a
    type-independent reusable function were ridiculous. And I stand by that
    assertion.

    You said "seriously guys, how's a fellow supposed to get anything done
    without generics?" Here you are posting in a forum for people who use
    Go, and saying, not just that one can't use Go without generic, but
    that the lack of generics means that the language is not serious. You
    may very well believe that; it may even be true; but when you come
    into a forum and tell people that they can not do what they are doing,
    it is seen as aggressive.
    I honestly can't see anything wrong with that sentence. It's a simple
    question, albeit an incredulous one. If a language didn't support non-const
    variables; or offered only C++ style references (that is, initialised at
    construction and immutable) and no pointers; or had no branches beyond
    "goto" (e.g. assembly language) - I consider that I would be quite
    justified in exclaiming incredulously, "how in seven circles of hell can I
    be expected to code something decent with *these* tools!??"

    You said "Is that really so unreasonable? Are you seriously telling me
    that...." Same sort of thing here. Rather than phrasing the issues
    in a neutral or helpful way, you are phrasing them in a way that
    implies that the people who use Go are unreasonable and unserious.
    This is seen as aggressive.
    Well, I guess I could've phrased that bit differently. But I disagree with
    your interpretation of my meaning. I wasn't saying anything about the
    people who use Go; I was flabbergasted that such a simple thing wasn't
    possible. I never implied it was your fault. If it's anyone's fault, it's
    the developers of the language. I'm assuming you aren't one? If you are,
    well, as an end user of the product, I have every right to inquire if
    you've taken leave of your senses. A language without generics, in this day
    and age, is like a language without threading; or without the ability to
    call the Windows API; or without 64-bit support.

    --
    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.
  • Ian Lance Taylor at May 17, 2013 at 10:38 pm

    On Fri, May 17, 2013 at 3:21 PM, Sod Almighty wrote:
    On Friday, May 17, 2013 10:51:50 PM UTC+1, Ian Lance Taylor wrote:


    Do you really not know? If this has occurred to you multiple times,
    and it's not intentional, then perhaps you should investigate your
    style of communication. Much as you said yourself farther down the
    thread, if many people tell you something, then perhaps it is true.
    Even if it's hard for you to see it yourself.

    I have tried to comprehend why I seem to speak a different language to
    everyone else on the planet; and have got precisely nowhere. I honestly
    cannot see anything wrong with my original post. Granted, some of my other
    posts have been a little snappish, but generally in response to unhelpful
    posts. Occasionally, when someone is helpful, you will notice that I thank
    them.
    I encourage you to reflect on your post and how people respond to it.
    It's not a matter of what you are trying to say. It's a matter of how
    you say it.

    In this case, since you said it so nicely, I'll give you a couple of tips.

    In describing what you have to do in Go to work around the lack of
    generics, you said "Madness!" Exclamation points are seen as
    aggressive. Accusing people and/or projects of insanity is seen as
    aggressive.

    Uh...but having to drop type-safety and pass in a type-agnostic closure is
    madness. I didn't say the language or the developers were insane, just that
    the hoops I'd have to jump through to achieve anything resembling a
    type-independent reusable function were ridiculous. And I stand by that
    assertion.
    I'm trying to say something not about what you are saying, but about
    how you are saying it. You are responding by reasserting what you are
    trying to say. That's not the point. It's not about the content.
    It's about the presentation.

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Sod Almighty at May 17, 2013 at 10:51 pm

    On Friday, May 17, 2013 11:38:12 PM UTC+1, Ian Lance Taylor wrote:

    I encourage you to reflect on your post and how people respond to it.
    It's not a matter of what you are trying to say. It's a matter of how
    you say it.

    I'm trying to say something not about what you are saying, but about
    how you are saying it. You are responding by reasserting what you are
    trying to say. That's not the point. It's not about the content.
    It's about the presentation.
    I get that. However, from my point of view, the content is 99% of the
    message. If I say "people who use Go are idiots", well, that's rude. If I
    say "Seriously? I can't even do *this?*" - well, in my native language,
    incredulity at the limitations of a system does not equal an insult to the
    people using it. I call my native language "English". Apparently it's not
    the same as what everyone else is using, however.

    Telling me that the presentation is important, while informative and
    appreciated, doesn't actually enable me to do anything about it. I look at
    my "presentation", as you call it, and see nothing wrong. (Except when I'm
    replying to unhelpful posts, of course.) While I'm aware that the majority
    of people in this world react badly to how I say things, I honestly can't
    do anything about it. Or, at least, haven't been able to thus far. Given
    that I'm in my thirties, I don't see that changing overmuch.

    --
    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.
  • Volker Dobler at May 17, 2013 at 10:59 pm

    Am Samstag, 18. Mai 2013 00:51:23 UTC+2 schrieb Sod Almighty:
    I get that. However, from my point of view, the content is 99% of the
    message. If I say "people who use Go are idiots", well, that's rude. If I
    say "Seriously? I can't even do *this?*" - well, in my native language,
    incredulity at the limitations of a system does not equal an insult to the
    people using it. I call my native language "English". Apparently it's not
    the same as what everyone else is using, however.

    Telling me that the presentation is important, while informative and
    appreciated, doesn't actually enable me to do anything about it. I look at
    my "presentation", as you call it, and see nothing wrong. (Except when I'm
    replying to unhelpful posts, of course.) While I'm aware that the majority
    of people in this world react badly to how I say things, I honestly can't
    do anything about it. Or, at least, haven't been able to thus far. Given
    that I'm in my thirties, I don't see that changing overmuch.
    You might want to try a Snickers. Or a weekend reflecting
    what and why was said.

    V.

    --
    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.
  • Sod Almighty at May 17, 2013 at 11:07 pm

    On Friday, May 17, 2013 11:59:47 PM UTC+1, Volker Dobler wrote:

    You might want to try a Snickers. Or a weekend reflecting
    what and why was said.
    Now *this* is a troll. Take note, people.

    If I haven't figured it out in thirty years, a weekend of fucking
    reflection isn't going to help, now is it? Don't take the piss. And I fail
    to see how a rebranded Marathon bar would help in any situation.

    --
    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.
  • Sod Almighty at May 17, 2013 at 10:59 pm
    As an aside, can anyone explain to me why compilers are always written in
    the languages they compile? The compiler for Red is to be re-written in Red
    once the language is usable. The compiler for Rust is written in Rust, and
    so on. I don't understand why this is important.

    It would also appear to be a logical impossibility.

    --
    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.
  • Ian Lance Taylor at May 17, 2013 at 11:19 pm

    On Fri, May 17, 2013 at 3:59 PM, Sod Almighty wrote:
    As an aside, can anyone explain to me why compilers are always written in
    the languages they compile? The compiler for Red is to be re-written in Red
    once the language is usable. The compiler for Rust is written in Rust, and
    so on. I don't understand why this is important.
    Interesting you should ask that. One of the major Go compilers is
    written in C. The other is in C++. Neither is in Go.
    It would also appear to be a logical impossibility.
    It's called pulling yourself up by your bootstraps, bootstrapping for
    short. It's straightforward enough.

    It's normally done because 1) language developers tend to be compiler
    writers, and tend to be interested in languages that are good for
    writing compilers; 2) writing a compiler in a language ensures that
    the language is powerful enough to write a reasonable complex program.

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Sod Almighty at May 17, 2013 at 11:38 pm

    On Saturday, May 18, 2013 12:18:59 AM UTC+1, Ian Lance Taylor wrote:

    It's normally done because 1) language developers tend to be compiler
    writers, and tend to be interested in languages that are good for
    writing compilers; 2) writing a compiler in a language ensures that
    the language is powerful enough to write a reasonable complex program.
    I figured the latter reason. And I suppose if you think your language is
    better than the logical alternative (and let's face it, if you didn't, why
    bother making it?) then I guess you'd want to write your compiler in it.
    Saves having to use the other (presumably crappy) 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.
  • Ian Lance Taylor at May 17, 2013 at 11:15 pm

    On Fri, May 17, 2013 at 3:51 PM, Sod Almighty wrote:
    On Friday, May 17, 2013 11:38:12 PM UTC+1, Ian Lance Taylor wrote:


    I encourage you to reflect on your post and how people respond to it.
    It's not a matter of what you are trying to say. It's a matter of how
    you say it.

    I'm trying to say something not about what you are saying, but about
    how you are saying it. You are responding by reasserting what you are
    trying to say. That's not the point. It's not about the content.
    It's about the presentation.

    I get that. However, from my point of view, the content is 99% of the
    message. If I say "people who use Go are idiots", well, that's rude. If I
    say "Seriously? I can't even do this?" - well, in my native language,
    incredulity at the limitations of a system does not equal an insult to the
    people using it. I call my native language "English". Apparently it's not
    the same as what everyone else is using, however.
    You don't intend an insult. But you are implying that the system is
    not merely deficient but obviously and fragrantly deficient. You are
    implying that no ordinary person would want to use it. It follows
    that you are implying that the people who do use it are not ordinary.
    It's a pretty short step from there to think that you are calling the
    people who do use it stupid. The step may not be warranted, but many
    people will take it. And at that point, it's an insult.

    Telling me that the presentation is important, while informative and
    appreciated, doesn't actually enable me to do anything about it. I look at
    my "presentation", as you call it, and see nothing wrong. (Except when I'm
    replying to unhelpful posts, of course.) While I'm aware that the majority
    of people in this world react badly to how I say things, I honestly can't do
    anything about it. Or, at least, haven't been able to thus far. Given that
    I'm in my thirties, I don't see that changing overmuch.
    If you really want to learn and change your communication patterns,
    you can do so. If you don't want to, then you must simply accept the
    fallout. There are many things about ourselves we can not change.
    This is not one of them. You can't change how you feel. But you can
    change how you communicate, especially over a medium like e-mail that
    permits time for reflection.

    One of the simpler techniques for changing is to write a reply but
    don't send it. Then wait ten minutes and throw that reply away. Then
    write another reply, but this time think hard about what the recipient
    will read.

    Remove any exclamation points. Remove any sentence that seems to call
    for an exclamation point.

    Remember that on the Internet people come from many different
    backgrounds and cultures. Sometimes it helps to think of your e-mail
    as being written to a timid child. You want to explain something to
    him. Maybe you want to explain why he shouldn't go out into the
    street. But you want to do it without scaring him. If you yell he
    will start to cry, and moreover he may be afraid to ever leave the
    house again, which is not what you want. What words would you use?
    Now pretend that the people reading your e-mail are timid children.
    You want to convince them without scaring them.

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Sod Almighty at May 17, 2013 at 11:32 pm

    On Saturday, May 18, 2013 12:15:49 AM UTC+1, Ian Lance Taylor wrote:
    On Fri, May 17, 2013 at 3:51 PM, Sod Almighty wrote:

    You don't intend an insult. But you are implying that the system is
    not merely deficient but obviously and fragrantly deficient.

    I think perhaps you mean "flagrantly deficient". I didn't say anything
    about how it smells.

    You are
    implying that no ordinary person would want to use it. It follows
    that you are implying that the people who do use it are not ordinary.
    It's a pretty short step from there to think that you are calling the
    people who do use it stupid. The step may not be warranted, but many
    people will take it. And at that point, it's an insult.
    Well, if you're gonna read several layers of indirection into my words,
    sure. Thing is, I mean what I say and, conversely, say what I mean. I don't
    imply that people are stupid - if I think they're stupid, I say so. And I
    honestly have no idea how to say exactly what I said in my original post
    but "presented" in a different way that happens to prevent people
    performing indirection on it and ending up insulted.

    if (*(*(*(*(what I said))))->GetImplication() == insult) {
    throw NotMyProblem();
    }
    Telling me that the presentation is important, while informative and
    appreciated, doesn't actually enable me to do anything about it. I look at
    my "presentation", as you call it, and see nothing wrong. (Except when I'm
    replying to unhelpful posts, of course.) While I'm aware that the majority
    of people in this world react badly to how I say things, I honestly can't do
    anything about it. Or, at least, haven't been able to thus far. Given that
    I'm in my thirties, I don't see that changing overmuch.
    If you really want to learn and change your communication patterns,
    you can do so.

    How? And what gives you the right to tell me what I am and am not capable
    of, in direct contradiction of what I said? As a leading authority on me, I
    have to take issue with you there. And, ironically, point out that your
    assertion - after a few indirections - implies that I'm a liar, and lazy,
    and don't give enough of a shit about people to bother being nice. See, I
    can do it too. Fun, isn't it?

    If you don't want to, then you must simply accept the
    fallout. There are many things about ourselves we can not change.
    This is not one of them.

    On what authority do you claim to know my abilities, and better than I do?
    You've known me for half an hour. And not particularly well, either.

    I appreciated your previous attempt to discuss the communication issue; but
    your continual implications that I'm a liar, and a lazy one at that, are
    not welcome.

    You can't change how you feel. But you can
    change how you communicate, especially over a medium like e-mail that
    permits time for reflection.
    See above.

    Remove any exclamation points. Remove any sentence that seems to call
    for an exclamation point.
    Incredulity calls for an exclamation mark. I was incredulous. I was
    exclaiming. Therefore an exclamation mark was appropriate.

    Remember that on the Internet people come from many different
    backgrounds and cultures. Sometimes it helps to think of your e-mail
    as being written to a timid child. You want to explain something to
    him. Maybe you want to explain why he shouldn't go out into the
    street. But you want to do it without scaring him. If you yell he
    will start to cry, and moreover he may be afraid to ever leave the
    house again, which is not what you want. What words would you use?
    Now pretend that the people reading your e-mail are timid children.
    You want to convince them without scaring them.
    I'm sorry? You're saying that I have to treat you and everyone else like
    children? Ah! It's all starting to make sense now.

    This has gone far enough. If I'd entered this thread shouting and swearing,
    you'd have grounds for complaint. All I did was exclaim "what!?? No
    generics!!??" and suddenly you're telling me how to behave? Enough, I say.
    I'm not an arsehole or a troll, but I do occasionally use exclamation marks
    to denote incredulity, and I tend to be opinionated. If that's not
    acceptable, then tough. This particular topic is finished.

    --
    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.
  • Ian Lance Taylor at May 18, 2013 at 12:07 am

    On Fri, May 17, 2013 at 4:32 PM, Sod Almighty wrote:
    On Saturday, May 18, 2013 12:15:49 AM UTC+1, Ian Lance Taylor wrote:

    On Fri, May 17, 2013 at 3:51 PM, Sod Almighty wrote:

    You don't intend an insult. But you are implying that the system is
    not merely deficient but obviously and fragrantly deficient.

    I think perhaps you mean "flagrantly deficient". I didn't say anything about
    how it smells.
    Yes. Thanks.
    You are
    implying that no ordinary person would want to use it. It follows
    that you are implying that the people who do use it are not ordinary.
    It's a pretty short step from there to think that you are calling the
    people who do use it stupid. The step may not be warranted, but many
    people will take it. And at that point, it's an insult.

    Well, if you're gonna read several layers of indirection into my words,
    sure.
    I tried, and I think I succeeded, in only putting one small step into
    what you were saying.
    Thing is, I mean what I say and, conversely, say what I mean. I don't
    imply that people are stupid - if I think they're stupid, I say so. And I
    honestly have no idea how to say exactly what I said in my original post but
    "presented" in a different way that happens to prevent people performing
    indirection on it and ending up insulted.
    I'll tell you if you really want to know.

    Writing is a two way communication mechanism. There is the meaning
    you intend, and there is the meaning that people receive. The goal
    for most people is that people receive the meaning that they intend.
    That requires writing in a way that considers not only what you want
    to say, but also how people are going to read it.

    If you really want to learn and change your communication patterns,
    you can do so.

    How? And what gives you the right to tell me what I am and am not capable
    of, in direct contradiction of what I said? As a leading authority on me, I
    have to take issue with you there. And, ironically, point out that your
    assertion - after a few indirections - implies that I'm a liar, and lazy,
    and don't give enough of a shit about people to bother being nice. See, I
    can do it too. Fun, isn't it?
    I don't think you are lying or lazy, but, you're right, I don't
    believe you are describing the only truth, either. I think you just
    don't have enough of a reason to change. I have no "right" to say
    this, any more than you have a "right" to criticize a language that
    you don't know well and with no apparent knowledge of the extensive
    discussions that have occurred on this very mailing list. Also, you
    are of course correct that I'm being insulting. I'm just doing it
    politely. The difference between what you wrote and what I wrote is
    that you had to think for a bit before you realized the insult,
    whereas a number of people spotted that you were being insulting
    (which you were, even if you did not mean to be) in your original
    post.

    This particular topic is finished.
    OK.

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Sod Almighty at May 18, 2013 at 12:13 am

    On Saturday, May 18, 2013 1:07:04 AM UTC+1, Ian Lance Taylor wrote:

    Also, you
    are of course correct that I'm being insulting. I'm just doing it
    politely. The difference between what you wrote and what I wrote is
    that you had to think for a bit before you realized the insult,
    whereas a number of people spotted that you were being insulting
    (which you were, even if you did not mean to be) in your original
    post.
    I see. So deliberately insulting me is fine, but using exclamation marks
    and expressing surprise that anyone can use a language without generics is
    unacceptable?

    Fuck you.

    There. I didn't use an exclamation mark, and I insulted you on purpose, so
    that's perfectly okay. I trust my post can't be inferred as an insult
    through indirection either? Good.
    (I'm afraid it won't take you long to spot, but to be fair it only took me
    a very small amount of time to spot your insult either, so it'll have to
    do.)

    --
    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.
  • Ian Lance Taylor at May 18, 2013 at 12:23 am

    On Fri, May 17, 2013 at 5:13 PM, Sod Almighty wrote:
    On Saturday, May 18, 2013 1:07:04 AM UTC+1, Ian Lance Taylor wrote:


    Also, you
    are of course correct that I'm being insulting. I'm just doing it
    politely. The difference between what you wrote and what I wrote is
    that you had to think for a bit before you realized the insult,
    whereas a number of people spotted that you were being insulting
    (which you were, even if you did not mean to be) in your original
    post.

    I see. So deliberately insulting me is fine, but using exclamation marks and
    expressing surprise that anyone can use a language without generics is
    unacceptable?
    No. Neither is fine. At least not if the goal is to actually
    communicate ideas.

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Sod Almighty at May 18, 2013 at 12:30 am

    On Saturday, 18 May 2013 01:23:50 UTC+1, Ian Lance Taylor wrote:
    On Fri, May 17, 2013 at 5:13 PM, Sod Almighty wrote:

    I see. So deliberately insulting me is fine, but using exclamation marks and
    expressing surprise that anyone can use a language without generics is
    unacceptable?
    No. Neither is fine. At least not if the goal is to actually
    communicate ideas.
    We'll just have to disagree on that point, I guess.

    --
    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 May 18, 2013 at 1:05 am

    On Fri, May 17, 2013 at 4:32 PM, Sod Almighty wrote:
    On Saturday, May 18, 2013 12:15:49 AM UTC+1, Ian Lance Taylor wrote:

    On Fri, May 17, 2013 at 3:51 PM, Sod Almighty <sod.al...@gmail.com>
    wrote:

    You don't intend an insult. But you are implying that the system is
    not merely deficient but obviously and fragrantly deficient.

    I think perhaps you mean "flagrantly deficient". I didn't say anything
    about how it smells.

    You are
    implying that no ordinary person would want to use it. It follows
    that you are implying that the people who do use it are not ordinary.
    It's a pretty short step from there to think that you are calling the
    people who do use it stupid. The step may not be warranted, but many
    people will take it. And at that point, it's an insult.
    Well, if you're gonna read several layers of indirection into my words,
    sure. Thing is, I mean what I say and, conversely, say what I mean. I don't
    imply that people are stupid - if I think they're stupid, I say so. And I
    honestly have no idea how to say exactly what I said in my original post
    but "presented" in a different way that happens to prevent people
    performing indirection on it and ending up insulted.
    Hmm. I would like to try my hand at a rewrite. Here goes:

    Hi all.

    I'm trying to implement a
    Linq<http://msdn.microsoft.com/en-us/library/vstudio/bb397926.aspx>-alike
    for Go. In the process of doing so, I've run into a few paradigms that I
    haven't been able to translate clearnly into Go.

        1. *Generics.* I am used to having generics at my disposal, and I
        haven't been able to create an API that is able to be as simultaneously
        concise and type-safe as I would like.

        2. *Overloading.* One way I'd typically be able to side-step the
        generics issue is with overloading.

        3. *Methods on predefined types.* If I could define methods on the
        predefined types, I would be able to make them implement interfaces, which
        might help to create a suitable API.

    I'm excited to learn a new compiled systems language, but I haven't been
    using Go for very long and I would like some tips about what an idiomatic
    API for a LINQ-alike would be.

    As an example, I want a function which is conceptually like this:

    func Ana(seed T, condition func(T) bool, next func(T) T) FEnumerable<T> {
        ... code ...
    }

    I Ideally I would be able to chain statements like
    "From(something).Where(filter).Select(transformation)". I've tried a few
    different approaches:

    (1) Return an interface
    - ... problems you ran into ...
    (2) ... other attempted solution ...

    Here is the latest version of my code: http://example.com/foo/linq

    If anyone has any tips about how to approach this or pointers to APIs that
    have done it in an idiomatic way, it would be much appreciated!

    if (*(*(*(*(what I said))))->GetImplication() == insult) {
    throw NotMyProblem();
    }
    Telling me that the presentation is important, while informative and
    appreciated, doesn't actually enable me to do anything about it. I look at
    my "presentation", as you call it, and see nothing wrong. (Except when I'm
    replying to unhelpful posts, of course.) While I'm aware that the majority
    of people in this world react badly to how I say things, I honestly can't do
    anything about it. Or, at least, haven't been able to thus far. Given that
    I'm in my thirties, I don't see that changing overmuch.
    If you really want to learn and change your communication patterns,
    you can do so.

    How? And what gives you the right to tell me what I am and am not capable
    of, in direct contradiction of what I said? As a leading authority on me, I
    have to take issue with you there. And, ironically, point out that your
    assertion - after a few indirections - implies that I'm a liar, and lazy,
    and don't give enough of a shit about people to bother being nice. See, I
    can do it too. Fun, isn't it?

    If you don't want to, then you must simply accept the
    fallout. There are many things about ourselves we can not change.
    This is not one of them.

    On what authority do you claim to know my abilities, and better than I do?
    You've known me for half an hour. And not particularly well, either.

    I appreciated your previous attempt to discuss the communication issue;
    but your continual implications that I'm a liar, and a lazy one at that,
    are not welcome.

    You can't change how you feel. But you can
    change how you communicate, especially over a medium like e-mail that
    permits time for reflection.
    See above.

    Remove any exclamation points. Remove any sentence that seems to call
    for an exclamation point.
    Incredulity calls for an exclamation mark. I was incredulous. I was
    exclaiming. Therefore an exclamation mark was appropriate.

    Remember that on the Internet people come from many different
    backgrounds and cultures. Sometimes it helps to think of your e-mail
    as being written to a timid child. You want to explain something to
    him. Maybe you want to explain why he shouldn't go out into the
    street. But you want to do it without scaring him. If you yell he
    will start to cry, and moreover he may be afraid to ever leave the
    house again, which is not what you want. What words would you use?
    Now pretend that the people reading your e-mail are timid children.
    You want to convince them without scaring them.
    I'm sorry? You're saying that I have to treat you and everyone else like
    children? Ah! It's all starting to make sense now.

    This has gone far enough. If I'd entered this thread shouting and
    swearing, you'd have grounds for complaint. All I did was exclaim "what!??
    No generics!!??" and suddenly you're telling me how to behave? Enough, I
    say. I'm not an arsehole or a troll, but I do occasionally use exclamation
    marks to denote incredulity, and I tend to be opinionated. If that's not
    acceptable, then tough. This particular topic is finished.

    --
    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.
    As a bit of an aside, there is a package somewhere (a bit of searching
    didn't turn up the name, though I'm sure someone around will remember) that
    allows you to write SQL queries using chained functions in the way you
    describe by using interfaces. I feel like it had "pretty" or "simple" in
    the name, if that jogs anyone's memory.

    --
    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.
  • Sod Almighty at May 18, 2013 at 1:43 am

    On Saturday, 18 May 2013 02:04:56 UTC+1, Kyle Lemons wrote:
    On Fri, May 17, 2013 at 4:32 PM, Sod Almighty <sod.al...@gmail.com<javascript:>
    wrote:
    Well, if you're gonna read several layers of indirection into my words,
    sure. Thing is, I mean what I say and, conversely, say what I mean. I don't
    imply that people are stupid - if I think they're stupid, I say so. And I
    honestly have no idea how to say exactly what I said in my original post
    but "presented" in a different way that happens to prevent people
    performing indirection on it and ending up insulted.
    Hmm. I would like to try my hand at a rewrite.
    You know, that might be very helpful. Seriously. I'll discuss it with my
    wife tomorrow, see if I can pinpoint why one was acceptable and the other
    (apparently) not. It might seem obvious to you, but you'll just have to
    take my word for it that it isn't. Obviously there *is* a difference - I
    can see that - but it's a case of narrowing down "what not to do", you know?

    Thanks.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan Kortschak at May 18, 2013 at 1:53 am
    Are you thinking of gosexy?
    On 18/05/2013, at 10:35 AM, "Kyle Lemons" wrote:

    As a bit of an aside, there is a package somewhere (a bit of searching didn't turn up the name, though I'm sure someone around will remember) that allows you to write SQL queries using chained functions in the way you describe by using interfaces. I feel like it had "pretty" or "simple" in the name, if that jogs anyone's memory
    --
    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.
  • Sanjay at May 18, 2013 at 4:26 am
    You asked about what was wrong with using the C# implementation.

    They have a simplifying factor, which is that they can do runtime expansion
    easily. Since they are running in a VM, they can do compact bytecode
    generation by having bytecode that is generics-aware, and then at runtime
    JIT compile specializations for each type, this gives it C++'s speed
    without C++'s bloat for compiled artifacts. Note that this can pollute CPU
    caches, so they do some clever things like sharing implementations of
    generic functions that are similarly sized, etc. This is an excellent
    implementation; but requires a VM to be easily implementable. Of course, it
    is possible for Go to do similar things with runtime code generation, but
    requiring runtime code generation has security implications, and would be
    quite unfortunate.

    Then there's reified generics from Java. i.e. you write list<T>, and the
    compiler compiles it as list<interface{}>, and writes the casting for you.
    This is somewhat inefficient and inelegant. In particular, when you write
    something like List<Integer>, this is a pointer to an array of pointers to
    integers, rather than what you'd expect (a pointer to a list of integers).

    That leaves C++'s generate all the template specializations approach. This
    is really crappy for C++ because it involves the compiler generating all
    specializations for object files. Then the linker has to try and throw away
    duplicates, it has to try and merge redundant implementations and so on.
    The final runtime code generally is very fast, but the object files tend to
    be bloated, and this will definitely slow the compilation process.

    I think the most promising approach for Go is something like this. The
    compiler generates object files with a compact generics-aware AST
    representation. The linker still has to dedupe, but it should be easier
    because unlike C++, code hasn't been generated yet. It can merely look at
    what calls to max(T, T) exist in the whole program after eliminating dead
    code, and then emit specialized code for just those max functions. It would
    need similar optimizations to C#, such as emitting one type for
    LinkedList<uint32> and LinkedList<int32> and so on. This model could
    support the aggressive inlining that makes C++ templates so fast. Major
    downside is that a lot of work gets shifted to link time; anyone who's
    timed Go builds in detail can tell you that they are already usually the
    bottleneck, and this will make them even more so. The corollary is that
    compiles of packages will become even faster, as it basically just entails
    type-checking. Also, optimization will get easier, because the linker has a
    whole-program view, so it can inline cross-package, and so-forth.

    Anyways, thats just mechanics of how to make the implementation work, but
    the other half of the problem is to how to fit it into the language and
    APIs nicely, and orthogonally. You have to spec out how they interact with
    interfaces, and what the syntax looks like, and how to make them simple to
    understand and how to make them predictable for developers. This is
    probably a non-trivial problem; I believe that this half is much much
    harder.

    Cheers,
    Sanjay

    --
    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.
  • Andrew at May 18, 2013 at 5:37 am
    Perhaps some concise method of declaring an augmentation of methods onto a
    type, as previously suggested, would mitigate the need for generics
    somewhat, but rather than try to make an argument that things should be
    this way I'd like to reframe it and ask what practical considerations have
    made it unattractive in past discussions, and the impact of the proposals
    on the language that may have induced caution. I don't entirely understand
    the above discussion, and frankly, I've deliberately avoided reading
    certain stretches of it.

    In my opinion, it seems that with Go, magic doesn't get imported into your
    source file, ever: any magic you do can be traced from the name to the
    import, and the import to the source. In my mind, the lack of generics
    means that the developer must explicitly implement any code bridging the
    generally-implemented algorithm with their own custom data types. This is,
    to me, equivalent to declaring "I know what I'm doing and want to apply X
    method to Y type. It'll work. I promise (in a compiled, typesafe way)". It
    also happens to be a very verbose way of doing it, because you have to
    declare a type that wraps it and supports the methods. Is there a middle
    ground somewhere, or is it that automatically wrapping types just another
    way of expressing something functionally equivalent to C++ style method
    copying or boxing things at runtime, Java-style?

    What I'd like to know is what are the pitfalls of compile-time struct
    mixins? i.e:

    import (
       "io"
       "code.google.com/p/sneakygophers" `mixin:"ExampleNumber(uint64)"`
    )

    where the sneakygophers (made-up name) package is imported with methods on
    the struct type sneakygophers.ExampleNumber aliasing to uint64 *only within
    the mixin package*? Admittedly, I haven't thought through the full
    implications of this, as I am still busy learning the language itself. Does
    this complicate things too much? Does it make sense to have an explicit
    file-local or package-local ability to augment types with methods for the
    purpose of satisfying interfaces? If you have to be explicit, you make it
    extremely obvious when you're abusing templates, because you have to tell
    the source to instantiate the implementation each time you add one
    (...which is no worse than what we have now?).

    Sorry if this is rambling a little bit; I deleted my original message and
    am struggling to express an idea which partially escaped me the first time
    around.

    On Friday, May 17, 2013 6:04:56 PM UTC-7, Kyle Lemons wrote:

    On Fri, May 17, 2013 at 4:32 PM, Sod Almighty <sod.al...@gmail.com<javascript:>
    wrote:
    On Saturday, May 18, 2013 12:15:49 AM UTC+1, Ian Lance Taylor wrote:

    On Fri, May 17, 2013 at 3:51 PM, Sod Almighty <sod.al...@gmail.com>
    wrote:

    You don't intend an insult. But you are implying that the system is
    not merely deficient but obviously and fragrantly deficient.

    I think perhaps you mean "flagrantly deficient". I didn't say anything
    about how it smells.

    You are
    implying that no ordinary person would want to use it. It follows
    that you are implying that the people who do use it are not ordinary.
    It's a pretty short step from there to think that you are calling the
    people who do use it stupid. The step may not be warranted, but many
    people will take it. And at that point, it's an insult.
    Well, if you're gonna read several layers of indirection into my words,
    sure. Thing is, I mean what I say and, conversely, say what I mean. I don't
    imply that people are stupid - if I think they're stupid, I say so. And I
    honestly have no idea how to say exactly what I said in my original post
    but "presented" in a different way that happens to prevent people
    performing indirection on it and ending up insulted.
    Hmm. I would like to try my hand at a rewrite. Here goes:

    Hi all.

    I'm trying to implement a Linq<http://msdn.microsoft.com/en-us/library/vstudio/bb397926.aspx>-alike
    for Go. In the process of doing so, I've run into a few paradigms that I
    haven't been able to translate clearnly into Go.

    1. *Generics.* I am used to having generics at my disposal, and I
    haven't been able to create an API that is able to be as simultaneously
    concise and type-safe as I would like.

    2. *Overloading.* One way I'd typically be able to side-step the
    generics issue is with overloading.

    3. *Methods on predefined types.* If I could define methods on the
    predefined types, I would be able to make them implement interfaces, which
    might help to create a suitable API.

    I'm excited to learn a new compiled systems language, but I haven't been
    using Go for very long and I would like some tips about what an idiomatic
    API for a LINQ-alike would be.

    As an example, I want a function which is conceptually like this:

    func Ana(seed T, condition func(T) bool, next func(T) T) FEnumerable<T> {
    ... code ...
    }

    I Ideally I would be able to chain statements like
    "From(something).Where(filter).Select(transformation)". I've tried a
    few different approaches:

    (1) Return an interface
    - ... problems you ran into ...
    (2) ... other attempted solution ...

    Here is the latest version of my code: http://example.com/foo/linq

    If anyone has any tips about how to approach this or pointers to APIs that
    have done it in an idiomatic way, it would be much appreciated!

    if (*(*(*(*(what I said))))->GetImplication() == insult) {
    throw NotMyProblem();
    }
    Telling me that the presentation is important, while informative and
    appreciated, doesn't actually enable me to do anything about it. I look at
    my "presentation", as you call it, and see nothing wrong. (Except when I'm
    replying to unhelpful posts, of course.) While I'm aware that the majority
    of people in this world react badly to how I say things, I honestly can't do
    anything about it. Or, at least, haven't been able to thus far. Given that
    I'm in my thirties, I don't see that changing overmuch.
    If you really want to learn and change your communication patterns,
    you can do so.

    How? And what gives you the right to tell me what I am and am not capable
    of, in direct contradiction of what I said? As a leading authority on me, I
    have to take issue with you there. And, ironically, point out that your
    assertion - after a few indirections - implies that I'm a liar, and lazy,
    and don't give enough of a shit about people to bother being nice. See, I
    can do it too. Fun, isn't it?

    If you don't want to, then you must simply accept the
    fallout. There are many things about ourselves we can not change.
    This is not one of them.

    On what authority do you claim to know my abilities, and better than I
    do? You've known me for half an hour. And not particularly well, either.

    I appreciated your previous attempt to discuss the communication issue;
    but your continual implications that I'm a liar, and a lazy one at that,
    are not welcome.

    You can't change how you feel. But you can
    change how you communicate, especially over a medium like e-mail that
    permits time for reflection.
    See above.

    Remove any exclamation points. Remove any sentence that seems to call
    for an exclamation point.
    Incredulity calls for an exclamation mark. I was incredulous. I was
    exclaiming. Therefore an exclamation mark was appropriate.

    Remember that on the Internet people come from many different
    backgrounds and cultures. Sometimes it helps to think of your e-mail
    as being written to a timid child. You want to explain something to
    him. Maybe you want to explain why he shouldn't go out into the
    street. But you want to do it without scaring him. If you yell he
    will start to cry, and moreover he may be afraid to ever leave the
    house again, which is not what you want. What words would you use?
    Now pretend that the people reading your e-mail are timid children.
    You want to convince them without scaring them.
    I'm sorry? You're saying that I have to treat you and everyone else like
    children? Ah! It's all starting to make sense now.

    This has gone far enough. If I'd entered this thread shouting and
    swearing, you'd have grounds for complaint. All I did was exclaim "what!??
    No generics!!??" and suddenly you're telling me how to behave? Enough, I
    say. I'm not an arsehole or a troll, but I do occasionally use exclamation
    marks to denote incredulity, and I tend to be opinionated. If that's not
    acceptable, then tough. This particular topic is finished.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.
    As a bit of an aside, there is a package somewhere (a bit of searching
    didn't turn up the name, though I'm sure someone around will remember) that
    allows you to write SQL queries using chained functions in the way you
    describe by using interfaces. I feel like it had "pretty" or "simple" in
    the name, if that jogs anyone's memory.
    --
    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.
  • Ian Lance Taylor at May 18, 2013 at 5:44 am

    On Fri, May 17, 2013 at 8:30 PM, wrote:
    What I'd like to know is what are the pitfalls of compile-time struct
    mixins? i.e:

    import (
    "io"
    "code.google.com/p/sneakygophers" `mixin:"ExampleNumber(uint64)"`
    )

    where the sneakygophers (made-up name) package is imported with methods on
    the struct type sneakygophers.ExampleNumber aliasing to uint64 *only within
    the mixin package*? Admittedly, I haven't thought through the full
    implications of this, as I am still busy learning the language itself. Does
    this complicate things too much? Does it make sense to have an explicit
    file-local or package-local ability to augment types with methods for the
    purpose of satisfying interfaces? If you have to be explicit, you make it
    extremely obvious when you're abusing templates, because you have to tell
    the source to instantiate the implementation each time you add one
    (...which is no worse than what we have now?).
    The main thing that troubles me about this approach is that it becomes
    awkward to have containers of containers. You need to somehow
    specialize the container package for the base type, and then
    specialize it again for the container type. It's a tempting idea but
    I don't really think it's the way to go.

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Michael Jones at May 18, 2013 at 7:33 am
    I propose a rethinking of one of the "getting generics right" tenets -- the
    focus on making the compile time not just blazingly fast, but as fast as
    possible, "double blazing" if that was a phrase.

    The Go developers have structured the language to allow amazingly fast
    compile times. They have implemented it in a way that realizes these
    amazingly fast compiles. For example, the whole language and libraries bild
    in a minute on my little notebook computer. Amazing!

    That said, there is a point where frugal can become miserly, and I suggest
    that generics should cause reevaluation of means and end on this very
    point. Here is the basic a general C++ like template system (user view) but
    with a magical and fast aspect made possible by Go's structure. The magic
    is in the importing. We need a flag in there (invisible to the developer)
    than says "Templates are used in this package or in its dependencies, and
    these are what they are."

    This allows the the compiler to know a priori which generic specifications
    need to be instantiated and what type combinations they need to be
    instantiated for.

    This allows the concrete calling sequences to be known when the callers are
    being compiled.

    This allows the compiler to emit the instantiations just once, at its
    discretion in terms of when.


    In spirit, it means "compiling twice" and that's what makes it simple to
    implement and explain. But the hierarchical nature of the package manifests
    and their pre-order visitation by the compiler means that you actually only
    have to do it once since you're building the template and instantiation
    tree efficiently as part of decoding package data (so you never have to
    discover a fact twice.)

    How fast would this be? Same speed as now when no generics are in use.
    Similar speed in parse/analyze package headers as now. Extra time to
    instantiate the minimal set of templated functions, but this is 1:1 with
    the time to compile the same functions is elaborated manually by the
    developer, so a tie.

    There would be a memory cost in keeping the "for those packages that rely
    on a template, here are the pointers to definitions of when they need to
    have instantiated" data structures during that package tree traversal. But
    at the end of that traversal the necessary functions could be immediately
    instantiated if desired and then the whole data structure deleted.
    Everything else in the compile can then proceed as now (with lexical
    substitution of the expanded template names happening, of course.)

    Here is the frugal/miserly as fast as possible argument: if this process
    adds more than a few percent to the compile time, I would be surprised. But
    let's be generous and say it costs an extra 5% of the entire time for
    compiles where even one generic is used. I'm saying that 1 minute and 3
    seconds would not be too much of an increase over the existing
    blazingly-fast one minute. This is a worthy place to spend a tiny bit of
    our time savings account, yet we'll never even consider it if we keep the
    initial condition of "as fast as possible." Let's weaken that to just
    "amazingly, awesomely, astoundingly fast" and be willing to use a percent
    or two of the peak speed to give developers peak speed in their work.

    Michael
    (In Amsterdam)
    On Sat, May 18, 2013 at 7:44 AM, Ian Lance Taylor wrote:
    On Fri, May 17, 2013 at 8:30 PM, wrote:

    What I'd like to know is what are the pitfalls of compile-time struct
    mixins? i.e:

    import (
    "io"
    "code.google.com/p/sneakygophers" `mixin:"ExampleNumber(uint64)"`
    )

    where the sneakygophers (made-up name) package is imported with methods on
    the struct type sneakygophers.ExampleNumber aliasing to uint64 *only within
    the mixin package*? Admittedly, I haven't thought through the full
    implications of this, as I am still busy learning the language itself. Does
    this complicate things too much? Does it make sense to have an explicit
    file-local or package-local ability to augment types with methods for the
    purpose of satisfying interfaces? If you have to be explicit, you make it
    extremely obvious when you're abusing templates, because you have to tell
    the source to instantiate the implementation each time you add one
    (...which is no worse than what we have now?).
    The main thing that troubles me about this approach is that it becomes
    awkward to have containers of containers. You need to somehow
    specialize the container package for the base type, and then
    specialize it again for the container type. It's a tempting idea but
    I don't really think it's the way to go.

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


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --
    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.
  • Gerard at May 18, 2013 at 9:23 am
    Michael, I like your motivating posts.

    I am not an expert in the subject of generics, however I don't see any real
    benefit of them. Why? Because they are being misused. A nice example is a
    first grade C++ chess engine, Stockfish<https://github.com/mcostalba/Stockfish>.
    If you look at the header files, it's template all over. And that's because
    the types, declared in types.h are enums, so in fact they are all ints. And
    C++ can't handle the enums. In Go, when you want the types (derived ints),
    just define an interface with a getter and that's it. So, yes there is some
    boilerplate, but the code is still compact and, most of all, clear and easy
    to understand.

    Btw, have fun in Amsterdam. And be aware of the dog poo on the sidewalks.

    Op zaterdag 18 mei 2013 09:33:02 UTC+2 schreef Michael Jones het volgende:
    I propose a rethinking of one of the "getting generics right" tenets --
    the focus on making the compile time not just blazingly fast, but as fast
    as possible, "double blazing" if that was a phrase.

    The Go developers have structured the language to allow amazingly fast
    compile times. They have implemented it in a way that realizes these
    amazingly fast compiles. For example, the whole language and libraries bild
    in a minute on my little notebook computer. Amazing!

    That said, there is a point where frugal can become miserly, and I suggest
    that generics should cause reevaluation of means and end on this very
    point. Here is the basic a general C++ like template system (user view) but
    with a magical and fast aspect made possible by Go's structure. The magic
    is in the importing. We need a flag in there (invisible to the developer)
    than says "Templates are used in this package or in its dependencies, and
    these are what they are."

    This allows the the compiler to know a priori which generic specifications
    need to be instantiated and what type combinations they need to be
    instantiated for.

    This allows the concrete calling sequences to be known when the callers
    are being compiled.

    This allows the compiler to emit the instantiations just once, at its
    discretion in terms of when.


    In spirit, it means "compiling twice" and that's what makes it simple to
    implement and explain. But the hierarchical nature of the package manifests
    and their pre-order visitation by the compiler means that you actually only
    have to do it once since you're building the template and instantiation
    tree efficiently as part of decoding package data (so you never have to
    discover a fact twice.)

    How fast would this be? Same speed as now when no generics are in use.
    Similar speed in parse/analyze package headers as now. Extra time to
    instantiate the minimal set of templated functions, but this is 1:1 with
    the time to compile the same functions is elaborated manually by the
    developer, so a tie.

    There would be a memory cost in keeping the "for those packages that rely
    on a template, here are the pointers to definitions of when they need to
    have instantiated" data structures during that package tree traversal. But
    at the end of that traversal the necessary functions could be immediately
    instantiated if desired and then the whole data structure deleted.
    Everything else in the compile can then proceed as now (with lexical
    substitution of the expanded template names happening, of course.)

    Here is the frugal/miserly as fast as possible argument: if this process
    adds more than a few percent to the compile time, I would be surprised. But
    let's be generous and say it costs an extra 5% of the entire time for
    compiles where even one generic is used. I'm saying that 1 minute and 3
    seconds would not be too much of an increase over the existing
    blazingly-fast one minute. This is a worthy place to spend a tiny bit of
    our time savings account, yet we'll never even consider it if we keep the
    initial condition of "as fast as possible." Let's weaken that to just
    "amazingly, awesomely, astoundingly fast" and be willing to use a percent
    or two of the peak speed to give developers peak speed in their work.

    Michael
    (In Amsterdam)

    On Sat, May 18, 2013 at 7:44 AM, Ian Lance Taylor <ia...@golang.org<javascript:>
    wrote:
    On Fri, May 17, 2013 at 8:30 PM, <and...@atoulou.se <javascript:>>
    wrote:
    What I'd like to know is what are the pitfalls of compile-time struct
    mixins? i.e:

    import (
    "io"
    "code.google.com/p/sneakygophers" `mixin:"ExampleNumber(uint64)"`
    )

    where the sneakygophers (made-up name) package is imported with methods on
    the struct type sneakygophers.ExampleNumber aliasing to uint64 *only within
    the mixin package*? Admittedly, I haven't thought through the full
    implications of this, as I am still busy learning the language itself. Does
    this complicate things too much? Does it make sense to have an explicit
    file-local or package-local ability to augment types with methods for the
    purpose of satisfying interfaces? If you have to be explicit, you make it
    extremely obvious when you're abusing templates, because you have to tell
    the source to instantiate the implementation each time you add one
    (...which is no worse than what we have now?).
    The main thing that troubles me about this approach is that it becomes
    awkward to have containers of containers. You need to somehow
    specialize the container package for the base type, and then
    specialize it again for the container type. It's a tempting idea but
    I don't really think it's the way to go.

    Ian

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com<javascript:>
    +1 650-335-5765
    --
    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.
  • Aram Hăvărneanu at May 18, 2013 at 9:34 am

    you need to [...] cast the slice of Person to a slice of
    PersonSortingByAge
    No cast in Go. A potential *conversion* between those two types
    means copying 3 words, and it's compile time type safe.
    no generics means no reusable code
    Ridiculous claim. You can have reusable code in assembly. You just
    can't have the type of reusable code you are accustomed to. Interfaces
    allow reusable *code* in Go.

    You can't have generic containers in Go, but that's another thing.
    It seems LINQ simply cannot be done in Go.
    Great. One of the philosophical principles of Go is to avoid magic
    things that have unintuitive or variable space or memory behavior.

    --
    Aram Hăvărneanu

    --
    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 May 18, 2013 at 9:37 am
    You can't have the type of generic containers you have in other languages in all cases, but you can have some, and then many more if you allow assertions.
    On 18/05/2013, at 7:04 PM, "Aram Hăvărneanu" wrote:

    You can't have generic containers in Go, but that's another thing.
    --
    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.
  • Andrew Akira Toulouse at May 18, 2013 at 9:41 am
    That's funny! I was just writing this email and before I saw your email,
    "very deep rabbit hole" was exactly my phrasing as well!

    After ruminating a bit, I'm thinking the idea that adding generics is a
    disproportionately and extraordinarily large design challenge given its
    presumed benefits, and perhaps the issue is best avoided until it can be
    demonstrably shown that the language has a poor solution to a situation
    that generics would compellingly solve. So far, I haven't seen it.

    I wonder if generics are even the fundamental problem here. The original
    question's itch that was attempted to be scratched was basically
    implementing a DSL for LINQ-like behavior. Is there some way we can
    facilitate the kind of type-safe method composition necessary for this
    without specifically designing and adding generics into the syntax? I think
    that a concise method of creating a filtered dataset or filtered pipeline
    of data would be compelling, and that perhaps the way to think of this is
    how can we add constructs that facilitate simply and concisely expressed,
    composable, and typesafe filters/transformers.
    On Saturday, May 18, 2013, Gerard wrote:

    Michael, I like your motivating posts.

    I am not an expert in the subject of generics, however I don't see any
    real benefit of them. Why? Because they are being misused. A nice example
    is a first grade C++ chess engine, Stockfish<https://github.com/mcostalba/Stockfish>.
    If you look at the header files, it's template all over. And that's because
    the types, declared in types.h are enums, so in fact they are all ints. And
    C++ can't handle the enums. In Go, when you want the types (derived ints),
    just define an interface with a getter and that's it. So, yes there is some
    boilerplate, but the code is still compact and, most of all, clear and easy
    to understand.

    Btw, have fun in Amsterdam. And be aware of the dog poo on the sidewalks.

    Op zaterdag 18 mei 2013 09:33:02 UTC+2 schreef Michael Jones het volgende:
    I propose a rethinking of one of the "getting generics right" tenets --
    the focus on making the compile time not just blazingly fast, but as fast
    as possible, "double blazing" if that was a phrase.

    The Go developers have structured the language to allow amazingly fast
    compile times. They have implemented it in a way that realizes these
    amazingly fast compiles. For example, the whole language and libraries bild
    in a minute on my little notebook computer. Amazing!

    That said, there is a point where frugal can become miserly, and I
    suggest that generics should cause reevaluation of means and end on this
    very point. Here is the basic a general C++ like template system (user
    view) but with a magical and fast aspect made possible by Go's structure.
    The magic is in the importing. We need a flag in there (invisible to the
    developer) than says "Templates are used in this package or in its
    dependencies, and these are what they are."

    This allows the the compiler to know a priori which generic
    specifications need to be instantiated and what type combinations they need
    to be instantiated for.

    This allows the concrete calling sequences to be known when the callers
    are being compiled.

    This allows the compiler to emit the instantiations just once, at its
    discretion in terms of when.


    In spirit, it means "compiling twice" and that's what makes it simple to
    implement and explain. But the hierarchical nature of the package manifests
    and their pre-order visitation by the compiler means that you actually only
    have to do it once since you're building the template and instantiation
    tree efficiently as part of decoding package data (so you never have to
    discover a fact twice.)

    How fast would this be? Same speed as now when no generics are in use.
    Similar speed in parse/analyze package headers as now. Extra time to
    instantiate the minimal set of templated functions, but this is 1:1 with
    the time to compile the same functions is elaborated manually by the
    developer, so a tie.

    There would be a memory cost in keeping the "for those packages that rely
    on a template, here are the pointers to definitions of when they need to
    have instantiated" data structures during that package tree traversal. But
    at the end of that traversal the necessary functions could be immediately
    instantiated if desired and then the whole data structure deleted.
    Everything else in the compile can then proceed as now (with lexical
    substitution of the expanded template names happening, of course.)

    Here is the frugal/miserly as fast as possible argument: if this process
    adds more than a few percent to the compile time, I would be surprised. But
    let's be generous and say it costs an extra 5% of the entire time for
    compiles where even one generic is used. I'm saying that 1 minute and 3
    seconds would not be too much of an increase over the existing
    blazingly-fast one minute. This is a worthy place to spend a tiny bit of
    our time savings account, yet we'll never even consider it if we keep the
    initial condition of "as fast as possible." Let's weaken that to just
    "amazingly, awesomely, astoundingly fast" and be willing to use a percent
    or two of the peak speed to give developers peak speed in their work.

    Michael
    (In Amsterdam)
    On Sat, May 18, 2013 at 7:44 AM, Ian Lance Taylor wrote:
    On Fri, May 17, 2013 at 8:30 PM, wrote:

    What I'd like to know is what are the pitfalls of compile-time struct
    mixins? i.e:

    import (
    "io"
    "code.google.com/p/**sneakygophers<http://code.google.com/p/sneakygophers>"
    `mixin:"ExampleNumber(uint64)"**`
    )

    where the sneakygophers (made-up name) package is imported with
    methods on
    the struct type sneakygophers.ExampleNumber aliasing to uint64 *only within
    the mixin package*? Admittedly, I haven't thought through the full
    implications of this, as I am still busy learning the language itself. Does
    this complicate things too much? Does it make sense to have an explicit
    file-local or package-local ability to augment types with methods for the
    purpose of satisfying interfaces? If you have to be explicit, you make it
    extremely obvious when you're abusing templates, because you have to tell
    the source to instantiate the implementation each time you add one
    (...which is no worse than what we have now?).
    The main thing that troubles me about this approach is that it becomes
    awkward to have containers of containers. You need to somehow
    specialize the container package for the base type, and then
    specialize it again for the container type. It's a tempting idea but
    I don't really think it's the way to go.

    Ian

    --
    You received this message because you are subscribed to the Google
    Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to golang-nuts...@**googlegroups.com.
    For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
    .


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com | +1
    650-335-5765
    --
    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.
  • Bartwiegmans at May 18, 2013 at 5:15 pm
    Hi,

    Its very funny that I was thinking just on the same lines, and would have
    written something very near to what you had written, then stopped, and
    realised that unfortunately, I was wrong. Basically, my proposal would be
    to let the linker do the work, in such a method:

    Lets assume sort() in generics.
    * The package declaration declares a certain method generic, and declares
    what is being 'done' with the object (comparison, container size, etc)
    * The compiler checks if the generic types are consistent
    * The calling package discovers the called method is generic, and generates
    'stubs' (for a > b for floats)
    * The linker inserts the stubs into a copy of the method / function.
    * Profit!

    For such a simple scheme, this would totally work, and indeed not slow
    things down too much (I think). The devil is always in the details, and
    what would happen if for example:

    * Generic functions call generic functions (they need to be recompiled /
    relinked recursively)
    * In the LINQ-y example, the compiler now needs to check that all calls to
    the second closure are correct with the type of the first argument, which
    means it needs to check the whole algorithm and can't compile the imported
    package before the importing package; in other words we have created a
    cycle).
    * What if (for example) the closure escapes, how do we assure type safety
    now?
    * Somebody assigns a generic value to a structure (now all the uses of a
    structure may need to be recompiled). (This is not madness, by the way, C++
    has template classes).
    * Somebody comes on this forum and argues how we should overload comparison
    because otherwise structure types will not be compared correctly.

    This is, in other words, a rabbits hole that goes down very, very deep. And
    at some point, you should stop, pause, and say 'hey, maybe this is simpler
    with interfaces'. Presumably the authors did this. And indeed it is,
    because:

    * Its generic (you can make an interface of every type, even integers.)
    * It is quickly compiled (no cycles, and compiling an interface is no more
    than compiling a vtable)
    * It is an obvious tradeoff that is clear to your users.

    In short, interfaces are the way to Go ;-). Pun intended, terribly so.

    Kind regards,
    Bart Wiegmans

    Op zaterdag 18 mei 2013 09:33:02 UTC+2 schreef Michael Jones het volgende:
    I propose a rethinking of one of the "getting generics right" tenets --
    the focus on making the compile time not just blazingly fast, but as fast
    as possible, "double blazing" if that was a phrase.

    The Go developers have structured the language to allow amazingly fast
    compile times. They have implemented it in a way that realizes these
    amazingly fast compiles. For example, the whole language and libraries bild
    in a minute on my little notebook computer. Amazing!

    That said, there is a point where frugal can become miserly, and I suggest
    that generics should cause reevaluation of means and end on this very
    point. Here is the basic a general C++ like template system (user view) but
    with a magical and fast aspect made possible by Go's structure. The magic
    is in the importing. We need a flag in there (invisible to the developer)
    than says "Templates are used in this package or in its dependencies, and
    these are what they are."

    This allows the the compiler to know a priori which generic specifications
    need to be instantiated and what type combinations they need to be
    instantiated for.

    This allows the concrete calling sequences to be known when the callers
    are being compiled.

    This allows the compiler to emit the instantiations just once, at its
    discretion in terms of when.


    In spirit, it means "compiling twice" and that's what makes it simple to
    implement and explain. But the hierarchical nature of the package manifests
    and their pre-order visitation by the compiler means that you actually only
    have to do it once since you're building the template and instantiation
    tree efficiently as part of decoding package data (so you never have to
    discover a fact twice.)

    How fast would this be? Same speed as now when no generics are in use.
    Similar speed in parse/analyze package headers as now. Extra time to
    instantiate the minimal set of templated functions, but this is 1:1 with
    the time to compile the same functions is elaborated manually by the
    developer, so a tie.

    There would be a memory cost in keeping the "for those packages that rely
    on a template, here are the pointers to definitions of when they need to
    have instantiated" data structures during that package tree traversal. But
    at the end of that traversal the necessary functions could be immediately
    instantiated if desired and then the whole data structure deleted.
    Everything else in the compile can then proceed as now (with lexical
    substitution of the expanded template names happening, of course.)

    Here is the frugal/miserly as fast as possible argument: if this process
    adds more than a few percent to the compile time, I would be surprised. But
    let's be generous and say it costs an extra 5% of the entire time for
    compiles where even one generic is used. I'm saying that 1 minute and 3
    seconds would not be too much of an increase over the existing
    blazingly-fast one minute. This is a worthy place to spend a tiny bit of
    our time savings account, yet we'll never even consider it if we keep the
    initial condition of "as fast as possible." Let's weaken that to just
    "amazingly, awesomely, astoundingly fast" and be willing to use a percent
    or two of the peak speed to give developers peak speed in their work.

    Michael
    (In Amsterdam)

    On Sat, May 18, 2013 at 7:44 AM, Ian Lance Taylor <ia...@golang.org<javascript:>
    wrote:
    On Fri, May 17, 2013 at 8:30 PM, <and...@atoulou.se <javascript:>>
    wrote:
    What I'd like to know is what are the pitfalls of compile-time struct
    mixins? i.e:

    import (
    "io"
    "code.google.com/p/sneakygophers" `mixin:"ExampleNumber(uint64)"`
    )

    where the sneakygophers (made-up name) package is imported with methods on
    the struct type sneakygophers.ExampleNumber aliasing to uint64 *only within
    the mixin package*? Admittedly, I haven't thought through the full
    implications of this, as I am still busy learning the language itself. Does
    this complicate things too much? Does it make sense to have an explicit
    file-local or package-local ability to augment types with methods for the
    purpose of satisfying interfaces? If you have to be explicit, you make it
    extremely obvious when you're abusing templates, because you have to tell
    the source to instantiate the implementation each time you add one
    (...which is no worse than what we have now?).
    The main thing that troubles me about this approach is that it becomes
    awkward to have containers of containers. You need to somehow
    specialize the container package for the base type, and then
    specialize it again for the container type. It's a tempting idea but
    I don't really think it's the way to go.

    Ian

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com<javascript:>
    +1 650-335-5765
    --
    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 Arbash Meinel at May 23, 2013 at 8:54 am

    On 2013-05-18 7:30, andrew@atoulou.se wrote:

    In my opinion, it seems that with Go, magic doesn't get imported
    into your source file, ever: any magic you do can be traced from
    the name to the import, and the import to the source. In my mind,
    the lack of generics means that the developer must explicitly
    implement any code bridging the generally-implemented algorithm
    with their own custom data types. This is, to me, equivalent to
    declaring "I know what I'm doing and want to apply X method to Y
    type. It'll work. I promise (in a compiled, typesafe way)". It also
    happens to be a very verbose way of doing it, because you have to
    declare a type that wraps it and supports the methods. Is there a
    middle ground somewhere, or is it that automatically wrapping types
    just another way of expressing something functionally equivalent to
    C++ style method copying or boxing things at runtime, Java-style?

    What I'd like to know is what are the pitfalls of compile-time
    struct mixins? i.e:

    import ( "io" "code.google.com/p/sneakygophers"
    `mixin:"ExampleNumber(uint64)"` )
    Note that there is gotgo:
    https://github.com/droundy/gotgo

    Which predates 'go build' to back when there were Makefiles. But it
    used a variant on this specific syntax to transform".got" files into
    ".go" files. .got files were syntactically go, but had a bit of
    template definitions.

    This works for macro-based templating, and defining container types.
    It doesn't work quite as well when you want to nest templates (I want
    a type T1<T2<T3>>>).

    The code is probably a bit old, and I'm guessing it doesn't integrate
    into the current build system. But it was *an* answer that people have
    investigated.

    John
    =:->



    --
    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.
  • Paulo Pinto at May 23, 2013 at 2:55 pm
    Sadly it resembles the tools some C++ compilers (Borland C++) were
    offering
    back in the day templates were still not available.

    Time travel back to 1993, when I used such tools.

    However, an interesting research topic would be to fork go compiler
    and integrate gotgo
    into the compiler itself and see how that could work out.

    --
    Paulo
    On May 23, 10:54 am, John Arbash Meinel wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On 2013-05-18 7:30, and...@atoulou.se wrote:








    In my opinion, it seems that with Go, magic doesn't get imported
    into your source file, ever: any magic you do can be traced from
    the name to the import, and the import to the source. In my mind,
    the lack of generics means that the developer must explicitly
    implement any code bridging the generally-implemented algorithm
    with their own custom data types. This is, to me, equivalent to
    declaring "I know what I'm doing and want to apply X method to Y
    type. It'll work. I promise (in a compiled, typesafe way)". It also
    happens to be a very verbose way of doing it, because you have to
    declare a type that wraps it and supports the methods. Is there a
    middle ground somewhere, or is it that automatically wrapping types
    just another way of expressing something functionally equivalent to
    C++ style method copying or boxing things at runtime, Java-style?
    What I'd like to know is what are the pitfalls of compile-time
    struct mixins? i.e:
    import ( "io" "code.google.com/p/sneakygophers"
    `mixin:"ExampleNumber(uint64)"` )
    Note that there is gotgo:https://github.com/droundy/gotgo

    Which predates 'go build' to back when there were Makefiles. But it
    used a variant on this specific syntax to transform".got" files into
    ".go" files. .got files were syntactically go, but had a bit of
    template definitions.

    This works for macro-based templating, and defining container types.
    It doesn't work quite as well when you want to nest templates (I want
    a type T1<T2<T3>>>).

    The code is probably a bit old, and I'm guessing it doesn't integrate
    into the current build system. But it was *an* answer that people have
    investigated.

    John
    =:->
    --
    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.
  • Sod Almighty at May 17, 2013 at 11:37 pm

    On Saturday, May 18, 2013 12:15:49 AM UTC+1, Ian Lance Taylor wrote:

    Remember that on the Internet people come from many different
    backgrounds and cultures.
    Oh, and I notice *my* background and culture counts for fuck-all,
    incidentally. If your (or anyone else's) background and culture means that
    I should take extra care not to "scare" people or use exclamation marks,
    why doesn't my "background and culture" (which, despite being white and
    English, I actually do have) count for a damn thing? Why aren't you telling
    everyone else to take my background and culture into account, and not read
    shit into my words that I didn't put there?

    Because I was brought up to say what I mean, and wasn't taught at an early
    age to couch everything I say in stupid diplomatic language. I was given a
    telling-off at work once for saying "but surely it ought to be this way"
    because "surely" apparently meant "it certainly is, there can be no
    question, and you're an idiot for thinking otherwise". Well it doesn't.
    Look it up. If your "culture" and upbringing and way of speaking is valid,
    then so is mine. When I stoop to name calling and abuse, feel free to call
    me down for it.

    --
    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.
  • Ian Lance Taylor at May 18, 2013 at 12:13 am

    On Fri, May 17, 2013 at 4:37 PM, Sod Almighty wrote:
    On Saturday, May 18, 2013 12:15:49 AM UTC+1, Ian Lance Taylor wrote:


    Remember that on the Internet people come from many different
    backgrounds and cultures.

    Oh, and I notice my background and culture counts for fuck-all,
    incidentally. If your (or anyone else's) background and culture means that I
    should take extra care not to "scare" people or use exclamation marks, why
    doesn't my "background and culture" (which, despite being white and English,
    I actually do have) count for a damn thing? Why aren't you telling everyone
    else to take my background and culture into account, and not read shit into
    my words that I didn't put there?
    Because you are the newcomer to an existing forum, and as such you are
    expected to adopt the prevailing norms of communication. You can work
    to change those norms--but not until you have participated for a
    while.
    Because I was brought up to say what I mean, and wasn't taught at an early
    age to couch everything I say in stupid diplomatic language. I was given a
    telling-off at work once for saying "but surely it ought to be this way"
    because "surely" apparently meant "it certainly is, there can be no
    question, and you're an idiot for thinking otherwise". Well it doesn't. Look
    it up. If your "culture" and upbringing and way of speaking is valid, then
    so is mine. When I stoop to name calling and abuse, feel free to call me
    down for it.
    "Stupid diplomatic language" is an interesting choice of phrase. The
    language of diplomacy was evolved, over time, specifically so that
    nations with radical disagreements, and touchy points of pride, would
    be able to communicate about important issues without getting into
    fights. It's awkward and tedious, but it's not stupid. It's actually
    pretty important.

    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Mathieu Lonjaret at May 18, 2013 at 12:20 pm
    I must say I am really amazed by your patience and selflessness here
    Ian. Hat tip to you.
    On 18 May 2013 02:13, Ian Lance Taylor wrote:
    On Fri, May 17, 2013 at 4:37 PM, Sod Almighty wrote:
    On Saturday, May 18, 2013 12:15:49 AM UTC+1, Ian Lance Taylor wrote:


    Remember that on the Internet people come from many different
    backgrounds and cultures.

    Oh, and I notice my background and culture counts for fuck-all,
    incidentally. If your (or anyone else's) background and culture means that I
    should take extra care not to "scare" people or use exclamation marks, why
    doesn't my "background and culture" (which, despite being white and English,
    I actually do have) count for a damn thing? Why aren't you telling everyone
    else to take my background and culture into account, and not read shit into
    my words that I didn't put there?
    Because you are the newcomer to an existing forum, and as such you are
    expected to adopt the prevailing norms of communication. You can work
    to change those norms--but not until you have participated for a
    while.
    Because I was brought up to say what I mean, and wasn't taught at an early
    age to couch everything I say in stupid diplomatic language. I was given a
    telling-off at work once for saying "but surely it ought to be this way"
    because "surely" apparently meant "it certainly is, there can be no
    question, and you're an idiot for thinking otherwise". Well it doesn't. Look
    it up. If your "culture" and upbringing and way of speaking is valid, then
    so is mine. When I stoop to name calling and abuse, feel free to call me
    down for it.
    "Stupid diplomatic language" is an interesting choice of phrase. The
    language of diplomacy was evolved, over time, specifically so that
    nations with radical disagreements, and touchy points of pride, would
    be able to communicate about important issues without getting into
    fights. It's awkward and tedious, but it's not stupid. It's actually
    pretty important.

    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+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.
  • Gustavo Niemeyer at May 17, 2013 at 11:19 pm

    On Fri, May 17, 2013 at 7:51 PM, Sod Almighty wrote:
    I get that. However, from my point of view, the content is 99% of the
    message. (...) While I'm aware that the majority of people in this world
    react badly to how I say things, I honestly can't do anything about it.
    Have you tried Rust? It's a brilliant language.


    gustavo @ http://niemeyer.net

    --
    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.
  • Sod Almighty at May 17, 2013 at 11:40 pm

    On Saturday, May 18, 2013 12:18:47 AM UTC+1, Gustavo Niemeyer wrote:
    On Fri, May 17, 2013 at 7:51 PM, Sod Almighty wrote:
    I get that. However, from my point of view, the content is 99% of the
    message. (...) While I'm aware that the majority of people in this world
    react badly to how I say things, I honestly can't do anything about it.
    Have you tried Rust? It's a brilliant language.
    Er....not yet, it's on my to-do list, since someone already recommended it
    above.

    I'm wondering what on earth it has to do with the bit you just quoted,
    though.

    --
    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.
  • Monnand at May 21, 2013 at 9:21 pm

    On 05/17/2013 06:51 PM, Sod Almighty wrote:
    well, in my native
    language, incredulity at the limitations of a system does not equal an
    insult to the people using it. I call my native language "English".
    Apparently it's not the same as what everyone else is using, however.
    Well. It seems that you are good at using a language in a "mad way" and
    it is really not surprise to me that you are using Go in that way as well.

    I'm not a native speaker but I think your original post is, well, rude.
    You can translate it into any language and no one will say it's a
    "polite" request.

    If you are unable to use a language in a good way, then any language
    sucks and it's your problem.

    Am I rude? I'm a troll.

    To any reader:

    Please ignore my message and keep doing your important work.

    --
    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.
  • Tomwilde at May 17, 2013 at 9:23 pm

    On Friday, May 17, 2013 10:55:25 PM UTC+2, Sod Almighty wrote:

    If nobody ever complained about the shortcomings of anything, nothing
    would ever get done.
    Dude you're like the 3000th person to bring this up. There have been like
    100 lengthy discussions about this topic. Answer has always been the same.
    There's a reason why this is mentioned in the FAQ.

    --
    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.
  • Sod Almighty at May 17, 2013 at 9:31 pm

    On Friday, May 17, 2013 10:23:25 PM UTC+1, tomwilde wrote:
    On Friday, May 17, 2013 10:55:25 PM UTC+2, Sod Almighty wrote:

    If nobody ever complained about the shortcomings of anything, nothing
    would ever get done.
    Dude you're like the 3000th person to bring this up. There have been like
    100 lengthy discussions about this topic. Answer has always been the same.
    There's a reason why this is mentioned in the FAQ.
    In other words, "I'm sick of telling people there's no demand for it"?

    If 3000 people want a thing, perhaps someone should give it to them. What
    you're essentially saying is, three thousand people agree with me. What's
    your point, exactly?

    --
    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.
  • Tomwilde at May 17, 2013 at 9:35 pm
    I'm saying that 3000 people wrote before they read, did before they thought
    and failed before they started.

    They came from other languages, read about Go, realized the "lack" of
    generics, immediately posted to the list. Left in less than an hour.
    On Friday, May 17, 2013 11:31:53 PM UTC+2, Sod Almighty wrote:
    On Friday, May 17, 2013 10:23:25 PM UTC+1, tomwilde wrote:
    On Friday, May 17, 2013 10:55:25 PM UTC+2, Sod Almighty wrote:

    If nobody ever complained about the shortcomings of anything, nothing
    would ever get done.
    Dude you're like the 3000th person to bring this up. There have been like
    100 lengthy discussions about this topic. Answer has always been the same.
    There's a reason why this is mentioned in the FAQ.
    In other words, "I'm sick of telling people there's no demand for it"?

    If 3000 people want a thing, perhaps someone should give it to them. What
    you're essentially saying is, three thousand people agree with me. What's
    your point, exactly?
    --
    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.
  • Sod Almighty at May 17, 2013 at 9:38 pm

    On Friday, May 17, 2013 10:35:52 PM UTC+1, tomwilde wrote:
    I'm saying that 3000 people wrote before they read, did before they
    thought and failed before they started.

    They came from other languages, read about Go, realized the "lack" of
    generics, immediately posted to the list. Left in less than an hour.
    I'm not surprised. They were probably called trolls. They probably figured
    that a language without generics was a poorly designed language. They were
    probably put off by the "no can't do" attitude.

    --
    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.
  • Tomwilde at May 17, 2013 at 9:41 pm
    If you read before you wrote you would have noticed that Aaron France
    quoted Ian Lance Tailor as a troll. Not you.

    Just stick around bro. Read the list - get to know the language, we're a
    fine community.
    On Friday, May 17, 2013 11:38:13 PM UTC+2, Sod Almighty wrote:


    On Friday, May 17, 2013 10:35:52 PM UTC+1, tomwilde wrote:

    I'm saying that 3000 people wrote before they read, did before they
    thought and failed before they started.

    They came from other languages, read about Go, realized the "lack" of
    generics, immediately posted to the list. Left in less than an hour.
    I'm not surprised. They were probably called trolls. They probably figured
    that a language without generics was a poorly designed language. They were
    probably put off by the "no can't do" attitude.
    --
    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.
  • Sod Almighty at May 17, 2013 at 9:53 pm

    On Friday, May 17, 2013 10:41:55 PM UTC+1, tomwilde wrote:
    If you read before you wrote you would have noticed that Aaron France
    quoted Ian Lance Tailor as a troll. Not you.
    Actually I did notice, but figured that nobody could have mistaken the *only
    constructive response* at that time for a troll; and naturally assumed he
    was talking about me. People usually do. I thought Ian's reply was - if not
    practical - at least well-intentioned. Why would Aaron call *him* a troll?

    Just stick around bro. Read the list - get to know the language, we're a
    fine community.
    Well, getting to know the language was my intention. I thought, "I know,
    I'll have a go at implementing MinLINQ, as it doesn't seem to have any kind
    of Select or Where functionality already". Can you suggest how I might
    approach the problem without 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.
  • Tad Glines at May 17, 2013 at 9:55 pm

    On Fri, May 17, 2013 at 2:38 PM, Sod Almighty wrote:

    I'm not surprised. They were probably called trolls. They probably figured
    that a language without generics was a poorly designed language. They were
    probably put off by the "no can't do" attitude.

    I'm picking this as a somewhat arbitrary point of insertion.
    The language developers WANT to add generics to the language.
    However, they don't want to rush it.
    If at all possible they would like to avoid the tradeoffs found in C++ and
    Java:
    1. The C++ templates while powerful slow down the compiler.
    2. The Java/.NET generics while powerful, slowdown the runtime.

    As I see it there is a third way. One that has been taken before.
    Create a wrapper/preprocessor language, ala Groovy, coffescript, etc...
    Then the developer could choose which tradeoff they want to make (compile
    speed, executabel size, and runtime speed) and then choose
    the appropriate wrapper 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.
  • Ziad Hatahet at May 17, 2013 at 9:59 pm

    On Fri, May 17, 2013 at 2:54 PM, Tad Glines wrote:
    As I see it there is a third way. One that has been taken before.
    Create a wrapper/preprocessor language, ala Groovy, coffescript, etc...
    Then the developer could choose which tradeoff they want to make (compile
    speed, executabel size, and runtime speed) and then choose
    the appropriate wrapper language.
    The 3 ways you listed are not the only ones. I noticed that the way that
    C#, D, or Rust implement generics was never brought up in the group.

    --
    Ziad

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

People

Translate

site design / logo © 2022 Grokbase