zlacker

My main complaints about Go are not that it needs more obscure syntax. The biggest problem with Go is basically that the core of the language's syntax is special, and only accessible to the compiler. This goes hand in hand with the language not offering generics out of the gate. This means that things like slices, maps, channels, etc. are all special. You cannot implement anything similar that uses the same syntax (even now that generics exist).

This lack of flexibility means that it's impossible to experiment with replacements for built-ins, and the lack of generics out of the gate meant so many things were simply impossible (like useful iterators).

Compare this to Rust, where almost everything like this is just a trait. If you want to offer a map replacement, you just implement the Index and IndexMut traits.

Overall, I don't think Perl is the best language design. It has some interesting ideas. Go is _also_ not the best language design. Is Rust the _best_? No, but it's better than both Perl and Go, IMO.

>>autarc+(OP)
Agreed. It's interesting that the design decisions that make Perl and Go problematic are pretty much at opposites. Both are extremists, in a way.

>>autarc+(OP)
> special

Many of us see that as an important feature, and a smaller set of people aren't too happy with the generics introduction for example. Or the recent iterators stuff they have added.

It makes codebases touched by a lot of people an absolute breeze to understand. There's no clever generic data structure/soup of traits/clever conditional types I have to understand from scratch. Everything is the same old boring maps and slices and for loops, nested sometimes. And functions mostly always return 2 values. There is no map/filter/anything. The name of function usually betrays the types. "getUserPreferencesBatch" is most likely a `func(userIDs []UserID) map[UserID]Preferences, error`. There's <1% chance it is anything else. People also tend to avoid relatively complicated datastructures like trees unless they are really really necessary. So you get boring, completely predictable, 70% optimal code.

Even when discussing implementation, people think in simple terms which leads to really simple implementations in the end across all team members. It basically makes drumming KISS into everyone really easy.

Now some people go all clean code or make functional wrappers and such, and that destroys all that's good in go.

>>autarc+(OP)
But I don't want to read your cute custom hashmap code. Go really shot for the stars with its primary design goal of uniformity. The hashmap you're using is the same one I'm using, is the same one any random Go repo on Github I open uses. The value of this is immense—I instantly feel right at home, I know the exact semantics you're using—we're speaking the same language.

To wit, I would argue that Go didn't go far enough in restricting the user and certainly did not pick the right features to include. I don't think it's clear at all that had go shipped with sum types—enabling better error handling—and iterators, more built in generic data structures, and higher level abstractions around its concurrency, but no generics at all, that we wouldn't end up with a far better language. A more restricted one, with even less room for anything custom, but a better one.