Why two code bases?

[ipfs]

Why two code bases?

[achingbrain]

What we want to encourage is multiple implementations of IPFS in multiple languages targeting specific use-cases.

Having a modular, composable stack allows developers to pick and choose the components they want which enables new and interesting implementations like Elastic IPFS (built on JS). Kubo targets different use cases and is not flexible like this so it's not a great fit.

It's also important to note that WASM is not a magic bullet, compiling go code to WASM typically results in a large binary which isn't great for browser users and for JS developers in general it's a completely black box which harms their ability to debug problems and otherwise be productive. There's also no guarantee of performance since you'll be copying lots of data in and out of the runtime.

There are also about 7x the number of JS vs Go developers in the world - it's important to meet them where they are. Saying "just use the go version" effectively excludes them from contributing to the IPFS projects and fails to leverage their massive amount of collective experience in deploying browser and Node.js apps at scale.

[unicomp21]

What about the overhead of maintaining the same implementation in multiple languages? Doesn't experience tell us this will result in some sort of "synchronization hell" between code bases? At a minimum, would it make sense to "generate" the multiple language implementations in a way similar to protocol buffers? Maybe look at something like Haxe? Developer's could then "learn" what's going on in the language of their choice? From here they could make the jump to the Haxe implementation? Which then generates all the other implementations? Apologies for being a "stick in the mud", but feels like I've seen this argument play out multiple times before, never seems to end well? Lots of pain?

Or maybe we should pick a language, like javascript, and say this will be the core implementation? And then use something like grpc stubs to wrap that implementation? And make it usable from other languages?

[achingbrain]

We're not attempting to maintain feature parity between the different implementations at the API level. For example there are lots of Kubo APIs we don't want to carry forward, like the object API and specialised APIs like bootstrap, most of the config ones, etc.

Implementations should be compatible on the wire though, that's incredibly important, but each implementation should have the freedom to innovate at the API level as they see fit.