Hiya
If Erlang crypo module could be improved or superseded I'd like for those improvements implemented in Erlang so all languages on the BEAM can make use of them, rather than just Elixir.
Cheers,
Louis
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/e2592402-3095-40c4-862d-a58d273d4420%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
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...
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/018f200b-6586-4c53-b3c9-2addc069a73b%40googlegroups.com.
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> 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-core+unsubscribe@googlegroups.com.
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-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAMURSkG0bMQ48%2BKncciXdj7ugrmCSe4pur%2BCTGWh7JhHvofYZA%40mail.gmail.com.
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> 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> 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.
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.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@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.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@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.
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAK%3D%2B-TsQnAoJ68V2jxjdMafbNkF%3DuMdk4H3GSqn0787EcYE%2B6Q%40mail.gmail.com.