Re: No generics, no overloading, and no adding methods to existing types. How....useful.

3,527 views
Skip to first unread message

James Bardin

unread,
May 17, 2013, 4:36:10 PM5/17/13
to golan...@googlegroups.com
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{}.

Ian Lance Taylor

unread,
May 17, 2013, 4:41:53 PM5/17/13
to sod.al...@gmail.com, golan...@googlegroups.com
On Fri, May 17, 2013 at 12:23 PM, <sod.al...@gmail.com> 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

Aaron France

unread,
May 17, 2013, 4:43:03 PM5/17/13
to Ian Lance Taylor, golan...@googlegroups.com, sod.al...@gmail.com

Troll detected

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


Sod Almighty

unread,
May 17, 2013, 4:47:44 PM5/17/13
to golan...@googlegroups.com

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.

Sod Almighty

unread,
May 17, 2013, 4:50:09 PM5/17/13
to golan...@googlegroups.com, sod.al...@gmail.com


On Friday, May 17, 2013 9:41:53 PM UTC+1, Ian Lance Taylor wrote:

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 .

Hmm. Interesting. Obviously reflection isn't ideal - slow, for starters - but it's better than nothing.

I'll have a play with the code you've provided and see if I can make sense of it. Cheers!

Sod Almighty

unread,
May 17, 2013, 4:55:25 PM5/17/13
to golan...@googlegroups.com, Ian Lance Taylor, sod.al...@gmail.com

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.

Sean Russell

unread,
May 17, 2013, 4:57:16 PM5/17/13
to golan...@googlegroups.com, sod.al...@gmail.com
Not really.

    http://play.golang.org/p/TgB_pRVBdP

There goes type safety, and, consequently, a core feature.

--- SER

Sod Almighty

unread,
May 17, 2013, 5:01:43 PM5/17/13
to golan...@googlegroups.com, sod.al...@gmail.com
On Friday, May 17, 2013 9:57:16 PM UTC+1, Sean Russell wrote:
Not really.

    http://play.golang.org/p/TgB_pRVBdP

There goes type safety, and, consequently, a core feature.

What type safety? The type safety that forces you to write a different function for every type you want to use it with; while simultaneously forcing you to give each function a different name?

If I write a Sort() function, I want to be able to pass slices, arrays and lists of any type. Similarly, if I write a Sort() function that takes a comparer - e.g. func Sort(values, sorter) - then I want the sorter function to be strongly typed to the type I am sorting.

That's generics. Period. No generics, no reusable type-safe type-independent code. You either have to cast (no type safety) or write extra code (no code reuse).

jimmy frasche

unread,
May 17, 2013, 5:03:54 PM5/17/13
to Sod Almighty, golang-nuts
Look at how the standard library does Sort: http://golang.org/pkg/sort/

James Bardin

unread,
May 17, 2013, 5:07:18 PM5/17/13
to golan...@googlegroups.com, Ian Lance Taylor, sod.al...@gmail.com


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/

Gustavo Niemeyer

unread,
May 17, 2013, 5:08:29 PM5/17/13
to Sod Almighty, golan...@googlegroups.com
On Fri, May 17, 2013 at 6:01 PM, Sod Almighty <sod.al...@gmail.com> wrote:
> That's generics. Period. No generics, no reusable type-safe type-independent
> code. You either have to cast (no type safety) or write extra code (no code
> reuse).

Indeed, but generics do not exist, period. You'll indeed have to write
some boilerplate code every once in a while. Unanimously, though,
everybody would appreciate having a beautiful implementation of
generics in the language, and the reason why that hasn't happened is
that such beautiful design is yet to surface. I'd rather have no
generics, than a rushed implementation as seen elsewhere.


gustavo @ http://niemeyer.net

Sod Almighty

unread,
May 17, 2013, 5:09:29 PM5/17/13
to golan...@googlegroups.com, Sod Almighty
On Friday, May 17, 2013 10:03:54 PM UTC+1, soapboxcicero wrote:
Look at how the standard library does Sort: http://golang.org/pkg/sort/

Yeah. Ugly, ain't it? And besides, none of those functions allow passing in a closure telling it how to sort. The type to be sorted has to define this, so if you want to be able to sort one slice of Person by name, another by age, and another by ID; you need to either write the sort function yourself, three times, or cast the slice of Person to a slice of PersonSortingByAge before actually performing the sort.

Rather than, you know, doing something like:

ppl := Sort(ppl, func(p Person) int { return p.age })

Way I see it, that's a hell of a lot better.

Sod Almighty

unread,
May 17, 2013, 5:18:45 PM5/17/13
to golan...@googlegroups.com, Ian Lance Taylor, sod.al...@gmail.com

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.

tomwilde

unread,
May 17, 2013, 5:23:25 PM5/17/13
to golan...@googlegroups.com, Ian Lance Taylor, sod.al...@gmail.com
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.

Sod Almighty

unread,
May 17, 2013, 5:23:58 PM5/17/13
to golan...@googlegroups.com, Sod Almighty

On Friday, May 17, 2013 10:08:29 PM UTC+1, Gustavo Niemeyer wrote:

Unanimously, though,
everybody would appreciate having a beautiful implementation of
generics in the language,

So explain why people tried to lynch me as soon as I mentioned it.

You think this "beautiful implementation" is going to fall out of the sky? No, it'll happen by people discussing it, and repeatedly demanding it on forums, until it gradually filters through the head of the developers.

Unless people get called trolls right from the get-go, that is.

minux

unread,
May 17, 2013, 5:29:23 PM5/17/13
to Sod Almighty, golan...@googlegroups.com
On Sat, May 18, 2013 at 5:23 AM, Sod Almighty <sod.al...@gmail.com> wrote:
On Friday, May 17, 2013 10:08:29 PM UTC+1, Gustavo Niemeyer wrote:
Unanimously, though,
everybody would appreciate having a beautiful implementation of
generics in the language,

So explain why people tried to lynch me as soon as I mentioned it.

You think this "beautiful implementation" is going to fall out of the sky? No, it'll happen by people discussing it, and repeatedly
but you don't seems to propose an implementation of generic, only complained the lack of it,
and that's why people consistently refer you to the FAQ.
demanding it on forums, until it gradually filters through the head of the developers.

btw, if you do want to propose an implementation of generic, be sure to read

Sod Almighty

unread,
May 17, 2013, 5:31:53 PM5/17/13
to golan...@googlegroups.com, Ian Lance Taylor, sod.al...@gmail.com

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?

Sod Almighty

unread,
May 17, 2013, 5:35:31 PM5/17/13
to golan...@googlegroups.com, Sod Almighty


On Friday, May 17, 2013 10:29:23 PM UTC+1, minux wrote:

but you don't seems to propose an implementation of generic, only complained the lack of it,
and that's why people consistently refer you to the FAQ.

