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