5 ms·
But the solutions don't offer much over "go get", what would be the point to use them?
by zzzcpan 10y ago
But the solutions don't offer much over "go get", what would be the point to use them?
- the_duke 10y agoI thoroughly disagree. The Golang ecosystem is in an incredibly weak state when you compare it with other modern languages. Major issues: -) Due to the lack of a proper package system, there's also no central pkg repository, which really hurts discoverabilty and growth of the ecosystem a lot. Just compare it to solutions like NPM for node, https://crates.io https://crates.io for Rust, Hackage for Haskell, etc... Github + https://godoc.org/ https://godoc.org/ is not a replacement for a proper package repository. -) Like I mentioned, way, way too many Go packages don't follow a proper release process with versioning and release notes. AT ALL. You often need to mirror repos for your own project, and closely track what upstream projects are doing. git clone + go get for your big projects just doesn't work. This is incredibly problematic when developing big projects. A proper pkg solution should enforce versioning and release best practices.
- jvehent 10y agoGodoc is searchable: https://godoc.org/?q=json+web+token https://godoc.org/?q=json+web+token
- mfer 10y agoHow do you find the main vs the forks of a package? What about useful metadata to help you make a decision? Compare godoc.org projects to https://crates.io/crates/bitflags https://crates.io/crates/bitflags or https://packagist.org/packages/masterminds/html5 https://packagist.org/packages/masterminds/html5. Look at the metadata to help you make a decision. Just the docs for the tip of master are far from what people expect.
- themihai 10y agoYou can see the number of imports and import graph on godoc. I don't see that on crates.io. You can also see if it's a fork on github. What is on crates.io link that is missing on Godoc? More colours? The package author chooses how much documentation is necessary for a given package. Given that html/js is a mess I expect more documentation to figure out how it works. Here is the godoc of a package with more text if that's what you are looking for http://godoc.org/google.golang.org/appengine/datastore http://godoc.org/google.golang.org/appengine/datastore On top of this the documentation is source code so you don't need a bunch of other fils to keep the documentation in sync.
- aleksi 10y agoYou mean http://www.gonuts.io http://www.gonuts.io?
- the_duke 10y agoYes, there are solutions out there, but the very first sentence on gonuts proves my point: "Serving 28 versions of 12 nuts published by 80 registered users." There's just very little adoption for these, and there won't be unless it's official.
- theseoafs 10y agoCan you explain why the lack of a central package repository is an issue? All of the languages I use in my daily work have central package repositories, but I don't use them for discovery, I use google, GitHub, etc., because to feel comfortable using a package I need to answer some meta-questions about the package ("is this package used by a lot of people?", "is it updated frequently?", "are there are a lot of reported issues and do the owners respond to issues diligently?") It seems to me that while I'm on the GitHub page anyway, it's reasonably convenient to just copy-paste the URL in a file so I can pull in the package and use it. I can't imagine just using a package repo for discovering new packages, that would be tantamount to just pulling whatever random code someone wrote that looks like it might solve my problem.
- steveklabnik 10y agoOne small example: someone could delete that github repository, and you'd be hosed. But many centralized systems (like crates.io) do not let you remove packages. The only way that things accidentally break there is if the government gets involved.
- theseoafs 10y agoThat's certainly true -- unrelated to the discovery point I mentioned, but it is true. The different tradeoffs are well-understood at this point IMO.
- themihai 10y agoAs a package user you could use your own git mirroring server or just use a fork. Even simpler just vendor it and you are safe from package removal. On the other hand a central distribution model is more problematic. As package author I want a certain degree of control over my code. If crates.io gets compromissed or is down everyone suffers. If crates.io received a DMCA(happened on npm) my package can be removed. I put some effort into that package so if for some reasons I want to remove it it should be my choice. Why do want to keep it hostage if it's not yours? I though at leat Mozilla learned that distributed is better than centralized. Do you want a place to find all the rust packages? Make a search engine(see godoc.org). Less is more!