Well, as a starting point, what about the .NET implementation? Seems to work well enough. Only shortcoming seems to be the lack of partial types. That is, the inability to specify a generic type without specifying T.

I really don't see what's so hard about it. .NET does it. D does it. A bunch of other languages do it. Granted, I'm not an expert on language design, but it's not exactly a new idea. Surely it can't be beyond the wit of man?

tomwilde

unread,
May 17, 2013, 5:35:52 PM5/17/13
to golan...@googlegroups.com, Ian Lance Taylor, sod.al...@gmail.com
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.

Sod Almighty

unread,
May 17, 2013, 5:38:13 PM5/17/13
to golan...@googlegroups.com, Ian Lance Taylor, sod.al...@gmail.com


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.

Gustavo Niemeyer

unread,
May 17, 2013, 5:40:20 PM5/17/13
to Sod Almighty, golan...@googlegroups.com
On Fri, May 17, 2013 at 6:23 PM, Sod Almighty <sod.al...@gmail.com> wrote:
> So explain why people tried to lynch me as soon as I mentioned it.

You came in very warmly, and they've corresponded to that. That's all.

I think you're not a troll, but you're too excited to be able to
influence things. Just take a deep breath, experience the language a
bit more, read some previous threads on the topic, and then come back
to help us solve the problem.


gustavo @ http://niemeyer.net

tomwilde

unread,
May 17, 2013, 5:41:55 PM5/17/13
to golan...@googlegroups.com, Ian Lance Taylor, sod.al...@gmail.com
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.

Ian Lance Taylor

unread,
May 17, 2013, 5:43:20 PM5/17/13
to Sean Russell, golan...@googlegroups.com, sod.al...@gmail.com
On Fri, May 17, 2013 at 1:57 PM, Sean Russell <seaner...@gmail.com> wrote:
> Not really.
>
> http://play.golang.org/p/TgB_pRVBdP
>
> There goes type safety, and, consequently, a core feature.

The language still has type safety, of course--that's why your code panics.

What this approach lacks is compile-time type safety. It's a serious
problem. I just want to make sure we give it the right name.

Ian


> On Friday, May 17, 2013 4:41:53 PM UTC-4, Ian Lance Taylor wrote:
>>
>> On Fri, May 17, 2013 at 12:23 PM, <sod.al...@gmail.com> 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
>

Ziad Hatahet

unread,
May 17, 2013, 5:44:22 PM5/17/13
to golang-nuts
On Fri, May 17, 2013 at 12:23 PM, <sod.al...@gmail.com> wrote:
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?


Out of curiosity, have you looked at Rust (http://rust-lang.org)? It is a native-compiled language, and it has generics, immutability, concurrency, and some other really nice features.

--
Ziad

Dan Kortschak

unread,
May 17, 2013, 5:47:47 PM5/17/13
to Sod Almighty, golan...@googlegroups.com, Sod Almighty
Probably you want to see how embedding can be used here. You can do extremely subtle things by wrapping your type in a struct with additional data and a changed Less method.

Ian Lance Taylor

unread,
May 17, 2013, 5:51:50 PM5/17/13
to Sod Almighty, golan...@googlegroups.com
On Fri, May 17, 2013 at 2:18 PM, Sod Almighty <sod.al...@gmail.com> 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

Sod Almighty

unread,
May 17, 2013, 5:53:45 PM5/17/13
to golan...@googlegroups.com, Ian Lance Taylor, sod.al...@gmail.com

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?

Tad Glines

unread,
May 17, 2013, 5:54:57 PM5/17/13
to Sod Almighty, golang-nuts, Ian Lance Taylor
On Fri, May 17, 2013 at 2:38 PM, Sod Almighty <sod.al...@gmail.com> 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.

Sod Almighty

unread,
May 17, 2013, 5:59:16 PM5/17/13
to golan...@googlegroups.com

Oooh, another native language! I googled for native languages recently and never encountered Rust. Thanks for pointing it out. I'll take a look.

The only other natives I know of are D (buggy as hell), C++, AutoIt (a bit lacking) and Red (afaik, not yet in a usable condition). Any more?

Ziad Hatahet

unread,
May 17, 2013, 5:59:20 PM5/17/13
to Tad Glines, Sod Almighty, golang-nuts, Ian Lance Taylor

On Fri, May 17, 2013 at 2:54 PM, Tad Glines <tad.g...@gmail.com> 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

Ian Lance Taylor

unread,
May 17, 2013, 6:04:21 PM5/17/13
to Sod Almighty, golan...@googlegroups.com
On Fri, May 17, 2013 at 2:35 PM, Sod Almighty <sod.al...@gmail.com> wrote:
>
>
> On Friday, May 17, 2013 10:29:23 PM UTC+1, minux wrote:
>>
>>
>> but you don't seems to propose an implementation of generic, only
>> complained the lack of it,
>> and that's why people consistently refer you to the FAQ.
>
>
> Well, as a starting point, what about the .NET implementation? Seems to work
> well enough. Only shortcoming seems to be the lack of partial types. That
> is, the inability to specify a generic type without specifying T.

.NET is a very different sort of system. In .NET generics are
implemented using just-in-time generation, e.g., to handle types with
unusual sizes in containers. That aspect wouldn't work with Go.
Also, the .NET approach requires that types, including builtin types,
implement interfaces like IComparable. Currently in Go builtin types
do not implement methods, so that would have to change, which makes
the approach more complex. Also, I don't really like the way that
IComparable's CompareTo method takes a parameter of type Object. In
Go that would be equivalent to a parameter of type interface{}. That
is not idea in Go, because it requires type conversions which are part
of what we are trying to get away from. .NET's implementation
partially relies on the concepts of covariance and contravariance,
which are meaningless in Go, because there is no inheritance hierarchy
in Go.

All that said, I agree that the .NET implementation of generics is one
of the better ones, and there is a lot we can learn there.


> I really don't see what's so hard about it. .NET does it. D does it. A bunch
> of other languages do it. Granted, I'm not an expert on language design, but
> it's not exactly a new idea. Surely it can't be beyond the wit of man?

The Go language is intentionally minimal and intentionally tries to
provide a relatively small number of concepts. Citing D, a language
with a very different philosophy, doesn't get us very far. That said,
I am not familiar offhand with how D implements generics. D's
heritage suggests it might be similar to C++ templates, which would
not be a good fit for Go. But I don't really know.

Ian

Sod Almighty

unread,
May 17, 2013, 6:04:38 PM5/17/13
to golan...@googlegroups.com
On Friday, May 17, 2013 10:47:47 PM UTC+1, kortschak wrote:
Probably you want to see how embedding can be used here. You can do extremely subtle things by wrapping your type in a struct with additional data and a changed Less method.

Ah, but I'd have to write a different struct for every type. Basically, no generics means no reusable code - plus, fully half of the awesomeness of lambdas goes straight out the window. It seems LINQ simply cannot be done in Go. And that's a shame.

NOTE: The two awesomenesses of function objects are [1] closure (of local variables) and [2] the ability to call generic functions and pass in a tiny bit of type-specific code as a lambda to specify behavour. Without generics, you cannot do this.

Ziad Hatahet

unread,
May 17, 2013, 6:04:41 PM5/17/13
to Sod Almighty, golan...@googlegroups.com
On Fri, May 17, 2013 at 2:59 PM, Sod Almighty <sod.al...@gmail.com> wrote:
Oooh, another native language! I googled for native languages recently and never encountered Rust. Thanks for pointing it out. I'll take a look.

The only other natives I know of are D (buggy as hell), C++, AutoIt (a bit lacking) and Red (afaik, not yet in a usable condition). Any more?


Objective-C and Haskell, to name a couple.

--
Ziad

Dan Kortschak

unread,
May 17, 2013, 6:15:58 PM5/17/13
to Sod Almighty, golan...@googlegroups.com
As an author of a variety of packages that aim at, and hit, generic use, I have to disagree there. There is some set up for that generic use, but this is in my view an honest statement to the client about the cost and a oportunity for type safe flexibility that other forms of generic code don't allow.

As another apporach to your question, similar to Ian's would be to take a pointer to an interface{} and plase the results in that. This is used in a number of places in the standard library. This would depend on reflection, but you could take an interfaced-based approach like Foo(a, b Interface, c SetInterface) where a and b satisfy the behaviours you need to het the inputs and SetInterface satisfies the behaviour of storing that result. Potentially no type assertions are needed under this scheme.

Sod Almighty

unread,
May 17, 2013, 6:21:57 PM5/17/13
to golan...@googlegroups.com, Sod Almighty
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.

Sod Almighty

unread,
May 17, 2013, 6:27:18 PM5/17/13
to golan...@googlegroups.com, Sod Almighty, Ian Lance Taylor
On Friday, May 17, 2013 10:54:57 PM UTC+1, Tad Glines wrote:

The language developers WANT to add generics to the language.
However, they don't want to rush it.

Well bugger me! A sensible rational discussion on the subject! ;)
 
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.

