[bsaul]

This posts shows two very common issues that programmer have with the GO language when they start using it (that includes me), especially since go is advertised as compiled with the feeling of a dynamic language :

A low-level feeling when manipulating arrays (or slice), and a poor support for generic functions ( that would be math.min in this example).

[jerf]

If it said that explicitly, I'd be fine with it.

But given the last paragraph, I don't think that's the most likely interpretation.

And it's still a terrible way to judge languages without a lot more context. All langauges have gotchas that fit into 3-5 lines. Python's got a pretty decent set: https://www.google.com/search?q=python%20gotchas It's still a good language.

And let me be very clear: I'm not "defending" Go here... I quite like both Python and Go. I've got no trouble saying Python is incrementally easier than Go when it comes to dealing with strings (but both are beat by Perl). (Especially since the incremental advantage comes at a stiff performance price. Sometimes that's fine, sometimes that's not.) I'm specifically saying as computer language polyglot, this metric for measuring languages is terrible. It's a rationalization, not a rational argument.

[bsaul]

I see your point, but after having coded a full (minor) project in Go, i can assure you that those two points alone (cumbersome array data structure and lack of generic code) made me rethink twice about using this language for the common "web service for CRUD to DB" use.

Then i tried to see how did go data access layer libraries look and it finished to convince me not to use it unless performance and memory usage were a crucial matter.