3 ms·

I'd disagree with "easier to deploy". Most users are going to do this via FFI, and then one .c and one .h pales in comparison to "already has a dylib/so" I can

by lvh 10y ago

I'd disagree with "easier to deploy". Most users are going to do this via FFI, and then one .c and one .h pales in comparison to "already has a dylib/so" I can use. It may be true that it doesn't need as many eyeballs; alternative implementations of the same code have the benefit that they're pretty easy to automatedly check. libsodium is not anywhere near the size where static analyses become impractical -- do you have any evidence that would support that?

loup-vaillant 10y ago
> 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?
yellowapple 10y ago
"Most users are going to do this via FFI, and then one .c and one .h pales in comparison to 'already has a dylib/so' I can use." This assumes two things: 1) that most users are indeed going to use this via FFI, which (to me at least) sounds like a very bold claim 2) that the target language provides easier support for precompiled shared libraries than it does for using an arbitrary .c or .h source file. This is not always (or even usually) the case, especially if the language's FFI mechanism comes from the C side rather than the target language side (see also: Perl (pre-6) and Ruby when not using third-party FFI modules) or if there are a lot of foreign functions needing an interface (in which case one will likely use some kind of generator, which usually requires the use of a C header to provide the foreign definitions).

by lvh 10y ago

loup-vaillant 10y ago

> 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?

yellowapple 10y ago

"Most users are going to do this via FFI, and then one .c and one .h pales in comparison to 'already has a dylib/so' I can use." This assumes two things: 1) that most users are indeed going to use this via FFI, which (to me at least) sounds like a very bold claim 2) that the target language provides easier support for precompiled shared libraries than it does for using an arbitrary .c or .h source file. This is not always (or even usually) the case, especially if the language's FFI mechanism comes from the C side rather than the target language side (see also: Perl (pre-6) and Ruby when not using third-party FFI modules) or if there are a lot of foreign functions needing an interface (in which case one will likely use some kind of generator, which usually requires the use of a C header to provide the foreign definitions).