[erlang-questions] Coon - new tool for building Erlang packages, dependency management and deploying Erlang services
Mon Feb 12 18:58:12 CET 2018
Goodness - what a lot of mails.
When choosing a name the following algorithm is used by many
organisations and people
1) Choose a name
2) Check in all known languages if this might offend someone
if it does goto 1)
(There are even companies you can hire that do this, if it's a big product)
If I wrote some software I would like it to be discussed for the right
reasons, which are
- it is useful
- it is beautiful
- it solves some interesting problem
- it raises and solves some interesting problem
I would not like it to be discussed for my skills in naming the damn code.
I have said on many occasions that code should be named by the SHA1 checksum of
the content - as far as I know this would not offend people - apart
from those who
thought the name could be a tad simpler.
If you choose the wrong name you can accidentally offend people, even if this
is not your intention - offending people has consequences.
On Mon, Feb 12, 2018 at 6:28 PM, <> wrote:
> On 2018年2月12日月曜日 12時10分20秒 JST Tom Santero wrote:
>> Putting the project's name aside for a moment, there are two things I'd
>> like to point about:
> THANK YOU
>> 1. i would never pull a pre-built binary from a 3rd party into one of my
>> projects. lol security?
> I disagree, in that we are right back in "trusting trust" territory. I prefer building from source (for a number of reasons) but source or not, for nearly everyone (perhaps actually everyone) who builds a project that involves external dependencies, the security is only as strong as the signature on the code received (and implicitly, the trust of the signature scheme employed) and the trust of the review process which granted the signature.
> Both are greviously lacking in using direct-from-github packages (whether source or pre-built) as repository inputs.
>> 2. that this project doesn't address rebar3/relx/hex at all means it is at
>> odds with the direction the community has been pushing toward for several
>> years now, and makes it relatively useless
> I disagree again. In this era we have full-blown systems to drive; the common case today is NOT to deploy to a resource-strapped or custom-built piece of hardware that can never be accessed by system administrators. The common environment today is more like a (to use an awful term) "devops" environment where people want things to rebuild in the lightest possible way and "just go". Which is to say, people desperately wish that Erlang (not to mention Elixir) code could be more commonly built and run the way Python projects that use virtualenv can be.
> I think the to-date direction of the Erlang community de facto practices is a bit dated, being built around the ancient and original assumption "everything has to be an Erlang distribution".
> erlang-questions mailing list
More information about the erlang-questions