Hmm...I wasn't aware that generics were that slow. I'll have to write a test program in .NET or something and benchmark it somehow. I'm not familiar with the preprocessors you mention; not being a Java developer. Isn't a preprocessor just another version of option 1, though?

Sod Almighty

unread,
May 17, 2013, 6:36:18 PM5/17/13
to golan...@googlegroups.com, Sod Almighty

I'm not an expert, but Objective-C would appear (at a casual glance) to suffer from the same problems as C++. For example, it has header files, which I personally consider the absolute most stupid and awkward feature of C/C++. I just googled and apparently it does have a GC, which I didn't realise. But it's primarily a Mac-targeted language. I'm not sure how feasible it'd be to write Windows software in it. Guess I'll take a look. It looks mighty strange at a casual glance, though. Trying to think of it as a parallel universe version of C++ just isn't working for me ;)

Haskell? Are you serious? It's a purely functional language - which in my opinion means it's totally useless - and, as far as I'm aware, totally dead except amongst mathematicians.

Ian Lance Taylor

unread,
May 17, 2013, 6:38:12 PM5/17/13
to Sod Almighty, golan...@googlegroups.com
On Fri, May 17, 2013 at 3:21 PM, Sod Almighty <sod.al...@gmail.com> 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

Sod Almighty

unread,
May 17, 2013, 6:41:48 PM5/17/13
to golan...@googlegroups.com, Sod Almighty


On Friday, May 17, 2013 11:15:58 PM UTC+1, kortschak wrote:

As another apporach to your question, similar to Ian's would be to take a pointer to an interface{} and plase the results in that. This is used in a number of places in the standard library. This would depend on reflection, but you could take an interfaced-based approach like Foo(a, b Interface, c SetInterface) where a and b satisfy the behaviours you need to het the inputs and SetInterface satisfies the behaviour of storing that result. Potentially no type assertions are needed under this scheme.

Yeah, but you can't do:

results := values.where( ...filter function... ).orderby( ...sorting function... ).select( ...transformation function... )

With your Foo function, it's a laborious job of one-operation-per-line, plus a bunch of typecasts. Yeah, I realise that with enough work and messing about it's possible to write a function Foo(), but that's not what I intended here. My intention was to allow for a simple SQL-like query syntax, in the style of .NET LINQ. Because doing it imperatively is hard work and less readable. Also potentially slower (if it resolves the queries immediately).

Sod Almighty

unread,
May 17, 2013, 6:51:23 PM5/17/13
to golan...@googlegroups.com, Sod Almighty


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.

Volker Dobler

unread,
May 17, 2013, 6:59:47 PM5/17/13
to golan...@googlegroups.com


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. 

Sod Almighty

unread,
May 17, 2013, 6:59:50 PM5/17/13
to golan...@googlegroups.com, Sod Almighty
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.

Tad Glines

unread,
May 17, 2013, 7:04:13 PM5/17/13
to Sod Almighty, golang-nuts, Ian Lance Taylor
On Fri, May 17, 2013 at 3:27 PM, Sod Almighty <sod.al...@gmail.com> wrote:
On Friday, May 17, 2013 10:54:57 PM UTC+1, Tad Glines wrote:

The language developers WANT to add generics to the language.
However, they don't want to rush it.

Well bugger me! A sensible rational discussion on the subject! ;)

I have a tendency to be very opinionated. I can recognize the same in others and can adjust accordingly :-)
  
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.

Hmm...I wasn't aware that generics were that slow. I'll have to write a test program in .NET or something and benchmark it somehow. I'm not familiar with the preprocessors you mention; not being a Java developer. Isn't a preprocessor just another version of option 1, though?

The distinction between option 1 and a preprocessor (or language translator) is that the core language developers don't have to support it. Browsers don't need to know, or care, about coffescript and Oracle (and other JVM developers) don't need to care about Groovy. If the developer doesn't mind the additional compile time/ hassle of using a language preprocessor then that's their choice.

As for options 2, the problem isn't necessarily in the way they are designed but in the way they would translate. For example, Java generics use type erasure. That is, in the source you might have Map<String, String>, but in the byte code you end up with Map<Object,Object>. In the case of Map, this works out ok because the only methods Map needs are available in the Object interface so there is no need to create a separate compiled version like in C++. But, because Go doesn't have a type hierarchy with a root type, and none of the types have methods, the Java style isn't really possible without making significant changes to the language. If a particular function/algorithm needs certain methods (e.g. Equals and Less) then the algorithm can require an interface as input then any type that implements those methods can be passed to that function/algorithm. This is sort of like the way C++ templates work but not quite as expressive because you have to do a bit more explicit casting depending on how the interface is used.

