Compiling a Go program into a native binary for Nintendo Switch

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),
          Object(HashMap),
          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).

Trying not to devlove into an ad hominem, I don't think you're arguing in good faith, You're dismissing my criticisims (which are valid critiques of golang and the ecosystem of it) by hand waving them away.

> I recognize that this does not perfectly map to your mental model, but why is this a major issue?

The phrasing of this implies that it's my fault that go forces me to represent invalid states, not the languages. Here [0] is a 30 line (contrived for brevity) example showing something that is just not possible if you use C++'s std::optional, or Rust's Result types.

> It's a bit like saying "that tire isn't perfect because it can pop, so lets use a metal tire instead". Sure, you fix one issue, but you create others.

Actually I think it's more like saying "A metal band around a wheel is fine, why would we wrap them in rubber, that just causes more issues".

> This is too vague to evaluate. There is a point at which repetition becomes a problem, and there is a point at which repetition is cheaper than having an abstraction. I don't think it can be evaluated in general.

I disagree. Fundamentally the js ecosystem suffers from being too far the opposite (left-pad), and golang swings too far in the repitition direction. Here's some examples of really fundamental things that are missing from the language/libraries, that the response is "just write your own" [1][2][3][4][5]

> If this is meant to be evidence that go is a bad language, I would disagree.

The method of actually interacting with cgo is completely bespoke and novel, and unlike any other FFI system, without any advantages for doing so. It's fair and valid to criticise C++ for it's arcane build system, lack of package manager, lack of abi stability, and name mangling. It's fair to criticise js for it's over reliance on tiny packages, npm and all the extra compile steps it requires for an uncompiled language. It's fair to criticise rust for excruciatingly long build times, therefore it's fair to criticise go for it's half baked slow ffi IMO.

[0] https://gcc.godbolt.org/z/eKWq6rnb7

[1] https://stackoverflow.com/questions/44940822

[2] https://stackoverflow.com/questions/21362950

[3] https://stackoverflow.com/questions/7782411 (no way to iterate through the container itself, only make a copy)

[4] https://stackoverflow.com/questions/12518876

[5] https://stackoverflow.com/questions/19979178

> 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