And you might argue, well hell this is no different than proposing
func Sort(a, b interface{}[]){
if a.(type) ...
}
Exactly because the language isn't broken.
C gets along just fine without generics. In fact that is considered a
feature of the language.
What absolutely doesn't scale is keeping into consideration the millions of
whats your code could be defined way up there ^ in the file (or more
horrifically, defined in another file) can actually impact the code you are
looking at here > on the current line of code. That doesn't scale and I
thought that was the point why we were happy with the compromise between
interfaces and not having generics?
Give me one example of something you can't do (according to turing) in Go
but you can in another language with convoluted generic syntax, and ill be
totally on board. But the fact that you can't proves that this feature
sucks and rejecting the majority is what should be done.
I mean if they were demanding us to put in classes would we give them that
just because they all demanded it? Because frankly, I see way more
usefulness in the genericity of classes than i do in the genericity of
types.
On Monday, January 18, 2021 at 11:47:14 PM UTC-6 mortdeus wrote:
> The more I look at the proposed generic syntax the more I feel like a
> texan fearing the californian relocation to my state. In other words I am
> feeling like Go had something awesome and extremely conservative going on
> in terms of syntax and because people from other super convoluted languages
> are coming over (which their leaving should say a lot about their said
> language) and they don't have their one "to die for" feature from their old
> language they are expecting us to conform.
>
> The reality I want to ask is whether any of the designers of the language
> actually want this feature to the point that they want to be looking at
> said feature all day, every day when they are working on other people's
> code, or are they just conforming because so many people are asking for a
> feature, and they feel a desire to give the people what they ask for,
> without considering the fact that the majority doesn't always consider the
> implications of what they ask for?
>
> I dont intend to go any more political than this, but what im trying to
> say if were going to ruin the language, atleast ruin it in a way where we
> isolate the code where its being ruined, that way when we get to that point
> in the code we know to think "okay this is where things can get screwy".
>
> What I mean is to just give us an omnipotent "any" builtin type and to
> make those special case functions that get extra attention by the runtime.
>
> func sort(a, b any){
> if a < b{
> lots of pre defined magic happens
> }
>
> if a.(type) < a.(type){
> lots of compile time magic happens
> }
> }
>
> if the people want magic give them magic, but don't ruin the language for
> the rest of us.
>
> The current proposals suck and the current proposal is going to be a
> constant reminder that the language sucks now as soon as you put them in.
> The fact that you keep blogging essentially "hey guys were about to put in
> generics... are you absolutely sure..... because we aren't and once we do
> were kind of stuck with it...?"
>
> The answer is simply biological.
>
> If you don't want to then don't. But if you do then put it in already.
>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/a5f47d9a-09e8-484c-b66a-281ad5448d52n%40googlegroups.com.
