Hi Christian, Thanks for the quick response!
On Jul 8, 2015, at 12:50 PM, Christian Grothoff <[email protected]> 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 _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
