4 ms·

My understanding is that Go haters take issue with three things: - Lack of generics (this will be resolved in the future) - nil exists - interface{} is a *vo

by throwit1979 13y ago

My understanding is that Go haters take issue with three things: - Lack of generics (this will be resolved in the future) - nil exists - interface{} is a *void style type safety loophole These are all very minor issues, but the Go haters just love to harp on them. 99% of the time, I find they hold up ml-style languages as some sort of Holy Perfection. (lulz)

lucian1900 13y ago
Those three flaws are brought up repeatedly because they are a sad regression from the current state of the art in programming language construction. It could've been a much nicer language with very little effort, but its designers chose not to do so.
jerf 13y ago
It's not that nil exists... it that it exists everywhere (on the types that support it), with no way of restricting it. It's actually the one criticism I find the most frustrating because, unlike generics and unlike interface{} (which is sort of a repeat of the generic complaint, that's an effect), it's so easy to fix that during the initial design, and it would not have profoundly affected the rest of the language. In fact it could still be bolted on after the fact, it's that easy and low-impact. That not all types support nil in Go is itself an interesting point; zero types are better than nil, so why didn't we propagate the idea that is already in Go through the language consistently, and not let anything be nil unless we explicitly request it in the type? With most of the rest of the criticisms it's not necessarily clear how to fix Go (that is, it may be fixable but there's no one obvious solution that just works), but that's not the case for non-nullable types. They were always possible, have been for decades, and there's just no reason not to have them and use them as much as possible in the standard lib. Also, I'm not a hater... unless your definition of "hater" is "doesn't like every last detail about Go", in which case, sure, under that degenerate definition I'm a "hater". You really shouldn't sling that term around in a preemptive attempt to marginalize your opponent like that, for a topic like programming languages. Save it for politics. ("Programming languages ARE politics." Well, they shouldn't be. Don't fall into that trap.)
- throwit1979 13y ago
  Well I think part of the problem is that most of Go's target audience come from languages where nil/null are used to be meaningful. They recognize it to be "wrong", but the languages in use (e.g. Java) force them into situations where, for example, returning null to mean "this entity wasn't found" is substantially more productive than catching and processing EntityNotFoundException. I think the Go designers wanted the language to be approachable for people who habitually use null to indicate meaningful state. Multiple return values offer a way out, while still allowing newbies the option to abuse nil. (although, sum types would be nicer) I think on balance, getting people from the 1970s to the 1980s who otherwise would not have gone there is a positive thing. Even if it's not the ideal thing. It's not out of the question that Go will make your suggested fixes once it acquires enough mindshare.
  - jerf 13y ago
    Go look at C#, or any other language that has this concept. The point is not that there would be no nil, anywhere, ever, the point is that you would have to ask for it, and by default, you get a type that can't contain nil. C# even proves it can be profitably bolted on after the fact (contra pcwalton)... because that's how unobtrusive this change is. It's not like this is a complicated idea, unlike the other suggestions.
  - pcwalton 13y ago
    Removing nil from Go is not possible without breaking backwards compatibility. The Go core team considers nil a feature anyhow.
- dualogy 13y ago
  > zero types are better than nil huh? Yeah, well. Newsflash: "nil" is nothing more than the zero-value for pointer types (and related other reference-semantics types). Your point again? Should we rename nil with a new keyword "zero"? Fine by me.
  - jerf 13y ago
    I'd rather have a pointer initialized to a new zero-type value, or require you to initialize it as a pointer to an existing thing. Forced-nil pointers are a disaster. Also, please re-read my last two paragraphs.
matrix 13y ago
I like Go. I really want it to succeed as a language. However, it does have some unfortunate warts. To me, one of the biggest issues is the lack of true exceptions. Exceptions that show the call stack (as in Java and .NET) take a lot of the mystery out of real-world troubleshooting an issue with a third-party library (for example). Panic or returning an error doesn't provide the same utility.
viscanti 13y ago
There's a certain elegance (that some ML-Style languages have) that Go forgoes in favor of simplicity. That's often not a bad tradeoff. Simplicity is a nobel goal, and is one of the big reasons for using Go. Go isn't going to break a lot of new ground (Hoare was talking about CSP back in the 70s), but that's fine. It's nice to have ML style languages as playgrounds for PL research, and languages like Go to help large teams be productive (the enforced style and simplicity of Go makes it relatively easy to find people who can contribute quickly to a project). Different languages have different goals, and that's great.
- deleted 13y ago
  [deleted]

