Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
Forking Elixir; First Impressions

When Elixir 1.8 was released, I wrote an article sharing my thoughts. Unfortunately, they didn't gain enough traction...

The great thing about tech is you don't need someone else's buy-in to run with your own idea.

So I forked.

The next step was to open it my editor. When I inspected elixir/lib, I saw 6 subdirectories. It turns out they are all independent Mix packages. (Notably, elixir--the root directory--has no mix.exs)

The first question this raises is: Why bundle them together?

The 6 packages are:

  • eex
  • elixir
  • ex_unit
  • iex
  • logger
  • mix

Obviously elixir is a must.

iex starts an Elixir shell in one's terminal.

logger produces those useful Elixir-related messages in one's terminal, and is automatically included in a new Mix project.

mix generates a minimal Elixir project-environment.

ex_unit provides macros for basic testing.

The only one that doesn't belong is eex, Elixir's templating language. This would be better suited as an independent package because a basic Mix project won't ever use it.

There is an argument to be made to remove ex_unit: Why lock devs into this particular testing framework? Whatever the performance footprint, I agree with its inclusion in the core for the sake of new devs.

Figuring out how to get Elixir setup is already a lot, psychologically (logistically, it is simple). Wrapping one's head around Mix packages is too big a leap for someone who simply wants to start writing Elixir code.

Additionally, ex_unit is the dominant testing framework for Elixir and has a ton of functionality.

This actually leads into a separate thread. While I believe elixir is bloated and in need of revision, I think ex_unit can be more powerful.

However, a flag should be added to exclude ex_unit from one's project.

For completeness on this topic: Property-based testing is not included by default in Elixir. I think this makes sense because it is more advanced. I.e. if you know what it is, you're willing to go the extra mile, psychologically, to install it. By contrast, for someone who's never written a test before, the test/3 and assert/1-2 macros are extremely intuitive. The hardest part is realizing there is a place to write tests because most languages don't provide it for you so seamlessly.


This comment has been minimized.

Copy link
Owner Author

commented Jan 20, 2019

Actually, reading this, I have a new conclusion.

ex_unit should be removed, but included by default in the mix.exs of any new Mix project. Then, in the terminal instructions, a new step should be added: mix deps.get

This is just as easy, psychologically, and makes new devs better aware of what Mix does. Additionally, it now gives devs the ability to opt out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.