Comment by margorczynski
9 months ago
> I just can't go back to Go with nil pointers and lack of decent enums/ADTs/pattern matching either.
Go is simply a badly designed language where the idea of "simplicity" has been maligned and proven bad ideas likes nil/null, exceptions and such have been introduced in a seemingly modern language. One would think that decades of Java, Javascript, etc. code blowing up because of this issues would teach someone something but seems that is not always the case.
Having worked with Go for about a decade now, I largely agree that nil is a pain in the ass to work with, and the language has largely done nothing to make it better. However, Go (mostly) doesn't have exceptions. Ordinary problems are represented by non-nil errors, which are values. Panics exist but really are reserved for exceptional situations (with the number 1 cause being, of course, dereferencing nil).
Nil in go is my biggest gripe with the language. Why keep repeating “the billion dollar mistake” in a relatively newly designed language??
There are a lot of ways in which Go handles nil better than C handles NULL. At the very least, a panic is better than a segfault. And carefully written code can avoid most kinds of nil panics entirely. So I guess the language's authors thought this would be enough to overcome the mistake. But I don't think they went far enough. The very limited type system and the lack of nil-safe operators make it not very ergonomic to write and read such "carefully written" code; design decisions in some key parts of the standard library completely undermine the language's attempts to minimize nil; and then there's the "untyped nil" default value for interfaces, which panics if you just look at it funny.
"code blowing up because of this issues"
I ran into these issues all the time with Java, C++, and Python projects.
But it's just not the experience of running Go in production, which I've been doing for over 10 years now, across many projects with many devs.
In practice, nil checks are just not very difficult to include everywhere. And experienced Go programmers don't use exceptions (panic/recover) almost ever.
What you said is:
1) Anecdotal
2) Based on faith that someone will not forget to do something instead of a well documented mechanism in the language that could block that from the start
Having nil/null to handle empty references is simply very bad design and there's decades of examples why. The correct way is using a two-value type like Option, Maybe, etc. so that the (possibility) of the value missing is actually encoded in the type system
And yet it is incredibly productive. The poster that contrasted engineers with artists got it right I think. Go is an engineer’s language.
> Go is an engineer’s language.
No, Ada/Spark is an example of a good engineers language. Go is a mediocre effort at best. Rob Pikes defence is that it was designed for junior Googlers who "aren't capable of understanding a brilliant language". Yes that's a real quote.
What’s a brilliant language in this context
2 replies →
[dead]
Go is great