3 ms·

> Most users are going to do this via FFI The C interface is the first step. I may consider C++ and OCaml bindings in the future. Still, point taken: calling

> Most users are going to do this via FFI The C interface is the first step. I may consider C++ and OCaml bindings in the future. Still, point taken: calling C from other languages is always a bit of a pain. > libsodium is not anywhere near the size where static analyses become impractical -- do you have any evidence that would support that? It's not much, but the TweetNaCl papers indicate that its size made it possible to automatically prove the absence of a couple classes of bugs with an algorithm prone to combinatorial explosion. Even being twice as big could have been too much for those.

lvh 10y ago
I'm not suggesting so much that it is painful in general (that's neither here nor there): I'm suggesting that existing libraries, specifically libsodium, make this _easier_ for anyone who isn't writing like C or _maybe_ Rust and _maybe_ Go. (So, anything on the JVM, Python, Javascript, Ruby, PHP... You name it.) For those use cases, the consumed artifact is a .so. Having a .so is easier than having to make it. Furthermore, having repeatedly built libsodium (I built FPM debs when libsodium wasn't yet commonly packaged), for those people building this is just as easy as libsodium if for some reason they need to build at all.
- loup-vaillant 10y ago
  > Having a .so is easier than having to make it. What's the point, a compilation unit is only a gcc call away from being an .so, right? Besides, I made sure I don't expose unnecessary symbols to the linker. What you're telling me amounts to saying binary distributions are easier to consume than source distributions. I would be quite bewildered by such a claim. As well as a little upset at my disadvantage: I do not have the resources to package my library for all major OSes and distributions. This of course has nothing to do with the library itself, merely the community around it (with one author and no user, as is the case with anything new). I've seen new programming languages being criticised for the immaturity of their tooling or the lack of community. This feels similar. --- Or, your idea of an .so is different from mine. Does .so libraries have something the C source files don't?

lvh 10y ago

I'm not suggesting so much that it is painful in general (that's neither here nor there): I'm suggesting that existing libraries, specifically libsodium, make this _easier_ for anyone who isn't writing like C or _maybe_ Rust and _maybe_ Go. (So, anything on the JVM, Python, Javascript, Ruby, PHP... You name it.) For those use cases, the consumed artifact is a .so. Having a .so is easier than having to make it. Furthermore, having repeatedly built libsodium (I built FPM debs when libsodium wasn't yet commonly packaged), for those people building this is just as easy as libsodium if for some reason they need to build at all.

loup-vaillant 10y ago
> Having a .so is easier than having to make it. What's the point, a compilation unit is only a gcc call away from being an .so, right? Besides, I made sure I don't expose unnecessary symbols to the linker. What you're telling me amounts to saying binary distributions are easier to consume than source distributions. I would be quite bewildered by such a claim. As well as a little upset at my disadvantage: I do not have the resources to package my library for all major OSes and distributions. This of course has nothing to do with the library itself, merely the community around it (with one author and no user, as is the case with anything new). I've seen new programming languages being criticised for the immaturity of their tooling or the lack of community. This feels similar. --- Or, your idea of an .so is different from mine. Does .so libraries have something the C source files don't?