Maybe your time would be better spent contributing to the existing list rather than making a new one? It's very long at this point and categorized very nicely.
At first, I took the title's adjective of "awesome" literally and assumed the author's list would be more opinionated as to why those libraries were awesome based on technical merits in comparison to the not-awesome ones. The go-wiki doesn't look to be opinionated so there could have been an opportunity to differentiate his list with battle-tested advice. (Maybe we've been spoiled by aphyr.com's comprehensive reviews of distributed software.)
Alas, I looked a little closer and it looks like the author used "awesome" because it followed in the footsteps of "awesome-python" which itself followed "awesome-php".
Therefore, the author's usage of "awesome" is simply a homage and not an adjective of significant semantics. (Unless the word "awesome" is constrained to mean "the libraries exist" which is amazing because Golang is only 4 years old. Imo, this is too low of a bar to signify as "awesome.")
Moreover the list contains some really outdated projects for some reason.
For example the database drivers section [1]: 3 out of 5 projects are abandoned, while current projects (listed in the official Go community wiki [2]) are missing.
I can't stand these laundry list lists that, as you say, seem to always include dead projects and are littered with incomplete, unusable or otherwise poor inclusions.
This is an area where quality defeats quantity by a particularly large margin.
Not sure if it's funny or sad, good or bad, that the bar for editing a wiki is higher than contributing to a git repo. Wiki: the no-longer-quite-so-quick-web. I do agree that requiring people to send an email shouldn't be considered "difficult", though.
Contributing to awesome-go is more expensive than just having a git repo: you need a github account, which means having to click some buttons, wait for the confirmation, fork remotely, get a clone locally, add content, push, send a pull-request, ...
Fair enough, but the (probably valid) assumption is that most developers already have a github account (much like most people have an email account) -- and you can then make all your changes without waiting for approval. True, your pull-request can still be refused, but even so you still have the product of your work sitting in your repo, and you can share it with others.
I'm not really a great fan of github, but it's hard to deny that it is one easy way to facilitate and mediate contributions.
Also, the permission request to edit the wiki is a one time request. Once you have permission, you are free to edit the project page or any other page on the community wiki.
There's room for improvement in a lot of the packages out there, and I'm still surprised by what feels like obvious omissions.
An example of how even a core package could do with improving: "image" doesn't support all forms of progressive and/or interlaced PNG, any version of animated PNG, or WebP. The lack of progressive PNG means that you can't quite rely on it for user-uploaded images, and image/webp seems to be getting more traction and handling those appears to be growing in importance. Without these things, the other packages that rely on "image" to provide image processing can only be relied upon to work for JPG and GIF.
An example of an omission I found myself filling recently, a HTML sanitizer. I wanted something like the OWASP Java HTML sanitizer https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Pr... , but could only find some very simplistic sanitizers packages (little to no ability to define the policy, simplistic URL checking, etc). I ended up writing my own package to help fill the gap https://github.com/microcosm-cc/bluemonday
You can tell I'm dealing with user generated/supplied content. Each domain still feels almost there (in having a toolbox of packages that do everything you need and are rock solid), but just shy of being there today.
Full read/write access to a directory via LDAP. I was about to start a microservice where I work using Go, but had to use Java. Bummer...
EDIT: a pure Go-based LDAP library is what I meant. I know there's a couple on GitHub but they seem to be abandoned. Plus, there's another one providing bindings to the OpenLDAP libraries.
The best approach to that would be interacting with and leveraging existing, very well proven and optimized image processing libraries. I can see some bindings for things like ImageMagick out there.
What are your requirements? I'm one of the owners of the GoConvey project and I'm happy to answer any of your questions about that project. Ginkgo and Goblin are great choices as well.
Could you please explain this further? I'm still learning Go but I haven't encountered anything in the philosophy of Go that (to me) would suggest that BDD is "not in the spirit of Go programming".
I wish it was more heavily curated so a beginner could have a better defined starting path - my experience with go over the last week has mostly been googling libraries to get pros/cons/gauge popularity.
I wish it was dynamic [1]. So it could cater to everyone.
If you're a beginner and just want to see the top 10 most high quality, popular Go packages, you'd move a slider nearly all the way to the left until only top 10 packages remain.
On the other hand, if you have an obscure need (say, generate random First Names, Last Names, ZIP codes, etc.) and you're willing to look through as many packages as possible, you'd adjust that slider all the way to the right until all included Go packages are listed, and hopefully find https://github.com/Pallinder/go-randomdata#go-randomdata under Awesome Go -> Testing -> Random Data Generation or some other sub-sub-sub-topic.
Still looking for a PhantomJS-like tool in Go. Really hope that'll happen some day. Embedding a browser engine is not easy mind you, but one can dream.
I will try to play with it as soon as I can. I was wondering, I didn't find any method to render a given as a PNG or JPG, is it currently supported? This is our main use for PhantomJS as it is. And thanks again for the hard work.
https://code.google.com/p/go-wiki/wiki/Projects