Elixir
Elixir v1.14.0-dev

View Source Changelog for Elixir v1.14

Elixir v1.14 requires Erlang/OTP 23+ with a small batch of new features and the usual enhancements and bug fixes to Elixir and its standard library. We cover the most notable changes next.

partitionsupervisor

 PartitionSupervisor

PartitionSupervisor is a new module that implements a new supervisor type. The partition supervisor is designed to help with situations where you have a single supervised process that becomes a bottleneck. If that process's state can be easily partitioned, then you can use PartitionSupervisor to supervise multiple isolated copies of that process running concurrently, each assigned its own partition.

For example, imagine you have an ErrorReporter process that you use to report errors to a monitoring service.

# Application supervisor:
children = [
  # ...,
  ErrorReporter
]

Supervisor.start_link(children, strategy: :one_for_one)

As the concurrency of your application goes up, the ErrorReporter process might receive requests from many other processes and eventually become a bottleneck. In a case like this, it could help to spin up multiple copies of the ErrorReporter process under a PartitionSupervisor.

# Application supervisor
children = [
  {PartitionSupervisor, child_spec: ErrorReporter, name: Reporters}
]

The PartitionSupervisor will spin up a number of processes equal to System.schedulers_online() by default (most often one per core). Now, when routing requests to ErrorReporter processes we can use a :via tuple and route the requests through the partition supervisor.

partitioning_key = self()
ErrorReporter.report({:via, PartitionSupervisor, {Reporters, partitioning_key}}, error)

Using self() as the partitioning key here means that the same process will always report errors to the same ErrorReporter process, ensuring a form of back-pressure. You can use any term as the partitioning key.

a-common-example

 A Common Example

A common and practical example of a good use case for PartitionSupervisor is partitioning something like a DynamicSupervisor. When starting many processes under it, a dynamic supervisor can be a bottleneck, especially if said processes take a long time to initialize. Instead of starting a single DynamicSupervisor, you can start multiple:

children = [
  {PartitionSupervisor, child_spec: DynamicSupervisor, name: MyApp.DynamicSupervisors}
]

Supervisor.start_link(children, strategy: :one_for_one)

Now you start processes on the dynamic supervisor for the right partition. For instance, you can partition by PID, like in the previous example:

DynamicSupervisor.start_child(
  {:via, PartitionSupervisor, {MyApp.DynamicSupervisors, self()}},
  my_child_specification
)

improved-errors-on-binaries-and-evaluation

 Improved errors on binaries and evaluation

Erlang/OTP 25 improved errors on binary construction and evaluation. These improvements apply to Elixir as well. Before v1.14, errors when constructing binaries would often be hard-to-debug generic "argument errors". With Erlang/OTP 25 and Elixir v1.14, more detail is provided for easier debugging. This work is part of EEP 54.

Before:

int = 1
bin = "foo"
int <> bin
#=> ** (ArgumentError) argument error

Now:

int = 1
bin = "foo"
int <> bin
#=> ** (ArgumentError) construction of binary failed:
#=>    segment 1 of type 'binary':
#=>    expected a binary but got: 1

slicing-with-steps

 Slicing with steps

Elixir v1.12 introduced stepped ranges, which are ranges where you can specify the "step":

