3 ms·
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
by cjslep 12y ago
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.
- account_306 12y agoNot yet, anyway.
- xg15 12y ago> 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 12y agoI 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