[gameswithgo]

I actually like Go's simplicity a lot, it was very easy for me to learn and very easy to programming with it because of that. But I agree strongly with some of your points. = vs := specifically feels like a plain mistake, and even against Go philosophy of having just 1 way to do things.

I think any new language should be designed around options instead of nils. F#, Rust, Zig show different ways to do this, and often any performance penalty can be compiled away.

if/switch being expressions is a simple and helpful idea, languages should allow this.

using map/filter/reduce as the idiomatic way to do things I am less sure about. This can come in handy but also would add a lot of complexity to Go, and in most languages these have a performance penalty.

its important to remember that not all programmers are interested in languages, they just want to get their project done. So being able to hop into a code base and have low cognitive overhead, because there are no mysterious features they have to learn, having quick compile times, and explicit semantics can be really helpful there. That can save you more time than typing less because of generics and meta programming sometimes.

[lostcolony]

'and in most languages these have a performance penalty' - pretty sure this is due to either bad implementation or because of additional guarantees they provide. Because fundamentally these constructs can be rewritten to be loops by the compiler, except where you're wanting to violate the guarantees they enforce (i.e., maybe you want to mutate every item in the array, rather than treating it as immutable; these won't do that). For those few situations you want to violate those guarantees, you wouldn't reach for these higher order functions. There's not really any reason not to include them except for language design ethos.