IPFS Implementation - C++, Any Interest in a C++ Protocol Implementation?

[kevina]

Is there any interest in a C++ protocol implementation (not just an API client library) either now, or at some point in the future?

I image that if you want to eventually get IPFS into the O.S. you will likely need a pure C implementation (at least for Linux). A C++ implementation might be a good starting point.

If you want to get a protocol implementation into the browsers a C++ implementation might help. It might also help with mobile.

The C++ implementation might be faster than the reference Go implementation.

Since I am just getting up to speed in IPFS I am mainly interested the core developers opinion on this matter.

[whyrusleeping]

I would be interested in having this. The starting point for any new ipfs implementation is writing an implementation of libp2p in that language. Even if we end up deciding we don't really want a full implementation of ipfs in C++, having libp2p will be awesome for the project.

[klartext]

If an implementation in C seems to be the way to go, why writing in C++ first instead of C?

... if other implementation languages would be of interest, I would propose OCaml :-)

Looking at the go-libp2p-lib, the ipfs-network-spec-link yields a 404-error.
Hmhhh, I would guess thats the most important document though....

[whyrusleeping]

re the broken link, sorry about that. It looks like someone renamed things over in the specs repo.

Here is the correct link: https://github.com/ipfs/specs/tree/master/libp2p (I'll also update over in the libp2p readme)

[klartext]

...is there also a one-document (pdf?)-version?

[whyrusleeping]

nope, parts of it are still somewhat in progress so we havent yet compiled it all together.

[kevina]

@klartext I have no idea if an C implementation is the way to go. At his point I am just trying to get the feel for what the core developers are thinking in terms of long term plans.

A C++ implementation will be easier to write (at least for me). As I see it, is is unlikely that the entire protocol belongs in the (Linux) kernel; the parts that need to be in the kernel can likely easily be rewritten in C once you have C++ code to base it from.

[lidel]

I don't think you should think about C as "something that is useful only around kernel development".
It is useful in user land too, for multiple reasons. Short opinion below (skip if not interested) :-)

From my experience, when writing systems code such as IPFS,
you may get a bigger bang for the buck with C:

1. It is more portable. C++ compilers exist only for the most popular platforms, while C compilers exist for just everything, even the most exotic hardware.
2. Note that most other languages out there have natural bindings to C (Python, Lua, Go and others support it out-of-the-box). I've met with an opinion that C++ is a huge pain to interface with, especially at the binary level.
3. C++ complexity makes collaboration difficult (a bigger problem than it seems, especially in open source):

• When two programmers tell you "I can code C++", they might both know 20% of the language, however a different 20%, so they would not be compatible with each other.
• C APIs are more alike and easy to grasp. C++ libraries are often like they come from separate planets (compare Boost and Qt).

In short C++ would be "just another implementation" (which is still nice to have), but C implementation could improve IPFS portability by a lot.

[whyrusleeping]

I'm quite familiar with C and would be amenable to working on such a project. Anything done in C++ is going to be either 'C with classes' or something I don't understand very well.

Also worth noting is compile times, theyre one the reasons I love go. C's compile times are pretty good if you write your makefiles correctly, but C++ compile times leave plenty of room for office chair swordfighting

[montagsoup]

I would love to see a C implementation. It would really open up development in certain areas. One use case I thought of a while back was a game with resources hosted on IPFS (this gets rid problem of effectively hosting and downloading some 25 GiB MMO). A lot of games are written in C/C++ so Go wouldn't be the best option for them.
As for whether C or C++, I think plain C would be better. Allows for a wider audience (both C and C++ instead of just C++).

[kevina]

@lidel it is very easy to create a C API for a C++ program and bind to that. (In fact in one of my projects (Aspell) I only export a C API to avoid many of the problems with a C++ API.) Linking pure C code with a C++ library on most system does not create a problem as long as shared libraries are used. For this reason I also believe a C++ implementation, while not as useful as a C one, will be more useful than "just another implementation" as it will create code than can be linked to from any application on most platforms.

@whyrusleeping in my experience C++ compiler times are not that big of a concern, especially on small to medium projects.

I am certainly capable of writing something in pure C. However, I can probably create a C++ implementation in a lot less time then I could A C one. I will also be far more confident the C++ program is free from memory errors than I would if I had to write a pure C one.

[Kubuxu]

@kevina it is quite easy to use C API in C++ program but it doesn't make a lot of sense then. C API won't use smart pointers, collections and so on.

Also most people are not familiar with new C++ some of them even dislike how bloaty it has become.

IPFS isn't small project (170k LOC with dependencies), and it will grow as time progresses, so compile times are concern.

There are ways to solve memory allocation problems in pure C, one of those ways is to use exclusively custom memory allocation method. This is what cjdns does and it really works. Development time in C might be longer at first but when codebase establishes it is much better than C++, error hinting works much better in C (ever made error in template in C++ ?) build times are shorter which is really important for debugging and basic OO coding is possible, again approach taken by cjdns, down- and safe up-casting with runtime check for find possible errors.

@montagsoup go can be linked with C/C++, it requires writing bindings and using gogcc but is viable.

[montagsoup]

@Kubuxu Of course go can be linked to C. Tons of stuff can, and I think that's another good point in the favor of a C implementation. Not only would it open up C development, it would open up development for any language that can link to C functions.

I'd be willing to help with a C implementation as much as I can if that's a direction people start deciding they want to go.

[xsnk]

How about Rust?

On Wed, Mar 23, 2016 at 2:41 AM, montagsoup notifications@github.com
wrote:

@Kubuxu https://github.com/Kubuxu Of course go can be linked to C. Tons
of stuff can, and I think that's another good point in the favor of a C
implementation. Not only would it open up C development, it would open up
development for any language that can link to C functions.

I'd be willing to help with a C implementation as much as I can if that's
a direction people start deciding they want to go.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/ipfs/ipfs/issues/164#issuecomment-200030246

[notabeatle]

I was surprised to find that the core of the reference IPFS implementation was not written in C. Most projects of this sort seem to go that way so they get Python/Ruby/Rust/PHP/Go/et c libraries—not to mention plugins to or modules for other major projects—practically for free and so, as infrastructure on which other projects may depend, they don't set the performance ceiling for such dependent projects any lower than absolutely necessary. At first glance I figured Go was just wrapping a C lib to act as the command line interface to it. That this is not the case remains my greatest concern for the long-term health and prosperity of this project, FWIW.

[whyrusleeping]

I used to work on distributed systems in C, now I work on distributed systems in Go and I'm much happier.