Skip to content

Commit e0bcb1b

Browse files
authored
Add v1.14 release announcement (#1629)
1 parent 825ffa0 commit e0bcb1b

File tree

2 files changed

+192
-1
lines changed

2 files changed

+192
-1
lines changed

_includes/search.html

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
<div class="widget news">
22
<h3>
3-
News: <a href="/blog/2021/12/03/elixir-v1-13-0-released/">Elixir v1.13 released</a>
3+
News: <a href="/blog/2022/09/01/elixir-v1-14-0-released/">Elixir v1.14 released</a>
44
</h3>
55
</div>
66

Lines changed: 191 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,191 @@
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

Comments
 (0)