Enum.to_list(1..10//3)
#=> [1, 4, 7, 10]

Stepped ranges are particularly useful for numerical operations involving vectors and matrices (see Nx, for example). However, the Elixir standard library was not making use of stepped ranges in its APIs. Elixir v1.14 starts to take advantage of steps with support for stepped ranges in a couple of functions. One of them is Enum.slice/2:

letters = ["a", "b", "c", "d", "e", "f", "g", "h", "i", "j"]
Enum.slice(letters, 0..5//2)
#=> ["a", "c", "e"]

binary_slice/2 (and binary_slice/3 for completeness) has been added to the Kernel module, that works with bytes and also support stepped ranges:

binary_slice("Elixir", 1..5//2)
#=> "lx"

expression-based-inspection-and-inspect-improvements

 Expression-based inspection and Inspect improvements

In Elixir, it's conventional to implement the Inspect protocol for opaque structs so that they're inspected with a special notation, resembling this:

MapSet.new([:apple, :banana])
#MapSet<[:apple, :banana]>

This is generally done when the struct content or part of it is private and the %name{...} representation would reveal fields that are not part of the public API.

The downside of the #name<...> convention is that the inspected output is not valid Elixir code. For example, you cannot copy the inspected output and paste it into an IEx session.

Elixir v1.14 changes the convention for some of the standard-library structs. The Inspect implementation for those structs now returns a string with a valid Elixir expression that recreates the struct when evaluated. In the MapSet example above, this is what we have now:

fruits = MapSet.new([:apple, :banana])
MapSet.put(fruits, :pear)
#=> MapSet.new([:apple, :banana, :pear])

The MapSet.new/1 expression evaluates to exactly the struct that we're inspecting. This allows us to hide the internals of MapSet, while keeping it as valid Elixir code. This expression-based inspection has been implemented for Version.Requirement, MapSet, and Date.Range.

Finally, we have improved the Inspect protocol for structs so that fields are inspected in the order they are declared in defstruct. The option :optional has also been added when deriving the Inspect protocol, giving developers more control over the struct representation. See the updated documentation for Inspect for a general rundown on the approaches and options available.

v1-14-0-dev

 v1.14.0-dev

1-enhancements

 1. Enhancements

EEx

  • [EEx] Support multi-line comments to EEx via <%!-- --%>
  • [EEx] Add EEx.tokenize/2

Elixir

ExUnit

IEx

  • [IEx] Evaluate --dot-iex line by line
  • [IEx.Helpers] Allow an atom to be given to pid/1

Logger

Mix

  • [mix compile] Add --no-optional-deps to skip optional dependencies to test compilation works without optional dependencies
  • [mix deps] Mix.Dep.Converger now tells which deps formed a cycle
  • [mix do] Support --app option to restrict recursive tasks in umbrella projects
  • [mix do] Allow using + as a task separator instead of comma
  • [mix format] Support filename in mix format - when reading from stdin
  • [mix new] Do not allow projects to be created with application names that conflict with multi-arg Erlang VM switches
  • [mix profile] Return the return value of the profiled function
  • [mix release] Make BEAM compression opt-in
  • [mix test] Improve error message when suite fails due to coverage
  • [mix test] Support :test_elixirc_options and default to not generating docs nor debug info chunk for tests

2-bug-fixes

 2. Bug fixes

Elixir

  • [Calendar] Handle widths with "0" in them in Calendar.strftime/3
  • [CLI] Improve errors on incorrect --rpc-eval usage
  • [Code] Do not emit warnings when formatting code
  • [Enum] Allow slices to overflow on both starting and ending positions
  • [Kernel] Do not allow restricted characters in identifiers according to UTS39
  • [Kernel] Define __exception__ field as true when expanding exceptions in typespecs
  • [Kernel] Warn if any of True, False, and Nil aliases are used
  • [Kernel] Warn on underived @derive attributes
  • [Protocol] Warn if a protocol has no definitions
  • [String] Allow slices to overflow on both starting and ending positions

ExUnit

  • [ExUnit] Do not raise when diffing unknown bindings in guards
  • [ExUnit] Properly print diffs when comparing improper lists with strings at the tail position
  • [ExUnit] Add short hash to tmp_dir in ExUnit to avoid test name collision
  • [ExUnit] Do not store logs in the CLI formatter (this reduces memory usage for suites with capture_log)
  • [ExUnit] Run ExUnit.after_suite/1 callback even when no tests run
  • [ExUnit] Fix scenario where setup with imported function from within describe failed to compile

Mix

  • [mix compile.elixir] Fix --warnings-as-errors when used with --all-warnings
  • [mix format] Do not add new lines if the formatted file is empty
  • [mix release] Only set RELEASE_MODE after env.{sh,bat} are executed

IEx

  • [IEx] Disallow short-hand pipe after matches

3-soft-deprecations-no-warnings-emitted

 3. Soft deprecations (no warnings emitted)

EEx

  • [EEx] Using <%# ... %> for comments is deprecated. Please use <% # ... %> or the new multi-line comments with <%!-- ... --%>

Logger

Mix

  • [mix cmd] The --app option in mix cmd CMD is deprecated in favor of the more efficient mix do --app app cmd CMD

4-hard-deprecations

 4. Hard deprecations

Elixir

  • [Application] Calling Application.get_env/3 and friends in the module body is now discouraged, use Application.compile_env/3 instead
  • [Bitwise] use Bitwise is deprecated, use import Bitwise instead
  • [Bitwise] ~~~ is deprecated in favor of bnot for clarity
  • [Kernel.ParallelCompiler] Returning a list or two-element tuple from :each_cycle is deprecated, return a {:compile | :runtime, modules, warnings} tuple instead
  • [Kernel] Deprecate the operator <|> to avoid ambiguity with upcoming extended numerical operators
  • [String] Deprecate passing a binary compiled pattern to String.starts_with?/2

Logger

  • [Logger] Deprecate $levelpad on message formatting

Mix

5-backwards-incompatible-changes

 5. Backwards incompatible changes

Mix

  • [mix local.rebar] Remove support for rebar2, which has not been updated in 5 years, and is no longer supported on recent Erlang/OTP versions

v1-13

 v1.13

The CHANGELOG for v1.13 releases can be found in the v1.13 branch.