Nominate your library to be reviewed + improved at GoSF on March 23

<p>I&#39;m giving a talk at GoSF on March 23 walking through how experienced Gophers reviewed and improved a couple of real open-source libraries, nominated by their creators here in this thread. The reviews will occur in the open and will come in the form of multiple mergeable pull requests to your library in the next 30 days.</p> <p>If you have an open-source Go library and this sounds helpful and fun, then nominate it here. Post a comment with the following info (1-2 sentence answers are fine):</p> <ul> <li>URL to library</li> <li>What problem was the library built to solve? (This is so our review stays in scope.)</li> <li>What parts of the library work well for users? What doesn&#39;t work well?</li> </ul> <p>Other notes:</p> <ul> <li>The projects will be selected among this list by March 9, the reviews will be completed by March 20, and the talk is at GoSF on March 23 at 6:30pm in San Francisco (<a href="https://www.meetup.com/golangsf/events/236855978/">https://www.meetup.com/golangsf/events/236855978/</a>). Video, slides, and a blog post will be available after the event.</li> <li>We&#39;ll be very respectful in our review. Beginners and experts alike are encouraged to nominate their library.</li> <li>Nominations by creators/maintainers only, please.</li> <li>You don&#39;t have to be in SF or be able to attend the event to nominate your library.</li> <li>The ideal library is small or medium in size with an active user community.</li> <li>This is an experiment. If it goes well, I&#39;m sure there will be more in the future.</li> </ul> <hr/>**评论：**<br/><br/>chewxy: <pre><ul> <li><strong>URL</strong>: <a href="https://github.com/chewxy/gorgonia" rel="nofollow">https://github.com/chewxy/gorgonia</a></li> <li><strong>Problem solved</strong>: building deep learning/machine learning programs. It&#39;s main attraction is building a graph of expressions (tailored to machine learning of course, given that programming in general is all about building a graph of expressions), and then executing them in a highly optimized fashion.</li> <li><strong>What works well</strong>: The basic stuff you&#39;d expect.</li> <li><strong>What doesn&#39;t work well</strong>: <ul> <li>performance related - cgo calls for BLAS and CUDA can be optimized a lot more.</li> <li>lack of uniformity in APIs (see for example the <code>Solver</code> type - ideally all <code>Solver</code>s should take the same options - batchSize, eta, etc, but they&#39;re not uniform because each solver was implemented at a different time).</li> <li>lack of equal support for features: the <code>*lispMachine</code> type is lagging behind the <code>*tapeMachine</code> type because I originally designed it as an exploratory tool. But I feel that it should support things like CUDA and CBLAS.</li> <li>lack of ops for image-based machine learning algorithms (things like <code>im2col</code> or <code>convolve</code>)</li> <li>there are some highly questionable design choices, in the exported API.</li> <li>Graphviz file generation is a mess of spaghetti code, and doesn&#39;t take options.</li> <li>high reliance on <code>sync.Pool</code> for performance (indicating of course, the underlying algorithm needs work)</li> <li>Very tightly coupled code - there is some current attempts at separating out the packaging, and I&#39;m personally finding it a challenge</li> </ul></li> <li><strong>Users</strong> : You run Sourcegraph... you can tell me how many users use Gorgonia (not many I suspect)</li> </ul></pre>driusan: <pre><p>is it possible to use without cgo?</p></pre>chewxy: <pre><p>Yep. That&#39;s the default. If you want to use with CUDA, you&#39;d have to pass in a build tag that specifies using CUDA</p></pre>driusan: <pre><p>This seems like a cool idea, I&#39;m not sure why you&#39;re not getting any bites. I&#39;m not in SF, but I&#39;ll submit one of my projects (even though there aren&#39;t many users other than myself): <a href="https://github.com/driusan/dgit" rel="nofollow">https://github.com/driusan/dgit</a> (and if it needs to be a &#34;package&#34;, then the git subpackage of it, which mostly attempts to implement a pure Go implementation of git in a way that closely mimics the command line plumbing commands, as opposed to libraries like go-git that try to mimic libgit2.) I think it&#39;d be a good project for your purposes because the code quality is all over the place. It&#39;s something I started when I was first learning Go, completely abandoned for a year or two, and recently came back to it again because I&#39;m trying to use 9front as my development machine, and I need a git client to do development. </p> <p>Problem: I need a pure Go git client that works on Plan 9 (and potentially any OS which Go supports but the standard C git client doesn&#39;t.)</p> <p>What works well: It mostly works for simple development. It can clone from GitHub, push, add, commit, etc. It&#39;s bootstrapping its own development now.</p> <p>What doesn&#39;t work well: just about everything. There are bugs, and a million sub-commands and options that aren&#39;t implemented. See the status.txt in the repo.</p></pre>vendakka: <pre><p>URL: <a href="https://github.com/surullabs/lint" rel="nofollow">https://github.com/surullabs/lint</a></p> <p>Lint was built to make it easy to run linters as part of go test. This makes it simple to include linters as part of a Dev workflow without any external scripts or extra steps. It also makes it easy to include linting in a continuous build with no extra effort. It can also be used to programmatically run linters. </p> <p>What could be improved:</p> <p>There are some low hanging fruit wrt to parallelizing linter execution. </p> <p>Linters are not vendored. The code to vendor linters exists for a vendored version of gometalinter but not for the others. </p></pre>dimitar_: <pre><p><a href="https://github.com/dimitark/socialauth" rel="nofollow">https://github.com/dimitark/socialauth</a></p> <p>Very small. First Go project.</p></pre>