[retrodaredevil]

I like simple languages without bells and whistles but for me, Go has some flaws that I cannot look past.

Specifically the map type. Unlike some Map implementations in Java, maps in Go are not ordered and there is no way to order them unless you want to keep a slice representing the order of the keys. Keys in these maps must be comparable, which means that unlike Java, you can't just implement equals() and hashCode() to make your type comparable. Maps and slices are not comparable, so if you use either in a struct, that struct is no longer comparable. Since map keys must be comparable, you'll have to convert your struct to a comparable type like a string if you want to use it as a key to a map.

You can always look for a third party library for more data structures, but the last time I looked those libraries didn't support generics yet.

Sometimes you'll find a standard library function that takes an interface{} and might panic if you give it a value it doesn't like. This is especially the case for library functions that want to operate on slices. Slices can be generic, but you'll still find many functions that accept interface{}, so you're left with library functions and third party libraries that take any as the type of an argument and expect you to read the documentation so that you don't accidentally pass the wrong type.

interface{}s are comparable sometimes, and if you compare two types that aren't actually comparable, you'll get a panic.

[Cthulhu_]

Maps being unordered is an intentional "feature" to prevent one of these programming adages that every bit of behaviour, every API will become something developers rely on; if a map has to be ordered, you're restricted in what implementations you can use, or forced to keep an array with the element order alongside it, again limiting performance. Most use cases of map do not rely on insertion / iteration order.

[bbatha]

You might want to check in again. Generics have been in go for a couple of years now. There are loads of generic data structure libraries now. The most recent release of go included a way to generic structures with `for range` loops. Which unblocks the ecosystem from writing iterator helper libraries.

[retrodaredevil]

Not sure how I didn't find this before, but https://github.com/zyedidia/generic looks like a decent library.

Although there are some decent libraries out there for this kind of thing, my complaint mostly stems from the fact that a lot of existing code doesn't involve generics yet.

I think I remember skimming an article about for range loops on Hacker News a while back, but again, my main complaint is still that existing code exists in a way that doesn't incorporate all these new features yet.

[bb88]

Not all languages are perfect. I'm leaning towards the ones where the creators at least acknowledge the flaws in the language they've created.