[nicoburns]

> I also think there is a question of what the cost, in terms of developer cognitive load, would be of adding more advanced modeling features to go.

That's the thing about Sum Types. They're not really an advanced feature at all: they map to an extremely intuitive human concept: "or". They reduce cognitive load. That's the advantage of having them. In fact, I suspect that a lot of the reason that dynamic languages are considered simpler is because every variable is essentially one big sum type. Trying to represent "or data types" without sum types requires you to use interfaces which are a much more advanced language feature, and are very awkward for the use case of a finite number of known cases.

You could have a perfectly functional language with only logical AND (&&) and logical negation (!) and no logical OR (||). It wouldn't cause any practical issues. But you wouldn't: it would be incredibly awkward. Likewise there should be a datatype for OR (sum types) as well as AND (structs/classes).

[5e92cb50239222b]

This comment pretty much sums up the idea of Go — it's a perfect language for those who haven't looked into anything else that's been available for the past fifty years. If you think that sum types is an "advanced feature" that puts additional "cognitive overhead", it may be perfect for you. I think iota puts much more overhead and adds a need to have oversight where there should be none. If your idea of less cognitive overhead if doing compiler's work for it, well, good for you. There are some exceptions among talented and well-educated developers who seem like it, I know, but those seem to be exceptions.

[maccard]

> There are some exceptions among talented and well-educated developers who seem like it, I know, but those seem to be exceptions.

I have to disagree with this (but agree with the rest of your post). The issues with go are there, but it's still a robust language with great tooling, a solid underlying ecosystem, and is actively improving. It performs pretty well, and idiomatic go is mostly transferable across projects (as opposed to say c++ where you have to pick your favourite style guide). I think it's a great tool for developers, even given its shortcomings

[philosopher1234]

I know Haskell, rust and lisp, so no, I have looked into and used these technologies in earnest. Taking the cost of complication for granted is naive.

[nicoburns]

I question the notion that sum types add complication. I would suggest that if teaching complete beginners it would be just as easy to teach them sum types as it is to teach them product types (structs/classes). A bunch of languages have classes with inheritance. Now that's complicated! But sum types? I just don't buy it.

[MathCodeLove]

Curious, could you elaborate how a dynamic languages variables are essentially sum types? Im not very familiar with types as a whole, though I've been doing some exploration in TS and Rust over the post few weeks

[nicoburns]

So a Sum Type is a type that can be one of many variants. In Rust this could be something like

     enum CustomType {
          String(String),
          Number(f64),
     }

(note: naming of String and Number is arbitrary here)

Where a variable of type CustomType can be either CustomType::String (in which case it contains a string) or CustomType::Number (in which case it contains a number (specifically a 64bit float)).

In typescript this same type would be:

     type CustomType = string | number;

A feature of sum types (in contrast to C/C++ "unions" which are an otherwise similar concept) is that they store which variant a current variable is using. So in Rust you can do:

    let foo_or_bar = CustomType::Bar(1);
    match foo_or_bar {
        CustomType::String(string) => { /* foo_or_bar is String */ },
        CustomType::Number(number) => { /* foo_or_bar is Number */ },
    }

And in TypeScript (and JavaScript!) you can do:

    let fooOrBar = 1;
    switch(typeof fooOrBar) {
        case "number":
             // fooOrBar is a number
             break;
        case "string":
             // fooOrBar is a string
             break;

Now notice that a JavaScript variable (or a variable of type `any` in typescript) is essentially the same as this except there are more options. If you were to model it in Rust you might have something like:

     enum JSValue {
          Null,
          Undefined,
          Boolean(bool),
          Number(f64),
          String(String),
          Array(Vec<JSValue>),
          Object(HashMap<String, JSValue>),
          Function(fn),
     }

With perhaps some more types to handle variants to handle less common types like big numbers, typed arrays, etc. And in JavaScript this is just the default type that applies to all variables! And as it applies to all variables you don't have to specify that a variable is of type JSValue, you just specify the inner type to be 7 or false or null or "foo" or whatever and it chooses the correct variant for you. But internally the JS engine is keeping track of what type your variable is, and it allows you to query it at runtime (although it may not be as simple as typeof).

[MathCodeLove]

Wow awesome explanation, that's so cool, thank you!!