5 ms·

> 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

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

nahnahno 2y ago
And yet it is incredibly productive. The poster that contrasted engineers with artists got it right I think. Go is an engineer’s language.
- grumpyprole 2y ago
  > 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.
  - Exuma 2y ago
    What’s a brilliant language in this context
    - grumpyprole 2y ago
      You'd have to ask Rob Pike. My own example of a brilliant language is Haskell, but it's not without problems.
    - pjmlp 2y ago
      Apparently anything that offers a type system beyond Go's.
  - melodyogonna 2y ago
    [dead]
lagichikool 2y ago
"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.
- margorczynski 2y ago
  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
kbolino 2y ago
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).
- sidkshatriya 2y ago
  Nil in go is my biggest gripe with the language. Why keep repeating “the billion dollar mistake” in a relatively newly designed language??
  - kbolino 2y ago
    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.
melodyogonna 2y ago
Go is great

nahnahno 2y ago

And yet it is incredibly productive. The poster that contrasted engineers with artists got it right I think. Go is an engineer’s language.

grumpyprole 2y ago
> 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.
- Exuma 2y ago
  What’s a brilliant language in this context
  - grumpyprole 2y ago
    You'd have to ask Rob Pike. My own example of a brilliant language is Haskell, but it's not without problems.
  - pjmlp 2y ago
    Apparently anything that offers a type system beyond Go's.
- melodyogonna 2y ago
  [dead]

lagichikool 2y ago

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

margorczynski 2y ago
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

kbolino 2y ago

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

sidkshatriya 2y ago
Nil in go is my biggest gripe with the language. Why keep repeating “the billion dollar mistake” in a relatively newly designed language??
- kbolino 2y ago
  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.

melodyogonna 2y ago

Go is great