What would you remove from Elixir?

With comp it was going to be just a matcher name like:

comp do
  x <- list l
  x <- filter mod(x, 2) == 0 # Only evens
  x * 2 # Double the evens
end

The ‘type’ definition was the code generation command, so list generated optimal code for list iteration, filter would generate optimal code for running the test, etc… etc… I was considering if to make it user extensible as well for custom types that could get around needing to incur the ‘Access’ cost for generic enumerations.

1 Like

At least 1/3 of the core’s API.

I’d remove the required argument from start_link, that is: give it a default value of nil. It is very common that:

  • there is no sensible default value to give to the module
  • the starting value is always the same, in which case it should not be specified in the caller
  • The module has to set up its state after it was started (for instance because state setup takes too long or might fail), which means it will not have a state that is used yet until after init returns.

In general you should pass runtime configuration there.

Why not? Also if we take into account above you will often change that value in tests.

For this you have handle_continue/2 callbacks as you shouldn’t do long initialisations in init/1 either.

1 Like