Hacker News Reader

Comment by chrissnell | Hacker News Reader

I went to look at their Go implementation but the libraries are each split into separate Github repos (super annoying) and some of those appear to be non-public/404. Very strange.

View on HN

> (super annoying)

Also found it very annoying using it. Coupled with the multi-whatever repos, that they make backwards incompatible changes, and they use IPFS paths in some of their imports (iirc) made for a non-welcoming library experience.

> (super annoying)

Why would anyone store different laguage implementations in the same Git repo?

Repo should be organized around project, not language/frameworks. It’s perfectly normal to have library +Python client + Go client in same repo.

Most of the time, I have a repo be an individual unit of testing. I.e. if the python client is broken, does that mean that the go client is broken as well? A large part of this is because its much easier to support testing multi-repos than mono-repos. Multi repos are generally easier to test because you run the entire suite of tests on every pull request whereas in a mono-repo you have to figure out which tests need to be run. All this isnt to say that its impossible (or not beneficial), but that its easier to have multiple repos with the current testing infrastructure (specifically looking at Jenkins). Another difficulty with mono-repos is merging code when something is broken, how do you know whether you should merge or wait for the bug to be fixed?

I can't think of any library for which this is the case, could you give some examples?

https://github.com/google/flatbuffers

LLVM has python, go, ocaml and c bindings all in the same repository https://github.com/llvm-mirror/llvm/tree/master/bindings (the c bindings live somewhere else)

In this case, the project (at least from the Go standpoint) is broken into multiple sub-projects, each within their own repo. In Go Land, you would more typically see each component library put in its own subdirectories off of the main repo. The main repo could contain libraries for multiple languages or just one, but the subcomponents would be organized as subdirectories, not separate repos.

Is it? The Google repo posted by 'orangea is maybe the first one I've seen.

I mean, let's flip it around: when I need a lib for language X, why would I want to download it also for languages V, Y, and Z (+ all language-specific cruft)? Especially in this day and age, when dependency management in project involves build systems pulling repos automatically?

Or, put another way, library is one project. Python wrapper/client is a different project. Go wrapper/client is yet another project. Etc.

Reply on news.ycombinator.com