News for hackers. Stuff that matters.
Re:Go 1.5 max procs default by PopsiclePete on Friday May 29, 2015 @12:44PM (#9625663)
It's just not an easy problem to solve. And I'm not convinced it has been already solved, much less solved correctly, in the vast majority of cases.

This is legal(-ish) C++:

template<typename T> T Add(T one, T two){ return one + two; }

It's completely illegal in C#. And Java. Both have "generics". Both are wildly different.

Then you have the Haskell camp which look at all of these "generics" and shake their heads and laugh bitterly since their static type system and "generic" blow all other ones out of the water anyway.

So when you say you want "generics" - which flavor do you want? How does it play with Go's interfaces? How deep down the rabbit hole do you go?

It's very easy, when you're not familiar with the problem to say "just do it" - but everyone seems to have their own idea of what "generics" is, how it works, how to constrain parameters, etc.

So even if the Go team picked an implementation from Camp A, I'm 120% positive that camps B, C, D, and X would declare it the worst implementation ever, and again, they've pleased no-one.

I'm glad they're sticking to their guns on this one.

Show them an implementation that works in Go, and they've said multiple times they might do it. Put up or shut up, basically.

Re:Go 1.5 max procs default by zerr on Friday May 29, 2015 @02:10PM (#9626295)
I don't understand your logic - just because different languages have some differences in how generic compile-time type-safe code is written, Go should NOT have this at all? And the only reason is that some subgroup might not be fully pleased?

I'm a C++ engineer more than a decade now.. And I'll be more than happy if Go had ANY kind of generics - even Ada-like, with explicit instantiation... Anything is better than current interface{} run-time checked stuff.

Re:Go 1.5 max procs default by PopsiclePete on Friday May 29, 2015 @04:27PM (#9627084)
Sounds like you have something in mind. All you have to do now, is:

1. Expand on your idea with some examples. 2. Show how this can be done without breaking existing Go code 3. Showing where the performance hits are - runtime? compile time? binary size? memory? 4. Show how this plays along with Go's implementation of interfaces, as well as other already-generic types, such as channels and maps.

If you can do all that, realistically, then I don't see why it wouldn't be taken seriously?

Heck, if you can provide even an example implementation (talk is increasingly cheap) I bet you'll get lots of people on-board!

You seem, like many others, to think that Go core team members don't want "generics". All they have ever said is - "we don't want bad generics". That's all.

Anyone can say "I don't know what exactly Go generics are, how they look like, how they perform, how they change the syntax, all I know is - I want them". Like I said, talk is cheap.

Re:Go 1.5 max procs default by codygman on Friday May 29, 2015 @01:07PM (#9625804)
> Show them an implementation that works in Go, and they've said multiple times they might do it. Put up or shut up, basically.

Didn't someone fork Go and do exactly that only to get ignored? Perhaps it was a rumor, do you know? I'll see if I can find any reference to it.

Re:Go 1.5 max procs default by dilap on Saturday May 30, 2015 @03:33PM (#9631479)
That would be interesting to see. (I've never heard of such a thing...)
Re:Go 1.5 max procs default by codygman on Saturday May 30, 2015 @06:36PM (#9632053)
Best I could find was this:

https://groups.google.com/forum/#!topic/golang-nuts/L5Lothlv...

It also led to a real world example where the author tried using Go for a project and had a lot of need for Generics:

http://oneofmanyworlds.blogspot.com/2011/11/draft-2-of-propo...