> it doesn't change the fact that both its documentation and the handling of invalid arguments should be improved, and that should happen _in_ Erlang, not anywhere else. A lot of the issues you have mentioned could be solved simply by improving the documentation to be explicit about what represents "good" selections vs "bad", what gotchas to be aware of, etc
Agreed that documentation improvements and argument handling should happen in Erlang. I disagree that documentation improvements and best practices would solve these problems. In practice, I definitely haven't seen that to be the case. > I see no reason why the OTP team wouldn't be amenable to a new crypto interface which is safer and easier to use, or at least open to discussion about it. Perhaps that is the best solution. Although, unfortunately, a new interface doesn't really solve the problem of the developer still needing to figure out which interface to use. Anyway, I appreciate the input :) I'll start poking around for potential solutions elsewhere. On Monday, May 14, 2018 at 2:02:29 PM UTC-4, Paul Schoenfelder wrote: > > I think despite that Erlang has to keep some APIs for legacy reasons, it > doesn't change the fact that both its documentation and the handling of > invalid arguments should be improved, and that should happen _in_ Erlang, > not anywhere else. A lot of the issues you have mentioned could be solved > simply by improving the documentation to be explicit about what represents > "good" selections vs "bad", what gotchas to be aware of, etc. Erlang has > also evolved APIs in the past by introducing new modules, and slowly > deprecating the old (see `rand` and `random`); I see no reason why the OTP > team wouldn't be amenable to a new crypto interface which is safer and > easier to use, or at least open to discussion about it. I just don't think > this is a good fit for the Elixir standard library, or even a third-party > library - this is a prime case of where contributing things upstream to OTP > benefits everyone, even if its a slower process. I would try opening an > issue there first, getting some discussion going, and if it fails to gain > traction, reviving this thread to see what people think. > > Paul > > > On Mon, May 14, 2018 at 1:40 PM, Griffin Byatt <byatt....@gmail.com > <javascript:>> wrote: > >> My concern with leaving it as a library is primarily that the onus is >> still on the developer to figure out which library to choose, so it doesn't >> really alleviate the issue. As it stands, developers already have >> out-of-the-box crypto tools when they are using Elixir, but they aren't the >> easiest or most secure to use. >> >> I *do* think that keeping it minimal is important. Non-basic features >> could absolutely be relegated to a library. But I don't know of any >> languages without some crypto support, and, as a secure/modern language, I >> think Elixir is in a good position to offer a saner API. >> >> (Only somewhat related) I also think that any non-core crypto library >> would do better to wrap libsodium than Erlang's crypto module. >> >> On Mon, May 14, 2018 at 1:02 PM Tallak Tveide <tal...@gmail.com >> <javascript:>> wrote: >> >>> Why shouldnt it start out as a library, then if it proves useful discuss >>> whether to include in elixir core? >>> >>> My feeling is that this belongs outside a language, Erlang has too much >>> stuff included. This was probably the right call back when Erlang didnt >>> have package managers, but elixir has great package support... >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "elixir-lang-core" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/elixir-lang-core/J-Idvs6ije8/unsubscribe >>> . >>> To unsubscribe from this group and all its topics, send an email to >>> elixir-lang-co...@googlegroups.com <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/elixir-lang-core/018f200b-6586-4c53-b3c9-2addc069a73b%40googlegroups.com >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to elixir-lang-co...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/CAMURSkG0bMQ48%2BKncciXdj7ugrmCSe4pur%2BCTGWh7JhHvofYZA%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/CAMURSkG0bMQ48%2BKncciXdj7ugrmCSe4pur%2BCTGWh7JhHvofYZA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/ab2aec1a-1e2c-4be7-84e1-8862cf011fa7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