In any language there is a tradeoff between expressiveness and performance. Ruby, for example, is very expressive (and thus its popularity), but isn't very fast. For example, a company recently replaced 30 servers with 2 servers when they re-wrote a ruby service in Go.

The Go language developers have made some very specific and conscious choices about the language design with certain goals in mind.
When languages are created there seem to be two philosophies: consensus (mob rule) and opinionated. Many languages fall somewhere in between, some tend to be more inclined to try and please as many people as possible. Others try and stick to a very strict set of core principles regardless of popular opinion. Go seems to be more on the opinionated end of the spectrum. I'm fine with that.

Sod Almighty

unread,
May 17, 2013, 7:07:01 PM5/17/13
to golan...@googlegroups.com


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.

Sanjay

unread,
May 17, 2013, 7:08:36 PM5/17/13
to golan...@googlegroups.com, Sod Almighty, Ian Lance Taylor
I feel obligated to point out the irony that you want to implement LINQ while having the opinion you do about Haskell (and functional languages, more generally). The contrast tickled me.

Cheers,
Sanjay

Sod Almighty

unread,
May 17, 2013, 7:13:41 PM5/17/13
to golan...@googlegroups.com, Sod Almighty, Ian Lance Taylor
On Saturday, May 18, 2013 12:04:13 AM UTC+1, Tad Glines wrote:

As for options 2, the problem isn't necessarily in the way they are designed but in the way they would translate. For example, Java generics use type erasure. That is, in the source you might have Map<String, String>, but in the byte code you end up with Map<Object,Object>. In the case of Map, this works out ok because the only methods Map needs are available in the Object interface so there is no need to create a separate compiled version like in C++. But, because Go doesn't have a type hierarchy with a root type, and none of the types have methods, the Java style isn't really possible without making significant changes to the language. If a particular function/algorithm needs certain methods (e.g. Equals and Less) then the algorithm can require an interface as input then any type that implements those methods can be passed to that function/algorithm. This is sort of like the way C++ templates work but not quite as expressive because you have to do a bit more explicit casting depending on how the interface is used.

I don't see the problem. If you have no class hierarchy, then you have no need for covariance or translation. Suppose I declare a function as follows:

func Foo<T>( a T, b T, comparer func(T,T) bool )

It doesn't matter what T is. Just compile a version of Foo where T is whatever type I'm passing:

Foo(1, 2, func(a int, b int) { return a == b })

If we specify a type limitation (e.g. func Foo<T:interface{ ...some methods... }>) then just don't allow a version of that function to be compiled where T doesn't implement the interface. I honestly don't see the problem.

Ian Lance Taylor

unread,
May 17, 2013, 7:15:49 PM5/17/13
to Sod Almighty, golan...@googlegroups.com
On Fri, May 17, 2013 at 3:51 PM, Sod Almighty <sod.al...@gmail.com> 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

Sod Almighty

unread,
May 17, 2013, 7:17:30 PM5/17/13
to golan...@googlegroups.com, Sod Almighty, Ian Lance Taylor
On Saturday, May 18, 2013 12:08:36 AM UTC+1, Sanjay wrote:
I feel obligated to point out the irony that you want to implement LINQ while having the opinion you do about Haskell (and functional languages, more generally). The contrast tickled me.

No irony at all. The functional paradigm has its uses - e.g. LINQ - and can make code far more readable. Some programming problems just lend themselves better to the functional style. I never said I didn't approve of the functional style.

The problem with Haskell is - correct me if I'm wrong - it's functional only. And that's neither use nor ornament to anything who isn't a maths prof. Try writing a Windows application in a pure functional language. Even F# supports imperative statements.

Ian Lance Taylor

unread,
May 17, 2013, 7:18:59 PM5/17/13
to Sod Almighty, golan...@googlegroups.com
On Fri, May 17, 2013 at 3:59 PM, Sod Almighty <sod.al...@gmail.com> 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

Gustavo Niemeyer

unread,
May 17, 2013, 7:18:47 PM5/17/13
to Sod Almighty, golan...@googlegroups.com
On Fri, May 17, 2013 at 7:51 PM, Sod Almighty <sod.al...@gmail.com> 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

Tad Glines

unread,
May 17, 2013, 7:29:27 PM5/17/13
to Sod Almighty, golang-nuts, Ian Lance Taylor
On Fri, May 17, 2013 at 4:13 PM, Sod Almighty <sod.al...@gmail.com> wrote:
I don't see the problem. If you have no class hierarchy, then you have no need for covariance or translation. Suppose I declare a function as follows:

func Foo<T>( a T, b T, comparer func(T,T) bool )

It doesn't matter what T is. Just compile a version of Foo where T is whatever type I'm passing:

Foo(1, 2, func(a int, b int) { return a == b })

If we specify a type limitation (e.g. func Foo<T:interface{ ...some methods... }>) then just don't allow a version of that function to be compiled where T doesn't implement the interface. I honestly don't see the problem.

That's the way C++ does it. The compiler has to:
1. Create a separate instance of Foo for each type. This is unavoidable in the case where an interface isn't used.
2. When the compiler/linker has to de-duplicate all the instantiated templates.
3. There is the potential for code bloat (in the non-interface case) and a much slower compile and link times.

I get the impression that the golang developers are trying to avoid any language change that would result in a slower compile time or in code bloat.

Also, the later case you gave "func Foo<T:interface{ ...some methods... }>" is already more or less supported in Go (e.g. func (t *T) Foo(value SomeInterface) SomeOtherInterface).

I think part of the difficulty with Go is that, in many ways, its syntax looks like something familier, but in many ways the language itself is very different. One common problem I see on this forum is people having difficulty switching from inheritance to embedding. Embedding can have some of the same results, but it isn't the same thing at all, and until people adjust to it they will continue to encounter a mental impedance mismatch.

Sod Almighty

unread,
May 17, 2013, 7:32:40 PM5/17/13
to golan...@googlegroups.com, Sod Almighty
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.

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.

Sod Almighty

unread,
May 17, 2013, 7:37:04 PM5/17/13
to golan...@googlegroups.com, Sod Almighty
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.

Sod Almighty

unread,
May 17, 2013, 7:38:50 PM5/17/13
to golan...@googlegroups.com, Sod Almighty


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.

Sod Almighty

unread,
May 17, 2013, 7:39:58 PM5/17/13
to golan...@googlegroups.com, Sod Almighty

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.

Sod Almighty

unread,
May 17, 2013, 7:41:44 PM5/17/13
to golan...@googlegroups.com, Sod Almighty, Ian Lance Taylor
On Saturday, May 18, 2013 12:29:27 AM UTC+1, Tad Glines wrote:

Also, the later case you gave "func Foo<T:interface{ ...some methods... }>" is already more or less supported in Go (e.g. func (t *T) Foo(value SomeInterface) SomeOtherInterface).

