Thanks /r/golang, I registered a two-character username on Gitlab!

<p>Last time I saw someone saying that he/she is lucky enough to register a three-char username on Gitlab. My current username is 6-char. :\ So I decided to give it a shot.</p> <p>Code:</p> <p><a href="https://gist.github.com/anonymous/a59410ed36c62be04be0a6c1b51e8c0a" rel="nofollow">https://gist.github.com/anonymous/a59410ed36c62be04be0a6c1b51e8c0a</a></p> <hr/>**评论：**<br/><br/>echophant: <pre><p>Cool script! I&#39;m not sure if you&#39;re looking for comments/improvements, but <a href="https://gist.github.com/anonymous/22a76c1d02c3785b0d3989c9d38f0351" rel="nofollow">I tweaked the script here</a>.</p> <p>Some of the changes I made:</p> <ul> <li><strong>Reformatted comments</strong> - Go comments are traditionally on their own lines, complete sentences, and end with a period.</li> <li><strong>Replaced inttoStr with a slice</strong> - Since we don&#39;t use the int index in the map, and it was sequentially indexed, we can use a slice directly and <code>range</code> over that.</li> <li><strong>Error-handling changes</strong> - In Go, one generally handles errors and returns early. Instead of having an indented <code>else</code> block, the code continues at the outermost level. This is easy to read, and we handle errors as they come up.</li> <li><strong>Removed struct tag</strong> - The <code>encoding/json</code> library will do a case-insensitive match of exported struct fields, so we don&#39;t need to add the struct tag in this case.</li> <li><strong>Added rate limiting</strong> - It&#39;s generally considered good practice to not hammer public APIs. They hopefully have their own throttling, but we can use <code>time.Tick</code> as a simple rate limiter.</li> <li><strong>Stream GitLab API response</strong> - We don&#39;t need to <code>ioutil.ReadAll</code> of the GitLab body, we can simply pass our <code>*http.Response.Body</code> to <code>json.NewDecoder</code>. This would likely save us memory for large responses, and removes a step from the process.</li> <li><strong>Changed concurrency mode</strong> - Each GitLab API call still happens in it&#39;s own goroutine, but instead of waiting at the end, we use a <code>sync.WaitGroup</code> to wait for all 1296 routines to finish. We also have a separate goroutine to listen for available names, so that only one goroutine is trying to write to our output file at a time.</li> </ul> <p>When I ran the script, I got <code>Total: 1296 Available: 209</code>, though the GitLab API threw an error or two, so your count might be slightly different :)</p> <p>Side note: I can&#39;t edit the gist, but line 49 should use <code>log.Printf</code> instead of <code>log.Println</code></p></pre>clover113: <pre><p>Wow, that is really good work! By the way, I never expect to see so many available username on Gitlab.:)</p></pre>forfuncsake: <pre><p>Nice enhancements - I&#39;d add a couple more very minor adjustments: </p> <ul> <li>Save a few LOC by using range over availChan</li> <li>Error on line 66 could also include the username we were trying to test</li> <li>Given that we don&#39;t &#34;do anything&#34; when a name is not available, the else case on line 74 might be better suited to an early return, keeping the golden happy path code aligned.</li> </ul> <p>Edit to add: </p> <ul> <li><code>wg.Add(total)</code> before the loops instead of <code>wg.Add(1)</code> 1296 times.</li> </ul></pre>ryankearney: <pre><p>This is more or less how I got a 2 letter .io domain name too a few years back. Scripting is fun.</p></pre>fiisio: <pre><p>You can try to write a github version</p></pre>clover113: <pre><p>Sorry, but Github version seems different. It is not the problem of POST method; It needs a &#34;token&#34; to authenticate. </p></pre>