When I wrote that paragraph, I definitely did not think of "pragmatism" as "doing whatever people wanted them to do". Golang is also not Perl. If you're looking for Perl, Golang will disappoint you.
I'm not sure how you can create a pragmatic language while ignoring the most common complaints about it.
There's this common attitude of "if you want feature X and Go does not have it, Go is not for you." To some extent it's not surprising since there was confusion about what niche Go hit when it first came out. But when there's repeated patterns in critiques of Go coming from very smart people, it's probably worth paying attention rather than saying it just doesn't fall into the language's sense of "pragmatism".
FWIW, I'm a Python programmer who loves Go. Despite all its good stuff, though, we shouldn't remain content with what we have already.
I wrote the comment you're replying to, so I'm probably in the best position to determine what I meant by the word "pragmatic". I didn't mean "implementing whatever feature people complained most about missing".
If there's a debate to have here, it's about what word better captures the point I was trying to make than "pragmatic". But that's an incredibly boring debate, so, I opt out.
I thought the debate was about polymorphism. It's apparently not worth including because...? It's not already in the language spec? Because the people who advocate it are using the wrong tool? Surely there's a better argument than this.
Lack of polymorphism isn't even close to the most common objection to Golang. The most common objection is the lack of generics, which make it tricky to write reusable container libraries.
Golang comes pretty close to flat-out rejecting object orientation. It's only barely more object-friendly than C is. If you're the kind of programmer that wants to model a problem domain or build code with the Smalltalky feel that Gang of Four patterns give Java and C++, you will also hate Golang.
Generics might happen in the future (the more Golang I write, the less excited I am at the prospect), but a richer object model seems very unlikely. If you want to hang your argument on polymorphism rather than generics (I applied the principle of charity and assumed that's what you meant), the argument gets less valid, not more.
Apologies, polymorphism is a loaded term that could mean different things depending on your background. I mean parametric polymorphism, i.e. generics. What makes you unexcited about them?
I surely see the value, but I'm also convinced by the idea that they will complicate the language, and, in practice, after a year or so writing fairly serious Golang programs (I wrote the emulator and debugger backend for Microcorruption in Golang, for instance, along with a pretty complicated web fuzzer) I haven't missed them.
Or "likelihood that program runs correctly if compiles correctly X" is too low, or "ability to write concurrent code in straight-line fashion rather than with callbacks X" is "too low".
When single threaded top-down Python is too slow for a particular task, of late I find it easier/cleaner/faster to use Go routines than multiprocessing / threading in Python, because of the way concurrency was designed in Go, but added to Python.
> "ability to write concurrent code in straight-line fashion rather than with callbacks X"