Hmm, not really. Because T would be a concrete type that implemented the interface, not the interface itself. I could pass a closure to it that took a T, rather than one that merely took the interface.

Ian Lance Taylor

unread,
May 17, 2013, 7:50:31 PM5/17/13
to Tad Glines, Sod Almighty, golang-nuts
On Fri, May 17, 2013 at 4:29 PM, Tad Glines <tad.g...@gmail.com> wrote:
>
> I get the impression that the golang developers are trying to avoid any
> language change that would result in a slower compile time or in code bloat.

Yes, see also http://research.swtch.com/generic .

Ian

Dan Kortschak

unread,
May 17, 2013, 7:58:05 PM5/17/13
to Sod Almighty, golan...@googlegroups.com, Sod Almighty
I didn't realise a period was easier to type than a new line.

Ian Lance Taylor

unread,
May 17, 2013, 8:07:04 PM5/17/13
to Sod Almighty, golan...@googlegroups.com
On Fri, May 17, 2013 at 4:32 PM, Sod Almighty <sod.al...@gmail.com> 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.

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

Sod Almighty

unread,
May 17, 2013, 8:08:27 PM5/17/13
to golan...@googlegroups.com
On Saturday, May 18, 2013 12:58:05 AM UTC+1, kortschak wrote:
I didn't realise a period was easier to type than a new line.

Perhaps you're being deliberately obtuse?

An imperative alternative to a LINQ query involves temporary variables, loops, unnecessary filling and emptying of lists, and other such clutter. For example, I can write "get me a list of all files in a directory, which are .txt files, sort them by date, and present me the top ten results, capitalised, without the file extension" in one line of code. And it'd be obvious from context what I was doing. Granted, it'd be a fairly long line, so I'd probably split it over three, but I daresay it'd take a dozen or so in Go. At least. And it wouldn't be immediately obvious what I was trying to achieve.

And that's just strings - not even taking custom types into account, which is the whole point of generics.

I like some things about Go - multiple return values, for example. In some ways, Go is a step forward. But it's sorely lacking in a couple of areas, one of which being generics. Support for async/yield would be nice too - and iterators - but I started with what I considered the most important.

Sod Almighty

unread,
May 17, 2013, 8:13:04 PM5/17/13
to golan...@googlegroups.com, Sod Almighty


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

Ian Lance Taylor

unread,
May 17, 2013, 8:13:32 PM5/17/13
to Sod Almighty, golan...@googlegroups.com
On Fri, May 17, 2013 at 4:37 PM, Sod Almighty <sod.al...@gmail.com> 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

Dan Kortschak

unread,
May 17, 2013, 8:17:54 PM5/17/13
to Sod Almighty, golan...@googlegroups.com
Mayhap, but there is an obvious list of candidates for doing something like what you want just a google away:

https://github.com/astaxie/beedb
https://github.com/coopernurse/gorp
https://github.com/gosexy/db

Sod Almighty

unread,
May 17, 2013, 8:20:08 PM5/17/13
to golan...@googlegroups.com, Sod Almighty
On Saturday, May 18, 2013 1:17:54 AM UTC+1, kortschak wrote:
Mayhap, but there is an obvious list of candidates for doing something like what you want just a google away:

I'm sorry, did I somehow give the impression that I was accessing a database?

Ian Lance Taylor

unread,
May 17, 2013, 8:23:50 PM5/17/13
to Sod Almighty, golan...@googlegroups.com
On Fri, May 17, 2013 at 5:13 PM, Sod Almighty <sod.al...@gmail.com> 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

Sod Almighty

unread,
May 17, 2013, 8:30:48 PM5/17/13
to golan...@googlegroups.com, Sod Almighty

We'll just have to disagree on that point, I guess.

Dougx

unread,
May 17, 2013, 8:49:10 PM5/17/13
to golan...@googlegroups.com, Sod Almighty
I'm not going to discuss it in this thread, which is spiraling out of control, but there's no reason you can't chain methods in go, passing an interface as a return type and doing a type assertion on the result, like:

