Re: [GNUnet-developers] Why old-school C?

[Ed Baskerville]

Hi Christian,

Thanks for the quick response!

On Jul 8, 2015, at 12:50 PM, Christian Grothoff <address@hidden> wrote:

> Just to cut this short: We have gnunet-java, gnunet-python (admittedly
> not much there yet), some people started gnunet-ruby and gnunet-rust.
> GNUnet is a multi-process system, so each service can be written (or
> re-written) in any language.  You fancy Go or Haskell or OCAML instead,
> go for it.

That all sounds great, but I still worry about the main reference 
implementation continuing in that style. If a killer app emerges to drive 
adoption--say, a social networking app--one implementation will be much more 
widespread than the others, and whatever vulnerabilities are there will be the 
ones that get attacked.

> 3) don't expect C hackers to switch to Haskell, or Java developers to
>   Go, the resulting loss of personal productivity is unlikely to work
>   out in anybody's favor.

To be fair, I wasn't proposing a switch from C per se, but suggesting that 
things could be done, even in C, in a safer way, with opaque data types and 
abstracted-away memory management. I also think that short-term losses in 
programmer productivity can sometimes be worth it in the long run, but I see 
your point.

> So please, go ahead, make it safer (even though I personally think the
> choice of language is not the most critical security issue today)

Would you mind quickly summarizing why we shouldn't worry too much about 
language choice--or, more specifically, raw pointers to structs, manual 
dereferencing, and manual memory allocation? Nicely separated processes?

> Furthermore, if you re-write any existing subsystem in a way that is
> clearly superior, we'll simply swap one binary for another and everybody
> will be happy.  GNUnet is primarily a (large) set of protocols ---
> between peers and between processes, and I don't care too much about
> which (libre) language the components are written in, as long as they
> are written well (and perform reasonably well).

This is a side note, but to get GNUnet to work on non-jailbroken iOS--which 
some people probably don't care about but I think is going to be 
necessary--there needs to be a version that can run in a single process. iOS 
just won't let you do multiple processes unless you're Apple. This might not be 
too hard--just put processes on different threads, and use the same IPC--but 
there are no doubt implications for stability and security. I may end up 
attempting this after I'm better oriented, and would certainly appreciate any 
warnings you have on this front.

> Happy hacking!

Thanks,
Ed