[cjslep]

From the article:

> Go isn’t perfect for every task. [...] Ultimately, it is up to you and your team to decide the best language and tools with which to build your application. While making that decision, I hope that you will take a moment to weigh the trade-offs that come with your choices.

It's a tradeoff based on your real, hard needs. If you decide that only having Array<T> and Map<T> is a deal breaker, and the complexity of creating a tool to autogenerate the go code for a large number of SinglyLinkedList<T>/DoublyLinkedList<T>/CircularLinkedList<T>/etc... outweighs the uses of Go, then don't use Go.

If you are fine writing a quick dirty code generator that can look for some <T>-like syntax and do simple replacement, or only really need Array<T> and Map<T>, then consider Go.

It's not like the language is forcing you to use it against your will.

[xg15]

> If you decide that only having Array<T> and Map<T> is a deal breaker, and the complexity of creating a tool to autogenerate the go code for a large number of SinglyLinkedList<T>/DoublyLinkedList<T>/CircularLinkedList<T>/etc... outweighs the uses of Go, then don't use Go.

With all due respect, but how is having to build a custom code-generator first, before you can write your actual program not accidental complexity?

[cjslep]

I wasn't claiming it isn't accidental complexity. Just pointing out the author essentially says to weigh the decision appropriately.

Looking at the sibling comment about "go generate" by buro9, it looks like a custom code-generator won't be needed either.

EDIT: Added buro9, and emphasis

[account_306]

Not yet, anyway.