var blah = package.GetAggregate()
var subset, err = linq.From(blah).Where(func(x T) bool { return x.Value == 10 }).Select(func(x T) []interface{} { return []interface{} { x.Value, x.Name }).OrderBy(func(x1 T, x2 T) bool { return x1.Value > x2.Value }).Result()
var typed_subset = subset.([]int)

Notice you need the .Result() to collect errors and the final result from the data set.

the closure syntax isn't as pretty as in C# or python, where you can x => x.Value == ?, but it *does* work.

You could get pretty far down the road of writing a linq library if you wanted to.

If you want to talk about it practically, start a new thread with a different topic.

~
Doug.

On Saturday, May 18, 2013 6:41:48 AM UTC+8, Sod Almighty wrote:


On Friday, May 17, 2013 11:15:58 PM UTC+1, kortschak wrote:

As another apporach to your question, similar to Ian's would be to take a pointer to an interface{} and plase the results in that. This is used in a number of places in the standard library. This would depend on reflection, but you could take an interfaced-based approach like Foo(a, b Interface, c SetInterface) where a and b satisfy the behaviours you need to het the inputs and SetInterface satisfies the behaviour of storing that result. Potentially no type assertions are needed under this scheme.

Yeah, but you can't do:

results := values.where( ...filter function... ).orderby( ...sorting function... ).select( ...transformation function... )

With your Foo function, it's a laborious job of one-operation-per-line, plus a bunch of typecasts. Yeah, I realise that with enough work and messing about it's possible to write a function Foo(), but that's not what I intended here. My intention was to allow for a simple SQL-like query syntax, in the style of .NET LINQ. Because doing it imperatively is hard work and less readable. Also potentially slower (if it resolves the queries immediately).

Chris Bolton

unread,
May 17, 2013, 8:49:47 PM5/17/13
to golan...@googlegroups.com, Sod Almighty
um.... what? totally useless? seriously? haskell is flourishing and has a huge community behind it, with many general-purpose applications and frameworks out there. #haskell is the 7th largest channel on freenode with over a thousand users in it. Get your head out of the sand.

On Friday, May 17, 2013 3:36:18 PM UTC-7, Sod Almighty wrote:

On Friday, May 17, 2013 11:04:41 PM UTC+1, Ziad Hatahet wrote:
On Fri, May 17, 2013 at 2:59 PM, Sod Almighty <sod.al...@gmail.com> wrote:
Oooh, another native language! I googled for native languages recently and never encountered Rust. Thanks for pointing it out. I'll take a look.

The only other natives I know of are D (buggy as hell), C++, AutoIt (a bit lacking) and Red (afaik, not yet in a usable condition). Any more?

Objective-C and Haskell, to name a couple.

I'm not an expert, but Objective-C would appear (at a casual glance) to suffer from the same problems as C++. For example, it has header files, which I personally consider the absolute most stupid and awkward feature of C/C++. I just googled and apparently it does have a GC, which I didn't realise. But it's primarily a Mac-targeted language. I'm not sure how feasible it'd be to write Windows software in it. Guess I'll take a look. It looks mighty strange at a casual glance, though. Trying to think of it as a parallel universe version of C++ just isn't working for me ;)

Haskell? Are you serious? It's a purely functional language - which in my opinion means it's totally useless - and, as far as I'm aware, totally dead except amongst mathematicians.

Sean Russell

unread,
May 17, 2013, 8:53:13 PM5/17/13
to golan...@googlegroups.com, Sean Russell, sod.al...@gmail.com
Hi Ian,

On Friday, May 17, 2013 5:43:20 PM UTC-4, Ian Lance Taylor wrote:
On Fri, May 17, 2013 at 1:57 PM, Sean Russell <seaner...@gmail.com> wrote:
> Not really.
>
>     http://play.golang.org/p/TgB_pRVBdP
>
> There goes type safety, and, consequently, a core feature.

The language still has type safety, of course--that's why your code panics.
 
I'm not sure I'd call that type safety.  A run-time panic because of a type error isn't type safety; type safety is supposed to prevent those sorts of errors -- unless you're in the camp that believes type safety is preventing incorrect, continued execution.  I believe this is the same as saying that C prevents pointer errors by segfaulting -- which is to say, it renders the question of "safety" a meaningless question.

What this approach lacks is compile-time type safety.  It's a serious
problem.  I just want to make sure we give it the right name.

Me too, although it's probably not worth quibbling over.  I will cede that it would have been more accurate to say that this sort of programming defeats strong typing.

--- SER

Sean Russell

unread,
May 17, 2013, 9:00:47 PM5/17/13
to golan...@googlegroups.com, sod.al...@gmail.com
On Friday, May 17, 2013 5:01:43 PM UTC-4, Sod Almighty wrote:
On Friday, May 17, 2013 9:57:16 PM UTC+1, Sean Russell wrote:
Not really.

    http://play.golang.org/p/TgB_pRVBdP

There goes type safety, and, consequently, a core feature.

What type safety? The type safety that forces you to write a different function for every type you want to use it with; while simultaneously forcing you to give each function a different name?

I think you misunderstood me.  I agree with you.

--- SER

Kyle Lemons

unread,
May 17, 2013, 9:04:56 PM5/17/13
to Sod Almighty, golang-nuts
On Fri, May 17, 2013 at 4:32 PM, Sod Almighty <sod.al...@gmail.com> 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-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!
 

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

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.

Sod Almighty

unread,
May 17, 2013, 9:05:39 PM5/17/13
to golan...@googlegroups.com, sod.al...@gmail.com

Oh, well, that's alright then ;)
 

Ziad Hatahet

unread,
May 17, 2013, 9:22:15 PM5/17/13
to Sod Almighty, golan...@googlegroups.com
On Fri, May 17, 2013 at 3:36 PM, Sod Almighty <sod.al...@gmail.com> wrote:
Haskell? Are you serious? It's a purely functional language - which in my opinion means it's totally useless - and, as far as I'm aware, totally dead except amongst mathematicians.


Except that Carmack is porting Wolfenstein 3D into it :) It will be an interesting project to follow IMO: https://twitter.com/id_aa_carmack/status/331918309916295168


--
Ziad

Sanjay

unread,
May 17, 2013, 9:39:51 PM5/17/13
to golan...@googlegroups.com, sod.al...@gmail.com
C#'s async in Go would be quite superfluous, as far as I can tell. In Go, all blocking operations are implicitly marked async, and whenever you call these operations, you are implicitly calling await. The keyword `go' is roughly equivalent to creating and running a Task.

For instance, this: http://play.golang.org/p/w-MTUDAyCD is a concurrent echo server. 

Note that yield and iterators are a different story; I wouldn't mind seeing coroutines, or more accurately iterators in Go sans-channels, but I don't think the authors are super interested. Discussion for another day, though.

Sanjay

Sod Almighty

unread,
May 17, 2013, 9:43:04 PM5/17/13
to golan...@googlegroups.com, Sod Almighty
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> 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.

Sod Almighty

unread,
May 17, 2013, 9:47:22 PM5/17/13
to golan...@googlegroups.com, sod.al...@gmail.com
On Saturday, 18 May 2013 02:39:51 UTC+1, Sanjay wrote:
C#'s async in Go would be quite superfluous, as far as I can tell. In Go, all blocking operations are implicitly marked async, and whenever you call these operations, you are implicitly calling await. The keyword `go' is roughly equivalent to creating and running a Task.

*facepalm* You're right, of course. Go is the one language that doesn't need async. Duh. What was I thinking?

I think I was just listing useful stuff that I keep missing in new languages, coming from .NET, and async was one of those.

Dan Kortschak

unread,
May 17, 2013, 9:53:00 PM5/17/13
to Kyle Lemons, Sod Almighty, golang-nuts
Are you thinking of gosexy?

Sanjay

unread,
May 18, 2013, 12:26:37 AM5/18/13
to golan...@googlegroups.com, Kyle Lemons, Sod Almighty
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

Kiki Sugiaman

unread,
May 17, 2013, 7:28:13 PM5/17/13
to golan...@googlegroups.com
Haskell is not "functional only" anymore once you get to monads. Whether the use of monads makes our life easier or harder is a different story.


On 5/17/2013 6:17 PM, Sod Almighty wrote:
On Saturday, May 18, 2013 12:08:36 AM UTC+1, Sanjay wrote:
I feel obligated to point out the irony that you want to implement LINQ while having the opinion you do about Haskell (and functional languages, more generally). The contrast tickled me.

No irony at all. The functional paradigm has its uses - e.g. LINQ - and can make code far more readable. Some programming problems just lend themselves better to the functional style. I never said I didn't approve of the functional style.

The problem with Haskell is - correct me if I'm wrong - it's functional only. And that's neither use nor ornament to anything who isn't a maths prof. Try writing a Windows application in a pure functional language. Even F# supports imperative statements.

Ian Lance Taylor

unread,
May 18, 2013, 1:44:21 AM5/18/13
to and...@atoulou.se, golan...@googlegroups.com, Sod Almighty
On Fri, May 17, 2013 at 8:30 PM, <and...@atoulou.se> 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

Michael Jones

unread,
May 18, 2013, 3:33:02 AM5/18/13
to Ian Lance Taylor, and...@atoulou.se, golang-nuts, Sod Almighty
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)

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





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

Gerard

unread,
May 18, 2013, 5:23:32 AM5/18/13
to golan...@googlegroups.com, Ian Lance Taylor, and...@atoulou.se, Sod Almighty
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. 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:

Aram Hăvărneanu