lucian1900 13y ago

Those three flaws are brought up repeatedly because they are a sad regression from the current state of the art in programming language construction. It could've been a much nicer language with very little effort, but its designers chose not to do so.

jerf 13y ago

It's not that nil exists... it that it exists everywhere (on the types that support it), with no way of restricting it. It's actually the one criticism I find the most frustrating because, unlike generics and unlike interface{} (which is sort of a repeat of the generic complaint, that's an effect), it's so easy to fix that during the initial design, and it would not have profoundly affected the rest of the language. In fact it could still be bolted on after the fact, it's that easy and low-impact. That not all types support nil in Go is itself an interesting point; zero types are better than nil, so why didn't we propagate the idea that is already in Go through the language consistently, and not let anything be nil unless we explicitly request it in the type? With most of the rest of the criticisms it's not necessarily clear how to fix Go (that is, it may be fixable but there's no one obvious solution that just works), but that's not the case for non-nullable types. They were always possible, have been for decades, and there's just no reason not to have them and use them as much as possible in the standard lib. Also, I'm not a hater... unless your definition of "hater" is "doesn't like every last detail about Go", in which case, sure, under that degenerate definition I'm a "hater". You really shouldn't sling that term around in a preemptive attempt to marginalize your opponent like that, for a topic like programming languages. Save it for politics. ("Programming languages ARE politics." Well, they shouldn't be. Don't fall into that trap.)

throwit1979 13y ago
Well I think part of the problem is that most of Go's target audience come from languages where nil/null are used to be meaningful. They recognize it to be "wrong", but the languages in use (e.g. Java) force them into situations where, for example, returning null to mean "this entity wasn't found" is substantially more productive than catching and processing EntityNotFoundException. I think the Go designers wanted the language to be approachable for people who habitually use null to indicate meaningful state. Multiple return values offer a way out, while still allowing newbies the option to abuse nil. (although, sum types would be nicer) I think on balance, getting people from the 1970s to the 1980s who otherwise would not have gone there is a positive thing. Even if it's not the ideal thing. It's not out of the question that Go will make your suggested fixes once it acquires enough mindshare.
- jerf 13y ago
  Go look at C#, or any other language that has this concept. The point is not that there would be no nil, anywhere, ever, the point is that you would have to ask for it, and by default, you get a type that can't contain nil. C# even proves it can be profitably bolted on after the fact (contra pcwalton)... because that's how unobtrusive this change is. It's not like this is a complicated idea, unlike the other suggestions.
- pcwalton 13y ago
  Removing nil from Go is not possible without breaking backwards compatibility. The Go core team considers nil a feature anyhow.
dualogy 13y ago
> zero types are better than nil huh? Yeah, well. Newsflash: "nil" is nothing more than the zero-value for pointer types (and related other reference-semantics types). Your point again? Should we rename nil with a new keyword "zero"? Fine by me.
- jerf 13y ago
  I'd rather have a pointer initialized to a new zero-type value, or require you to initialize it as a pointer to an existing thing. Forced-nil pointers are a disaster. Also, please re-read my last two paragraphs.

matrix 13y ago

I like Go. I really want it to succeed as a language. However, it does have some unfortunate warts. To me, one of the biggest issues is the lack of true exceptions. Exceptions that show the call stack (as in Java and .NET) take a lot of the mystery out of real-world troubleshooting an issue with a third-party library (for example). Panic or returning an error doesn't provide the same utility.

viscanti 13y ago

There's a certain elegance (that some ML-Style languages have) that Go forgoes in favor of simplicity. That's often not a bad tradeoff. Simplicity is a nobel goal, and is one of the big reasons for using Go. Go isn't going to break a lot of new ground (Hoare was talking about CSP back in the 70s), but that's fine. It's nice to have ML style languages as playgrounds for PL research, and languages like Go to help large teams be productive (the enforced style and simplicity of Go makes it relatively easy to find people who can contribute quickly to a project). Different languages have different goals, and that's great.

deleted 13y ago
[deleted]