Review needed for my article's draft - The beauty of Go

<p>Can someone quickly help me review my draft (The Beauty of Go) and provide constructive/critical comments for it?</p> <p><a href="https://kanishkdudeja.in/?p=108&amp;shareadraft=baba108_59cbbcb8b061b" rel="nofollow">https://kanishkdudeja.in/?p=108&amp;shareadraft=baba108_59cbbcb8b061b</a></p> <hr/>**评论：**<br/><br/>acroback: <pre><ol> <li><p>thread safety is a misnomer and Go does nothing to help with that. It depends on concurrency fundamentals and knowing your data, which is not Go specific. So, Go does nothing for thread safety as a language.</p></li> <li><p>Go is just fine for concurrency for most of the stuff but IMO a systems language cannot be judged without talking about latency responses and integration with C. Fortunately, Go is good at latency responses as long as you understand limits of Channels.</p> <p>C integration is important because most of the systems out there are in C and Go is not the best when it comes to communicating with C world due to its runtime limitations which is unfortunate.</p></li> </ol> <p>I personally have worked around this issue with ease after understanding limitations and working around it.</p></pre>qu33ksilver: <pre><blockquote> <p>Unlike C, you don’t need to remember to free up pointers or worry about dangling pointers in Go. The garbage collector automatically does this job. This also makes sure that there are no memory leaks</p> </blockquote> <p>Yes, but that doesn&#39;t mean you can play fast and reckless with your resources. Memory leaks can still happen. You still have to close connections and file handles. There should be a note on that.</p></pre>computersmusiclife: <pre><p>Sure. I will do that. Thanks for taking out the time to review :)</p></pre>nasciiboy: <pre><p>good overview of Go features</p></pre>computersmusiclife: <pre><p>Thanks for reviewing :)</p></pre>mrkyu: <pre><p>Great article! I would change in-built to built-in, but then again I&#39;m not sure of the semantic differences. I enjoyed the fact that you linked out to some really great resources. (I.E. Rob Pikes&#39;s talks, avelino/awesome-go, etc) </p> <p>One helpful topic would be when you&#39;re covering the language weaknesses. It would be great if you could include some &#34;industry best practices,&#34; to mitigate these weaknesses. Specifically around dependency management, would be the most helpful for newbies like me. I would also move &#34;target audience,&#34; closer to the top. It gives a clear guideline for who this article is for from the start. </p> <p>I think the addition of you adding &#34;how to get started with go,&#34; is a really great add. The fact that you included companies currently using go is awesome. It helps to give dev&#39;s who are relatively new to go, a good sense of its popularity within the market. </p> <p>Thank you for writing this, it&#39;s a great article.</p> <p>edit: a word</p></pre>eikenberry: <pre><blockquote> <p>Go’s official experiment dep should ideally become the solution to this problem soon. Probably in Go 2 </p> </blockquote> <p>&#34;dep&#34; should be ready long before Go 2. Though you might have just been being facetious.</p></pre>titpetric: <pre><p>&#34;should&#34; is the operative word here, imho I think it&#39;s so low on the priority list that it explains all the community efforts (gvt, glide, gb, etc.) and because of those there&#39;s no real drive to solve this.</p> <p>If to continue with the definition of the RFC lingo: there&#39;s a difference between &#34;should&#34; and &#34;must&#34;.</p></pre>