Go's Sweet 16

It has proper enums. Granted, it lacks an enum keyword, which seems to trip up many.

Perhaps what you are actually looking for is sum types? Given that you mentioned Rust, which weirdly[1] uses the enum keyword for sum types, this seems likely. Go does indeed lack that. Sum types are not enums, though.

> sensible arrays & slices, without any magic and awkward syntax

Its arrays and slices are exactly the same as how you would find it in C. So it is true that confuses many coming from languages that wrap them in incredible amounts of magic, but the issue you point to here is actually a lack of magic. Any improvements to help those who are accustomed to magic would require adding magic, not taking it away.

> iterators

Is there something about them that you find lacking? They don't seem really any different than iterators in other languages that I can see, although I'll grant you that the anonymous function pattern is a bit unconventional. It is fine, though.

> result unwrapping shorthands

Go wants to add this, and has been trying to for years, but nobody has explained how to do it sensibly. There are all kinds of surface solutions that get 50% of the way there, but nobody wants to tackle the other 50%. You can't force someone to roll up their sleeves, I guess.

[1] Rust uses enums to generate the sum type tag as an implementation detail, so its not quite as weird as it originally seems, but still rather strange that it would name it based on an effectively hidden implementation detail instead of naming it by what the user is actually trying to accomplish. Most likely it started with proper enums and then realized that sum types would be better instead and never thought to change the keyword to go along with that change.

But then again Swift did the same thing, so who knows? To be fair, its "enums" can degrade to proper enums in order to be compatible with Objective-C, so while not a very good reason, at least you can maybe find some kind of understanding in their thinking in that case. Rust, though...

Maybe by 18, or 21, the maturity finally settles in.

I don’t know if this is the reason but Robert Griesemer, one of the three original guys, comes from a Pascal/Modula background.

So nothing to worry about?

> how do I insert an element in the middle of an array?

Same as in C. If the array allocation is large enough, you can move the right hand side to the next memory location, and then replace the middle value.

Something like:

    replaceWith := 3
    replaceAt := 2
    array := [5]int{1, 2, 4, 5}
    size := 4
    for i := size; i > replaceAt; i-- {
        array[i] = array[i-1]
    }
    array[replaceAt] = replaceWith
    fmt.Println(array) // Output: [1 2 3 4 5]

> The docs on the internet suggest that slices in go are exactly like in Rust, a contiguous sequence of array's elements.

They're exactly like how you'd implement a slice in C:

    struct slice {
        void *ptr;
        size_t len;
        size_t cap;
    };

Which isn't exactly the same as Rust. Technically, a Rust slice looks something like:

    struct slice {
        void *ptr;
        size_t len;
    };

Of course, that does mean operating a bit lower level than some developers are used to. Go favours making expensive operations obvious so that is a tradeoff it is willing to make, but regardless if it were to make it more familiar to developers coming from the land of magic it stands that it would require more magic, not less.

>3) To make matters worse, at work we have a linter that forbids merging a branch if you a) don't do if err != nil for every case b) have >20 for & if/else clauses. This makes you split functions in many pieces, turning your code into enterprise Java.

That is not a problem with Go.