[mlochbaum]

Well, Lisp is just as functional as ML-family languages like OCaml and F#. Haskell's typed/pure FP is a branch off of this. Surely between Pike, Griesemer, and Thompson someone had some ML experience, but this doesn't matter much for the design of Go. More important is that newcomers can't be expected to have ML experience, and a central goal of Go is to be quickly accessible to new programmers. And there was also a focus on fast compile times, fast execution, and low-level control, which are very hard to achieve with immutable data structures. Overall Go's design is very restrained, which I think shows a lot of wisdom on the part of the authors. ML is not the only language slighted: as Rob says, the only bit of APL that made it in was the name "iota"!

I think it'd be a bit of a shame if everyone were pushed to be a polyglot with a finger in every currently popular paradigm. Connections between different approaches to programming are very useful, but the sort of effort made in Go, to refine and simplify one imperative/OO approach, also helps push our understanding of programming into new territory.

[corethree]

It's the whole (res, error) error handling thing.

Seems like there's an obvious solution that was avoided or not known about here. It's not even about being clever. Its about being practical.

[mlochbaum]

Maybe so. I guess you're talking about option types, although it's not obvious to me that these do any better given the requirement that errors are always explicitly shown in the code. So maybe your problem is with that requirement instead. But why are you listening to a podcast in the hopes the guest will admit his ignorance and tell you something you already know, instead of to learn new things?

[corethree]

>I guess you're talking about option types,

I'm talking about a more general concept. A kind of type that can be either one thing or another. For example an Int or an Error.

You have Product types which are types that are two things at the same time an (int and an error) and you have sum types (int or an error).

To illustrate say I have two types that consists of a small finite set of values type A and type B.

   A = 1 | 2 (cardinality = 2, A can be a 1 or a 2)

and another type that consists of 3

   B = '1 | '2 | '3 (cardinality = 3, B can be a '1, '2 or '3)

A product type is like a tuple or a struct containing both A and B: (A, B). The cardinality of (A, B) is the product of the cardinality of the individual types: 2 * 3 = 6

   (1,'1) (1,'2), (1,'3) (2,'1) (2,'2) (2,'3)  

in other words cardinality is the total amount of possible values that can be represented by the type.

A sum type is a type that consists of EITHER A or B: (A | B). The value can be one or the other. The cardinality becomes the sum of the cardinality of the original types 2 + 3 = 5. In this case the sum type of A | B can be one of these values:

   1, 2, '1, '2, '3
   

Go is missing the sum type. It's like the world of math with only multiplication and no addition. You are missing a critical piece of programming.

An option type is simply a Sum type with two possible types. (Any | None)

But it goes far beyond just Options.

For example JSON is not definable as a type in Go. Not without some really awkward stuff (aka reflection lol). You can define it in almost every other modern language:

Python:

   JSONTYPE = None | float | int | str | List[JSONTYPE] | Dict[str, JSONTYPE]

Haskell:

  data JSValue
    = JSNull
    | JSBool     Bool
    | JSRational Float
    | JSString   String
    | JSArray    [JSValue]
    | JSObject   (JSObject JSValue)

Rust:

  #[derive(Debug, PartialEq, Clone)]
  enum JsonValue {
      Null,
      Bool(bool),
      Number(f64),
      String(String),
      Array(Vec<JsonValue>),
      Object(HashMap<String, JsonValue>),
  }

You can define a type completely isomorphic to json in almost every language. You can't do that at all with Go. Literally this popular data format cannot defined in go. How the heck is that suppose to be "practical"?

What does go do when it comes to parsing json? I've seen it and it appears to be the ugliest thing I've ever seen. But that's another deep dive.

>But why are you listening to a podcast in the hopes the guest will admit his ignorance and tell you something you already know, instead of to learn new things?

I just got a job that involves golang and its now a big part of my life as it's now my daily driver. I thought due to the popularity of the language it must be great.

What ended up happening was Go feels like a broken language. But maybe I'm wrong. Maybe Rob Pike had a good reason not to include sum types in his language, or maybe he just didn't know about it. Imagine that, my life and the lives of other people defined by the fact Rob Pike didn't know something.

That's what I want to find out. Is the popularity of his language really stemming from him and other people not knowing any better? Or is it me not knowing any better? Have I not seen the light? Or have you not?

Put it this way. If you read my post and you knew about everything I said here and you love golang... Then you know something I don't. If you learned something then maybe you haven't seen the light.

[mlochbaum]

Sure, I've run into this when I went to do some language implementation in Go (dumped at [0]; didn't keep up with it just because I didn't have much reason to do it in the first place). I'd prefer ADTs, but I just frowned a bit and used interfaces. Your strong feelings here aren't because this is objectively inconvenient but because you think it's something you shouldn't have to put up with. If there's a factor you're missing—not saying there is—it's that types aren't supposed to tell the whole story in Go and it's fine to have data that's not fully described by a type.

I don't believe in a single "the light" to be seen. I know something you don't (the ability to create your own array DSL gives you none of the advantages of a particular array DSL developed over decades of hard work), you know something I don't. Go's popular because it got stuff right that other languages in the space like Dart and Swift missed.

[0] https://gist.github.com/mlochbaum/a7c0dcd482bd07f39fffc3332f...

[corethree]

> I know something you don't (the ability to create your own array DSL gives you none of the advantages of a particular array DSL developed over decades of hard work)

I don't see how this has anything to do with golang.

>you know something I don't

That go is missing sum types?

> Go's popular because it got stuff right that other languages in the space like Dart and Swift missed.

The only advantage I see are implementation specific and not language specific. Go has a better ecosystem, it's cross platform, it has extremely fast compilation times. The language itself is independent of these factors. You haven't mentioned any specific advantage by golang as a language here which is my main gripe with it as of now. But if you meant the implementation specific stuff than I agree with you, those are big advantages. It's one of the reasons why a language like python hasn't fully taken over... if python had the speed of C then it would likely even replace go.

Because of this I'm going to have to assume you agree with me. Go from a language design viewpoint is fundamentally broken. You clearly still like it, but you also clearly can't articulate specific reasons as to why. I mean this is normal, if you like something for really long and you learn that you've liked something flawed for years you're not going to flip around in seconds.

Anyway I think Go only appears fundamentally broken. There must be someone who knows why Rob Pike made these choices to leave our really fundamental primitives when designing go. I don't see why yet, and even though you're a supporter of go you haven't clearly elucidated why either.

I'm still waiting on the reasoning why Rob decided to leave out sum types and make go routines a first class feature when the concept of green threads are easily created as library sub rountines. Not being snarky here. I think this reasoning exists, we just don't see it yet. Perhaps someone else does?

[bPspGiJT8Y]

I got curious and decided to google around. I din't find anything from Pike specifically, but my overall impression is that the maintainers simply refuse to see significant value in sum types. They do acknowledge the benefits but not their importance. Interestingly, the overwhelming majority of Go users (at least as indicated by this[0] GH issue) do wish for Go to have sum types. My speculation for Pike in particular though is that he's not that important to have significant influence on the evolution of Go.

[0] https://github.com/golang/go/issues/19412

[mseepgood]

> or maybe he just didn't know about it

They knew about it, they considered it, and they decided not to do it. Sometimes it's just that simple. It has been mentioned in the FAQ since day one: https://go.dev/doc/faq#variant_types

[nullc]

JSON numbers are not floats/doubles.