Elixir: The c helper should not produce beam files by default

[ericmj]

Creating .beam files in the local directory for mix projects is usually a bad idea which can cause weird compilation errors. I think this feature is causing more confusion for new users than it helps.

[ericentin]

Just want to note that modules that are compiled in-memory cannot be used with the debugger, so maybe it would be a good idea to provide the option of compiling to file or memory in some way.

[whatyouhide]

Maybe calling it c for compile is not very user-friendly since if I _compile_ I expect the compile output to exist. Maybe we should have an helper to "require" or "load" files?

[josevalim]

@whatyouhide the problem is with folks using c to check something quickly inside a Mix project and leaving a .beam in their root which causes more issues down the road. It has happened almost a dozen times at this point (that I know of).

[whatyouhide]

Yes it happened to me as well tbh, but since we would possibly have this fix in future versions of Elixir, people will still have to deal with c behaving like today for a while; considering that, maybe it's worth thinking about another helper for that, that's what I meant :)

[josevalim]

@whatyouhide I think we should still keep c/1 and c/2, except that c/1 is a shortcut for c(file, :in_memory). So if you want to write to disk, you just do: c("foo.ex", ".") which is a bit more explicit and we don't end-up adding a new letter to our helpers. :)

[danhper]

I have also run a few times into some issues due to a generated beam file,
and I agree it is a bit dangerous for a default behavior.
I like the idea of c/1 defaulting to memory.

[josevalim]

This is up for grabs then. :)

[danhper]

Can I take this one? :smile:

[josevalim]

Yes, please!

[allyraza]

can I take it?

[ericmj]

@allyraza I believe @tuvistavie is already working on it.