Hacker News Reader

Comment by iand | Hacker News Reader

Because Go uses URLs for package names its easy to build tools like godoc.org that automatically aggregate packages from the web.

View on HN

It's a good start but it needs many more features to be considered usable. For example, I just did a search for "redis" and about 30 libs came up. Half of them don't even have a description.

How can I know which one to pick at a glance? Asking me to evaluate and profile 30 different libs for just a single task is unreasonable.

Also this page isn't even on Google's first page for when you search for something. I didn't even know it existed until you mentioned it.

How do you handle that with any other language? There is no shortage of redis libs for any language.

If we look at CPAN http://search.cpan.org/search?query=redis&mode=all , there are a few things right in the search results. We have version numbers, release dates, and a review score. All of those give you a chance at finding a half decent library. The first result was updated a week or 2 ago and has 4 significant digits in the version number. None of it's a guarantee but it's a place to get started.

The review score thing is nice, is there anything like that in packaging systems for other languages?

Usually I just check the commit activity on github if I want to see which Go libraries are actively developed.

It doesn't seem to be a place to get started for Go though. I just did a search for "golang redis" and it showed me a single perl redis lib?

I like the idea of the reviews and ratings though. Normally I would put almost no value in a rating system but we need to somehow separate the good from the bad without having to dive in and look at and profile code from 20 diff libs on a daily basis.

CPAN is the repository for Perl modules, not Go

With Node I would use a combination of npm's site which is their package manager which ranks libs and has a wealth of info for each package and github.

When you publish an npm module it gets put on their site automatically, then there's a lot of javascript scraping sites that watch npm's site. Before you know it your module has a decent amount of coverage which in return makes it much easier to find as someone who is searching for modules.

I also never had a problem finding a good lib in Node because there's a few stand out Node devs who are insanely productive and produce extremely high quality libs on a regular basis.

With Go it feels like there's 3 or 4 lib searching sites but all of them are really flawed. Then on top of that Go code is hosted on a bunch of different sites.

Top Google results are also not very good. In that Redis search example I searched for "golang redis lib" and the highest rank result was for some lib with almost no traction and had a questionable API.

Having too many possible packages to use is a nicer problem to have than having too few.

godoc.org is an interesting service because its package list is produced as a by-product of people using it to read package documentation.

Reply on news.ycombinator.com