unread,
May 18, 2013, 5:33:41 AM5/18/13
to Gerard, golang-nuts, Ian Lance Taylor, and...@atoulou.se, Sod Almighty
> 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

Dan Kortschak

unread,
May 18, 2013, 5:37:42 AM5/18/13
to Aram Hăvărneanu, Gerard, golang-nuts, Ian Lance Taylor, and...@atoulou.se, Sod Almighty
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.

Andrew Akira Toulouse

unread,
May 18, 2013, 5:41:43 AM5/18/13
to Gerard, golan...@googlegroups.com, Ian Lance Taylor, Sod Almighty
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.

Russel Winder

unread,
May 18, 2013, 6:24:47 AM5/18/13
to Sod Almighty, golan...@googlegroups.com
On Fri, 2013-05-17 at 14:59 -0700, Sod Almighty wrote:
[…]
> The only other natives I know of are D (buggy as hell), C++, AutoIt (a bit
> lacking) and Red (afaik, not yet in a usable condition). Any more?

This is the second time you have made the claim that D is unusable due
to bugs. Can I suggest that rather than just making unsubstantiated
claims to go to the D mailing list and debate the actual issues you
have.

C++ / D / Go / Rust is a really interesting situation just now and the
classes and generics issues are interesting ones. I would though prefer
substantiated debate rather than simple off-hand opinion.

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc

Alexei Sholik

unread,
May 18, 2013, 6:52:02 AM5/18/13
to golang-nuts
If you set up a second ML for Go2 you'll hopefully see less heated discussions about changing Go on this list. Since Go 1.x won't ever get the changes mentioned in the first post and Go2 is years (probably decades) away, discussing it here does not feel that productive.
--
Best regards
Alexei Sholik

Mathieu Lonjaret

unread,
May 18, 2013, 8:20:24 AM5/18/13
to Ian Lance Taylor, golan...@googlegroups.com
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 <ia...@golang.org> wrote:
> On Fri, May 17, 2013 at 4:37 PM, Sod Almighty <sod.al...@gmail.com> 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.

Bob Hutchison

unread,
May 18, 2013, 10:32:18 AM5/18/13
to golan...@googlegroups.com, Sod Almighty

On 2013-05-17, at 7:17 PM, Sod Almighty <sod.al...@gmail.com> wrote:

The problem with Haskell is - correct me if I'm wrong - it's functional only. And that's neither use nor ornament to anything who isn't a maths prof. Try writing a Windows application in a pure functional language. Even F# supports imperative statements.


Haskell *is* functional *and* happens to be "the world's finest imperative language" -- or so they say :-) In my opinion, it is very easy and natural to write imperative code in Haskell, and you will remain 100% functional while doing so.

It has generics too :-)

As for it's usefulness to those other than maths profs… I'm no maths prof but I've had rather good success at implementing a very tricky application in Haskell that I could not reasonably write in Go (and I tried).

Have a read of "Tackling the Awkward Squad" at:


Note the author's affiliation. This is the paper where the phrase "the world's finest…" above comes from, and the paper is intended in part to argue the claim. This paper was very important to my 'getting' Haskell. I think it's particularly useful for programmers experienced in other languages and who are coming to Haskell.

This is not to say that Haskell is easy.

Cheers,
Bob

Sod Almighty

unread,
May 18, 2013, 10:37:00 AM5/18/13
to golan...@googlegroups.com, Sod Almighty
On Saturday, 18 May 2013 11:24:47 UTC+1, Russel Winder wrote:
On Fri, 2013-05-17 at 14:59 -0700, Sod Almighty wrote:
[…]
> The only other natives I know of are D (buggy as hell), C++, AutoIt (a bit
> lacking) and Red (afaik, not yet in a usable condition). Any more?

This is the second time you have made the claim that D is unusable due
to bugs. Can I suggest that rather than just making unsubstantiated
claims to go to the D mailing list and debate the actual issues you
have.

I did. They told me that they weren't adding new features to the language because they were focusing on stabilising the language and fixing things. And then they told me that the bugs I'd reported weren't likely to get fixed either anytime soon. You know, unimportant little bugs like "it won't compile if the directory has a space in it" or "the compiler insists it can't see one of your code files", or "if you omit the optional package header, you can't build".

So I gave up. I'd love to use D, but the developers just don't seem to give a damn.

suharik

unread,
May 19, 2013, 11:21:36 AM5/19/13
to golan...@googlegroups.com
If you want generics, post your proposal here, and then read to this link: http://goo.gl/1j8Cs
We want to have sane generics in go too.

Also, I'd like to have something like haskell monads to handle errors, instead of code like this: http://stackoverflow.com/a/16127029/2267702

Sod Almighty

unread,
May 19, 2013, 2:13:01 PM5/19/13
to golan...@googlegroups.com
On Sunday, 19 May 2013 16:21:36 UTC+1, suharik wrote:
If you want generics, post your proposal here, and then read to this link: http://goo.gl/1j8Cs
We want to have sane generics in go too.

Apparently you don't. The form at that link essentially boils down to "there are only a finite number of ways to implement generics, and we will accept none of them".

Fine. Carry on having a crappy language then. To my mind, it currently rates barely higher than AutoIt - as in, when I find myself needing to write a couple-dozen-line program to perform a simple task like culling old backup zipfiles or truncating a log, I'll use Go instead of AutoIt. But anything more complicated, and it's C++, D (if they ever fix the damn thing) or maybe Rust.

Go has some nice features; but I draw the line at writing boilerplate code everywhere. That's what we're supposed to be avoiding. Personally, I think you should just decide on a damn implementation, and do it. You're never gonna find a perfect solution, and having no solution is worse than having a less-than-perfect one.

Rémy Oudompheng

unread,
May 19, 2013, 2:22:19 PM5/19/13
to Sod Almighty, golang-nuts
On 2013/5/19 Sod Almighty <sod.al...@gmail.com> wrote:
> Go has some nice features; but I draw the line at writing boilerplate code
> everywhere. That's what we're supposed to be avoiding. Personally, I think
> you should just decide on a damn implementation, and do it. You're never
> gonna find a perfect solution, and having no solution is worse than having a
> less-than-perfect one.

I wrote Go programs for the past year and never felt like it was
boilerplate, and usually didn't feel the need to write boilerplate.

Why are you actually writing boilerplate?

Rémy.

Sod Almighty

unread,
May 19, 2013, 2:43:46 PM5/19/13
to golan...@googlegroups.com, Sod Almighty

Well, I'm not "actually" writing boilerplate, because I've not really written much in Go so far. I simply figured that there are two ways to write a complex data query (not necessarily to a database), and those are [a] LINQ and [b] with a fuckton of boilerplate.

For example, suppose I want a list of the top ten .txt files in a directory, capitalised, sorted by date, and without the file extension?

In LINQ, I can say something like this:

results = EnumFiles(path).Where(lambda).OrderBy(lambda).Select(lambda)

In Go, way I see it, I'd need to do something like this:

Get a list of files into a slice
Make a new temporary slice
Enumerate through them, copying the ones that end in .txt into the new slice
Create an interface type to represent a slice of files, with custom functions for sorting by date
Cast the slice to this interface and call Sort()
Make a new temporary slice
Enumerate through the results, building a new list of capitalised filenames sans extension into the new slice

Better? I don't think so.

Andreas Krennmair

unread,
May 19, 2013, 2:53:02 PM5/19/13
to Sod Almighty, golan...@googlegroups.com


On 19.05.2013, at 20:13, Sod Almighty <sod.al...@gmail.com> wrote:


Go has some nice features; but I draw the line at writing boilerplate code everywhere. That's what we're supposed to be avoiding. Personally, I think you should just decide on a damn implementation, and do it. You're never gonna find a perfect solution, and having no solution is worse than having a less-than-perfect one.

Have you ever considered the possibility that your Go experience might be bad because you use Go is exactly like you use a completely different language even though the language features don't match? All your rambling here moved around the topic of not having generics. Instead of trying to get generics into Go with all force and much insulting of developers, you should rather consider trying to embrace Go's language feature set. Most Go users managed to do so without having to produce much or any boilerplate, so you should manage, too.

Andreas

Sod Almighty

unread,
May 19, 2013, 2:57:55 PM5/19/13
to golan...@googlegroups.com, Sod Almighty
On Sunday, 19 May 2013 19:53:02 UTC+1, Andreas Krennmair wrote:

Have you ever considered the possibility that your Go experience might be bad because you use Go is exactly like you use a completely different language even though the language features don't match? All your rambling here moved around the topic of not having generics. Instead of trying to get generics into Go with all force and much insulting of developers, you should rather consider trying to embrace Go's language feature set. Most Go users managed to do so without having to produce much or any boilerplate, so you should manage, too.

Alright. How would I go about filtering, sorting and transforming a list of arbitrary objects without all this faffing about? Is there some nifty Go solution that I'm missing? Some way to avoid having to write a new type every time I want to change how something is sorted, perhaps?

Rémy Oudompheng

unread,
May 19, 2013, 3:12:05 PM5/19/13
to Sod Almighty, golang-nuts
Did you actually try to write it?

Here is an interesting way of doing it in Go:

func main() {
files, err := ioutil.ReadDir("/usr/lib")
if err != nil {
log.Fatal(err)
}
var txts []os.FileInfo
for _, f := range files {
if strings.HasSuffix(f.Name(), ".so") {
txts = append(txts, f)
}
}
is := SimpleSort(len(txts), func(i, j int) bool {
return txts[i].ModTime().After(txts[j].ModTime())
})
var s []string
for _, i := range is[:10] {
fmt.Println(i)
n := strings.ToUpper(txts[i].Name())
s = append(s, n[:len(n)-3])
}
DoSomethingWith(s)
}

// Generic sorting function (simple to use and reusable anywhere).
func SimpleSort(length int, less func(i, j int) bool) []int {
s := simpleSorter{
LessFunc: less,
Indices: make([]int, length),
}
for i := range s.Indices {
s.Indices[i] = i
}
sort.Sort(&s)
return s.Indices
}

type simpleSorter struct {
LessFunc func(i, j int) bool
Indices []int
}

func (s *simpleSorter) Len() int { return len(s.Indices) }
func (s *simpleSorter) Less(i, j int) bool { return
s.LessFunc(s.Indices[i], s.Indices[j]) }
func (s *simpleSorter) Swap(i, j int) { s.Indices[i],
s.Indices[j] = s.Indices[j], s.Indices[i] }

Notice how in this code, the SimpleSort function and simpleSorter type
are generic and totally reusable, we can assume it to live in a nice
library. The body of main() contains exactly 375 non-whitespace
characters.

Now here is the LINQ equivalent on that code using your syntax suggestion:

func linq_main() {
files, err := ioutil.ReadDir("/usr/lib")
if err != nil {
log.Fatal(err)
}
s := files.Where(func(fi os.FileInfo) bool {
return strings.HasSuffix(fi.Name(), ".so")
}).OrderBy(func(a, b os.FileInfo) bool {
return a.ModTime().After(b.ModTime())
}).Select(func(fi os.FileInfo) string {
n := strings.ToUpper(fi.Name())
return n[:len(n)-3]
})
s = s[:10]
DoSomethingWith(s)
}

That's 325 non-whitespace characters in the body. So less than 15% of
characters are saved, and the code looks like a dense block of
difficult to read things (mostly because of Go's closure syntax, but
the debate is about generics, not closure syntax).

And my version has the advantage of being totally type safe, and not
need any language extensions.

Rémy.

Rémy Oudompheng

unread,
May 19, 2013, 3:13:04 PM5/19/13
to Sod Almighty, golang-nuts
On 2013/5/19 Sod Almighty <sod.al...@gmail.com> wrote:
I just sent one.

Rémy.

Ziad Hatahet

unread,
May 19, 2013, 3:23:23 PM5/19/13
to Rémy Oudompheng, Sod Almighty, golang-nuts
On Sun, May 19, 2013 at 12:12 PM, Rémy Oudompheng <remyoud...@gmail.com> wrote:
    s := simpleSorter{
        LessFunc: less,
        Indices:  make([]int, length),
    }


This solution might be more generic, but now you are introducing a huge memory overhead with the Indices slice. Unless I am missing something, it is proportional to the number of elements you want to sort, correct?
 

and the code looks like a dense block of
difficult to read things (mostly because of Go's closure syntax, but
the debate is about generics, not closure syntax).


True. A language that does type inference on closure/lambda syntax (I think even Java is getting this in the next release) would make this much more compact, elegant, and easier to read.

--
Ziad

Andreas Krennmair

unread,
May 19, 2013, 3:27:31 PM5/19/13
to Sod Almighty, golan...@googlegroups.com, Sod Almighty


On 19.05.2013, at 20:57, Sod Almighty <sod.al...@gmail.com> wrote:


Alright. How would I go about filtering, sorting and transforming a list of arbitrary objects without all this faffing about? Is there some nifty Go solution that I'm missing? Some way to avoid having to write a new type every time I want to change how something is sorted, perhaps?


writing functions to operate on arbitrary data by using interfaces and type assertions is surprisingly low-overhead in terms of boiler plate. I admit, this is not the optimal solution because it moves some type safety from compilation to runtimr, but I dare to claim that this won't be a bottleneck in any of your programs anytime soon, and reasonable automated test coverage can alleviate the type safety issue.

IIRC, there was also another library published recently that solved the problem in a similar and type-safer fashion using reflection internally.

Also, what Rémy sent you.

Andreas

It is loading more messages.
0 new messages