I'd kill for them adding support for structurally typed, non-nullable immutable tuples and records, destructuring, and pattern matching. This would make sharing data across channels much safer and seems like it could be implemented with minimal syntactic changes. I envision something like the following.

    //full-blown tuple support
    var person (string, string) = ("John", "Doe")

    //records are just tuples with named fields, but can use existing struct access syntax.
    var point #{x: int, y: int, z: int} = #{x: 1, y: 2, z: 3}

    //due to structural typing, we can just use a type alias
    type Person = (string, string)
    type Point = #{x: int, y: int, z: int}

    var person Person = ("John", "Doe")
    var point Point = #{x: 1, y: 2, z: 3}

    //or just infer
    person := ("John", "Doe")
    point := #{x: 1, y: 2, z: 3}

    //destructure
    fname, lname := person
    
    //destructure record/tuple
    {x, y, z} := point

    //destructure array or slice (c is always slice)
    [a, b, ...c] := myArray

    //pattern matching on tuple
    switch person {
        case ("John", "Doe"): //do exact match
        case ("John", _): //only match first name
        case (fname, lname): //use new variables
        default: //this is the same as `case _:`
    }

    //pattern matching on record or struct
    switch point {
        case {x, y, 0}: //do stuff with variable match
        case {1, 1, 1}: //do stuff with exact match
        default: //do stuff
    }

    
    //same style of error handling with more flexibility
    switch getPointWithPossibleError(point1, point2) {
        case (_, {type: "error1", msg}): //handle error 1
        case (_, {type: "errorN", msg}): //handle error N
        case ({x, 0, 0}, _): //handle exceptional case
        case ({x, y, z}, _): //handle default case
    }

The Go team is extremely friendly, so I encourage anyone thinking they could improve the language to open a feature request on GitHub: https://github.com/golang/go/issues

I love go but im annoyed they didn't choose angle brackets for the syntax. It's illogical to be annoyed at this, i know, but it feels like being different just for the sake of being different.

> Angle brackets require unbounded parser look-ahead or type information in certain situations

https://groups.google.com/g/golang-nuts/c/7t-Q2vt60J8

The argument seems to be that a,b=c<d,e>g could be misplaced based on whether this is a generic type or a pair of comparisons.

They then go on to say that they needed to revisit the design in the square brackets case to insert the keyword “type” whenever generics were used, which means this example would presumably become c<type d, type e> which resolves the ambiguity.

It seems more likely it was an issue discovered atbut not revisited when the issue was fixed, and now inertia is keeping it as is.

Is it possible to compile my local Go code with generics?

Yes, by building the dev.go2go branch: https://github.com/golang/go/blob/dev.go2go/README.go2go.md