Why multiple implementations in different languages?

From @knocte on Thu Mar 03 2016 03:03:25 GMT+0000 (UTC)

I see there are multiple implementations for IPFS: Go, JS, and Python.

I can understand why you would want to have a JS implementation, so that it runs inside the browser (no need to install) and benefits from WebRTC’s P2P capabilities.

However, what’s the point of having a Python implementation? It seems also that the reference implementation in Go will always be more complete than the alternatives. Isn’t it too much overhead? Also, maybe using GopherJS (https://github.com/gopherjs/gopherjs) for the in-browser version of IPFS helps the team finish it earlier, and allows not having to maintain many implementations at once.

Thanks


Copied from original issue: https://github.com/ipfs/faq/issues/97

From @RichardLitt on Thu Mar 10 2016 18:56:17 GMT+0000 (UTC)

This is a good question.

Multiple implementations of a spec ensure redundancy. They also help to isolate and discover bugs, which may have otherwise not have been noticed due to the lack of a reference point.

@diasdavid can talk more about the uses of js-ipfs. As far as I know, the Python implementation hasn’t yet advanced very far.

From @diasdavid on Thu Mar 10 2016 19:19:20 GMT+0000 (UTC)

Our current focus is the go and js implementations, however it is important to understand that IPFS is a protocol, not a library, and so, like any other protocol, it will eventually see an implementation in every other language where there is a will to use it.

We could in fact expose an API, which we do, and create clients in other languages, which we have done in js, swift, java, python and go, that developers can use to interact with IPFS directly, however, having a complete implementation brings several benefits when it comes to hackability and portability. Plus it enables us to do fancy things some environments supports, such as you described, WebRTC in the browser.

It seems also that the reference implementation in Go will always be more complete than the alternatives

That situation will be eventually be stabilised :slight_smile:

Hope that this answer was helpful

From @knocte on Fri Mar 11 2016 02:21:26 GMT+0000 (UTC)

Ok makes sense.

However, let me give my 2 cents: I think IPFS is still in the adoption phase. And to help its adoption, it has to support the best features as soon as possible. I consider WebRTC a fundamental use case that would improve adoption of IPFS by orders of magnitude. So, I think the JS implementation should use GopherJS (maybe only temporarily?) to get there as soon as possible.

From @erm3nda on Sat Apr 02 2016 02:53:46 GMT+0000 (UTC)

One thing related, is that if you publish implementations in many languages, you could hit some good developers that are good just in one language.