Is using reflect "idiomatic Go"?

<p>If not how come everyone uses it? Does it affect performance or create bugs? I haven&#39;t seen any consensus on the use of reflect.</p> <p>Lately I&#39;ve been trying to deal with database querying without using reflect, but I&#39;m not sure it&#39;s worth the effort since a huge amount of popular packages use reflect extensively.</p> <p>Then even if my db package doesn&#39;t use reflect, it&#39;s all for nought as routers, graphql, etc all use reflect. </p> <hr/>**评论：**<br/><br/>mixedCase_: <pre><p>Reflection is a necessary evil that you should avoid whenever you can, the label idiomatic/unidiomatic is complicated, because it&#39;s not what you want to do, but sometimes it&#39;s what you must and that&#39;s why the language includes the reflection package. To quote one of the &#34;Go Proverbs&#34; Rob came up with:</p> <blockquote> <p>Clear is better than clever.</p> <p>Reflection is never clear.</p> </blockquote></pre>ultra_brite: <pre><p>Using reflection means trading compile time safety for runtime percs. You also might get a performance hit. At the end of the day however people use reflection in Go because </p> <p>1/ Go reflection is actually quite powerful</p> <p>2/ Go type system is way too basic and limited</p> <p>IMHO reflection is totally acceptable under 2 conditions :</p> <ul> <li><p>a operation using reflection should never panic or at least have an alternative API that doesn&#39;t panic </p></li> <li><p>a operation using reflection should yield an error if needed</p></li> </ul> <p>So basically using Go reflection turns Go into a dynamic language. While, as previously said, using reflection results in a performance hit, Go is usually fast enough so that Go + reflection is faster than any dynamic language out there. </p> <p>Is it idiomatic ? Go std lib is full of reflection. Reflection could have been avoided if Go had a better type system, so to me it&#39;s a bit of a cop-out from Go designers. I was using Vala the other day to write a Gtk+ GUI, Vala has very little reflection capabilities but that&#39;s not a problem since it has extensive support for things like generics, contracts, ... </p> <p>In Go today one can even create adhoc types, from scratch at runtime, through reflection , that&#39;s crazy. </p></pre>darkmagician2: <pre><p>The official Go blog says “It&#39;s a powerful tool that should be used with care and avoided unless strictly necessary.&#34; <a href="https://blog.golang.org/laws-of-reflection" rel="nofollow">https://blog.golang.org/laws-of-reflection</a></p></pre>danredux: <pre><p>Reflect is type-safe, so yes, use it.</p> <p>Just remember that it loses a lot of valuable type annotating abilities, which can make packages harder to use. They are also slower.</p> <p>The best thing to use is a concrete type. If that doesn&#39;t suffice, use interfaces. If that still doesn&#39;t suffice, use the blank interface and reflect on it.</p></pre>itsmontoya: <pre><p>To add one point to your comment. Before reflection I would also do a switch type assertion for known and/or common types.</p> <p>Essentially, use reflection after every other method has been exhausted.</p></pre>xiegeo: <pre><p>If your database package have to handle any type, then use reflect. If your package only handle specific types, then don&#39;t use reflect, or at lease hide it form function definitions even if underling libraries use reflect.</p> <p>tl;dr: If you don&#39;t have to use reflect, don&#39;t use it. If you have to use reflect, then use it.</p></pre>