Review my learning experiences with Go

<p>I&#39;ve been working on getting my feet wet with golang and have been positively impressed while doing a couple of implementations. I&#39;ve just recently started to work on an IRC server implementation. I think I&#39;ve come to a point, where the codebase is big enough, but yet still small enough, that someone can can quickly take a grasp at what it&#39;s doing and see where I&#39;m headed with that code style and maybe direct me in a different direction if it&#39;s not working out.</p> <p>Enough of the talk, here&#39;s the project: <a href="https://github.com/tehcyx/girc" rel="nofollow">https://github.com/tehcyx/girc</a></p> <p>Feel free to point out things you&#39;d change and maybe help me out with things like these:</p> <pre><code>call of append copies lock value: server.Room contains sync.Mutex </code></pre> <p>Thanks for your effort!</p> <hr/>**评论：**<br/><br/>dgryski: <pre><p>For the vet issue, read <a href="https://medium.com/golangspec/detect-locks-passed-by-value-in-go-efb4ac9a3f2b" rel="nofollow">https://medium.com/golangspec/detect-locks-passed-by-value-in-go-efb4ac9a3f2b</a></p></pre>tehcyx: <pre><p>While it tells me, that it&#39;s best practice not to do this, it fails to point out a valuable solution for it.</p> <p>I want copies of these structs, that contain the Mutex, but how would I go ahead and design it in a way, that I don&#39;t copy the Mutex? Do I just have global Mutex for this, since the <code>roomList</code> and <code>connectedClientList</code> are supposed to be global anyways?</p> <p>And while the list itself shouldn&#39;t be modifiable, the <code>Room</code> should have a Mutex by itself, so that only one user at a given time can e.g. change the topic. The list of active users in a room doesn&#39;t change, while I loop through it, to notify everyone of someone&#39;s arrival or departure.</p></pre>