Good, now we just need the ability to declare function parameters and return values non-nullable (Forbid passing nil into a function, and declare a function will never return nil).

That would get rid of the "panic: runtime error: invalid memory address or nil pointer dereference" errors.

https://wakatime.com/blog/48-go-desperately-needs-nil-safe-t...

I’d kill for union types as well.

… and pattern matching. Maybe just some extensions for `switch`.

… and one of the `try` proposals.

That having been said… I do appreciate that Go has gotten where it is today by being radically simple, and that a lot of extreme care needs to be done to add new features to the language. It’s hard to draw a firm line in the sand. I feel like all of these features would work great together, though; it’d enable Go to do something like `Result` in Rust with few language-level changes.

I even remain somewhat skeptical about generics, but I am hopeful.

> I’d kill for union types as well.

> … and pattern matching. Maybe just some extensions for `switch`.

Go has type switches which are… ok. If it were possible to “close up” interfaces and type switches took that in account (match completeness) you’d be done about done, you would not have the structural / patterned unpacking but that’s probably less of a concern.

the fact that the set of types that can satisfy an interface is open is the source of their power. "closed interfaces" are broadly an antipattern in Go.

> "closed interfaces" are broadly an antipattern in Go.

That is complete nonsense.

The ability to create an open set of types is powerful, so is the ability to create a closed set of types, and they are not exclusive.

But go currently has only one of the two, which significantly limits its expressivity and type safety.

you can make an exported interface with an unexported method in it and voila, nobody else can implement it. That’s just broadly not that useful so it doesn’t come up a lot.

Congratulation on getting within inches of the point yet still completely whiffing. But i guess that’s the blub paradox for you.

lol the arrogance. Hilarious.

there are tools to do this, they’re not widely used because it doesn’t fit Go well. You’re trying too hard to write Go in the style of another language.

If you want an exhaustive type switch that badly, it’s usually a sign that your interface definition is wrong. https://github.com/nishanths/exhaustive

here, have fun. You’re gonna write some tests, make new types to satisfy interfaces for testing, and then wind up with branches for your test paths in your live code, but go for it, I guess. You know everything! I am but a simple blubbite, too dim, too dim to get it.