|
| 1 | +--- |
| 2 | +layout: post |
| 3 | +title: Elixir v1.14 released |
| 4 | +author: Andrea Leopardi |
| 5 | +category: Releases |
| 6 | +excerpt: Elixir v1.14 is out with a focus on debugging and developer experience |
| 7 | +--- |
| 8 | + |
| 9 | +Elixir v1.14 has just been released. 🎉 |
| 10 | + |
| 11 | +Let's check out new features in this release. Like many of the past Elixir releases, this one has a strong focus on developer experience and developer happiness, through improvements to debugging, new debugging tools, and improvements to term inspection. Let's take a quick tour. |
| 12 | + |
| 13 | +Note: this announcement contains [asciinema](https://asciinema.org) snippets. You may need to enable 3rd-party JavaScript on this site in order to see them. If JavaScript is disabled, `noscript` tags with the proper links will be shown. |
| 14 | + |
| 15 | +## `dbg` |
| 16 | + |
| 17 | +[`Kernel.dbg/2`](https://hexdocs.pm/elixir/Kernel.html#dbg/2) is a new macro that's somewhat similar to [`IO.inspect/2`](https://hexdocs.pm/elixir/IO.html#inspect/2), but specifically tailored for **debugging**. |
| 18 | + |
| 19 | +When called, it prints the value of whatever you pass to it, plus the debugged code itself as well as its location. |
| 20 | + |
| 21 | +<script id="asciicast-510632" src="https://asciinema.org/a/510632.js" async></script><noscript><p><a href="https://asciinema.org/a/510632">See the example in asciinema</a></p></noscript> |
| 22 | + |
| 23 | +`dbg/2` can do more. It's a macro, so it *understands Elixir code*. You can see that when you pass a series of `|>` pipes to it. `dbg/2` will print the value for every step of the pipeline. |
| 24 | + |
| 25 | +<script id="asciicast-509506" src="https://asciinema.org/a/509506.js" async></script><noscript><p><a href="https://asciinema.org/a/509506">See the example in asciinema</a></p></noscript> |
| 26 | + |
| 27 | +## IEx + dbg |
| 28 | + |
| 29 | +Interactive Elixir (IEx) is Elixir's shell (also known as REPL). In v1.14, we have improved IEx breakpoints to also allow line-by-line stepping: |
| 30 | + |
| 31 | +<script id="asciicast-508048" src="https://asciinema.org/a/508048.js" async></script><noscript><p><a href="https://asciinema.org/a/508048">See the example in asciinema</a></p></noscript> |
| 32 | + |
| 33 | +We have also gone one step further and integrated this new functionality with `dbg/2`. |
| 34 | + |
| 35 | +`dbg/2` supports **configurable backends**. IEx automatically replaces the default backend by one that halts the code execution with IEx: |
| 36 | + |
| 37 | +<script id="asciicast-509507" src="https://asciinema.org/a/509507.js" async></script><noscript><p><a href="https://asciinema.org/a/509507">See the example in asciinema</a></p></noscript> |
| 38 | + |
| 39 | +We call this process "prying", as you get access to variables and imports, but without the ability to change how the code actually executes. |
| 40 | + |
| 41 | +This also works with pipelines: if you pass a series of `|>` pipe calls to `dbg` (or pipe into it at the end, like `|> dbg()`), you'll be able to step through every line in the pipeline. |
| 42 | + |
| 43 | +<script id="asciicast-509509" src="https://asciinema.org/a/509509.js" async></script><noscript><p><a href="https://asciinema.org/a/509509">See the example in asciinema</a></p></noscript> |
| 44 | + |
| 45 | +You can keep the default behavior by passing the `--no-pry` option to IEx. |
| 46 | + |
| 47 | +## dbg in Livebook |
| 48 | + |
| 49 | +[Livebook](https://livebook.dev/) brings the power of computation notebooks to Elixir. |
| 50 | + |
| 51 | +As an another example of the power behind `dbg`, the Livebook team has implemented a visual representation for `dbg` as a backend, where it prints each step of the pipeline as its distinct UI element. You can select an element to see its output or even re-order and disable sections of the pipeline on the fly: |
| 52 | + |
| 53 | +<video src="https://user-images.githubusercontent.com/17034772/187455667-b166ce50-c440-444c-94dc-e2c0280a4924.webm" data-canonical-src="https://user-images.githubusercontent.com/17034772/187455667-b166ce50-c440-444c-94dc-e2c0280a4924.webm" controls="controls" muted="muted" style="max-height:640px;"></video> |
| 54 | + |
| 55 | +## PartitionSupervisor |
| 56 | + |
| 57 | +[`PartitionSupervisor`](https://hexdocs.pm/elixir/PartitionSupervisor.html) implements a new supervisor type. It is designed to help when you have a single supervised process that becomes a bottleneck. If that process' 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. |
| 58 | + |
| 59 | +For example, imagine you have a `ErrorReporter` process that you use to report errors to a monitoring service. |
| 60 | + |
| 61 | +```elixir |
| 62 | +# Application supervisor: |
| 63 | +children = [ |
| 64 | + # ..., |
| 65 | + ErrorReporter |
| 66 | +] |
| 67 | + |
| 68 | +Supervisor.start_link(children, strategy: :one_for_one) |
| 69 | +``` |
| 70 | + |
| 71 | +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`. |
| 72 | + |
| 73 | +```elixir |
| 74 | +# Application supervisor |
| 75 | +children = [ |
| 76 | + {PartitionSupervisor, child_spec: ErrorReporter, name: Reporters} |
| 77 | +] |
| 78 | +``` |
| 79 | + |
| 80 | +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. |
| 81 | + |
| 82 | +```elixir |
| 83 | +partitioning_key = self() |
| 84 | +ErrorReporter.report({:via, PartitionSupervisor, {Reporters, partitioning_key}}, error) |
| 85 | +``` |
| 86 | + |
| 87 | +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. |
| 88 | + |
| 89 | +### A common example |
| 90 | + |
| 91 | +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: |
| 92 | + |
| 93 | +```elixir |
| 94 | +children = [ |
| 95 | + {PartitionSupervisor, child_spec: DynamicSupervisor, name: MyApp.DynamicSupervisors} |
| 96 | +] |
| 97 | + |
| 98 | +Supervisor.start_link(children, strategy: :one_for_one) |
| 99 | +``` |
| 100 | + |
| 101 | +Now you start processes on the dynamic supervisor for the right partition. For instance, you can partition by PID, like in the previous example: |
| 102 | + |
| 103 | +```elixir |
| 104 | +DynamicSupervisor.start_child( |
| 105 | + {:via, PartitionSupervisor, {MyApp.DynamicSupervisors, self()}}, |
| 106 | + my_child_specification |
| 107 | +) |
| 108 | +``` |
| 109 | + |
| 110 | +## Improved errors on binaries and evaluation |
| 111 | + |
| 112 | +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". Erlang/OTP 25 and Elixir v1.14 provide more detail for easier debugging. This work is part of [EEP 54](https://www.erlang.org/eeps/eep-0054). |
| 113 | + |
| 114 | +Before: |
| 115 | + |
| 116 | +```elixir |
| 117 | +int = 1 |
| 118 | +bin = "foo" |
| 119 | +int <> bin |
| 120 | +#=> ** (ArgumentError) argument error |
| 121 | +``` |
| 122 | + |
| 123 | +Now: |
| 124 | + |
| 125 | +```elixir |
| 126 | +int = 1 |
| 127 | +bin = "foo" |
| 128 | +int <> bin |
| 129 | +#=> ** (ArgumentError) construction of binary failed: |
| 130 | +#=> segment 1 of type 'binary': |
| 131 | +#=> expected a binary but got: 1 |
| 132 | +``` |
| 133 | + |
| 134 | +Code evaluation (in IEx and Livebook) has also been improved to provide better error reports and stacktraces. |
| 135 | + |
| 136 | +## Slicing with Steps |
| 137 | + |
| 138 | +Elixir v1.12 introduced **stepped ranges**, which are ranges where you can specify the "step": |
| 139 | + |
| 140 | +```elixir |
| 141 | +Enum.to_list(1..10//3) |
| 142 | +#=> [1, 4, 7, 10] |
| 143 | +``` |
| 144 | + |
| 145 | +Stepped ranges are particularly useful for numerical operations involving vectors and matrices (see [Nx](https://github.com/elixir-nx/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`](https://hexdocs.pm/elixir/Enum.html#slice/2): |
| 146 | + |
| 147 | +```elixir |
| 148 | +letters = ["a", "b", "c", "d", "e", "f", "g", "h", "i", "j"] |
| 149 | +Enum.slice(letters, 0..5//2) |
| 150 | +#=> ["a", "c", "e"] |
| 151 | +``` |
| 152 | + |
| 153 | +[`binary_slice/2`](https://hexdocs.pm/elixir/Kernel.html#binary_slice/2) (and [`binary_slice/3`](https://hexdocs.pm/elixir/Kernel.html#binary_slice/3) for completeness) has been added to the `Kernel` module, that works with bytes and also support stepped ranges: |
| 154 | + |
| 155 | +```elixir |
| 156 | +binary_slice("Elixir", 1..5//2) |
| 157 | +#=> "lxr" |
| 158 | +``` |
| 159 | + |
| 160 | +## Expression-based Inspection and `Inspect` Improvements |
| 161 | + |
| 162 | +In Elixir, it's conventional to implement the `Inspect` protocol for opaque structs so that they're inspected with a special notation, resembling this: |
| 163 | + |
| 164 | +```elixir |
| 165 | +MapSet.new([:apple, :banana]) |
| 166 | +#MapSet<[:apple, :banana]> |
| 167 | +``` |
| 168 | + |
| 169 | +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. |
| 170 | + |
| 171 | +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. |
| 172 | + |
| 173 | +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: |
| 174 | + |
| 175 | +```elixir |
| 176 | +fruits = MapSet.new([:apple, :banana]) |
| 177 | +MapSet.put(fruits, :pear) |
| 178 | +#=> MapSet.new([:apple, :banana, :pear]) |
| 179 | +``` |
| 180 | + |
| 181 | +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`. |
| 182 | + |
| 183 | +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`](https://hexdocs.pm/elixir/Inspect.html) for a general rundown on the approaches and options available. |
| 184 | + |
| 185 | +## Learn more |
| 186 | + |
| 187 | +For a complete list of all changes, see the [full release notes](https://github.com/elixir-lang/elixir/releases/tag/v1.14.0). |
| 188 | + |
| 189 | +Check [the Install section](/install.html) to get Elixir installed and read our [Getting Started guide](http://elixir-lang.org/getting-started/introduction.html) to learn more. |
| 190 | + |
| 191 | +Happy debugging! |
0 commit comments