You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+103-6Lines changed: 103 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,8 +1,98 @@
1
1
# Changelog for Elixir v1.10
2
2
3
-
## v1.10.0-dev
3
+
## Support for Erlang/OTP 21+
4
4
5
-
Elixir v1.10 requires Erlang/OTP 21+.
5
+
Elixir v1.10 requires Erlang/OTP 21+, allowing Elixir to integrate with Erlang/OTP's new logger. Currently, this means that the logger level, logger metadata, as well as all log messages are now shared between Erlang and Elixir APIs.
6
+
7
+
We will continue improving the relationship between the logging systems in future releases. In particular, we plan to expose all log levels and runtime filtering functionalities available in Erlang directly into Elixir in the next Elixir version.
8
+
9
+
This release also adds two new guards, `is_struct/1` and `is_map_key/2`, thanks to the strict requirement on Erlang/OTP 21+.
10
+
11
+
## Releases improvements
12
+
13
+
Elixir v1.9 introduced releases as a mechanism to package self-contained applications. Elixir v1.10 further improves releases with bug fixes and new enhancements based on feedback we got from the community. The highlights are:
14
+
15
+
* Allow the dual boot system of releases to be disabled on environments that are boot-time sensitive, such as embedded devices
16
+
17
+
* Track and raise if compile-time configuration is set or changes at runtime (more in the next section)
18
+
19
+
* Support for easily adding extra files to releases via overlays
20
+
21
+
* Allow `RELEASE_DISTRIBUTION` to be set to `none` in order to fully disable it
22
+
23
+
* Add a built-in `:tar` step that automatically packages releases
24
+
25
+
See the full CHANGELOG for more improvements.
26
+
27
+
## Improvements to sort-based APIs in Enum
28
+
29
+
`Enum.sort/1` in Elixir always sorts from lowest to highest. If you want to sort from highest to lowest, you need to call `Enum.sort/2` with a custom sorting function, such as `Enum.sort(collection, &>=/2)`, which is not immediately obvious to someone reading the code.
30
+
31
+
To make matters worse, comparison operators, such as `<=` and `>=`, perform structural sorting, instead of a semantic one. For example, using `>=` to sort dates descendingly won't yield the correct result. Therefore, to sort dates from more recent to oldest, one has to write `Enum.sort(dates, &(Date.compare(&1, &2) != :lt))`.
32
+
33
+
Elixir v1.10 streamlines the sorting functions by introducing both `:asc` and `:desc` shortcuts:
34
+
35
+
Enum.sort(collection, :asc) # the default
36
+
Enum.sort(collection, :desc) # in reverse
37
+
38
+
Furthermore, if you want to perform semantic comparison, you can pass a module that provides the relevant comparison function. For example, to sort dates:
39
+
40
+
Enum.sort(birth_dates, Date)
41
+
Enum.sort(birth_dates, {:asc, Date})
42
+
Enum.sort(birth_dates, {:desc, Date})
43
+
44
+
This new API has also been added to `Enum.sort_by`, `Enum.min_by`, `Enum.max_by`, and friends.
45
+
46
+
### Tracking of compile-time configuration
47
+
48
+
All applications in Elixir come with an application environment. This environment is a key-value store that allows us to configure said application. While reading the application environment at runtime is the preferred approach, in some rare occasions you may want to use the application environment to configure the compilation of a certain project. This is often done by calling `Application.get_env/3` outside of a function:
This approach has one big limitation: if you change the value of the application environment after the code is compiled, the value used at runtime is not going to change! For example, if you are using `mix release` and your `config/releases.exs` has:
59
+
60
+
config :my_app, :db_host, "db.production"
61
+
62
+
The new value will have no effect as the code was compiled to connect to "db.local", which is mostly likely unavailable in the production environment.
63
+
64
+
For those reasons, reading the application environment at runtime should be the first choice. However, if you really have to read the application environment during compilation, Elixir v1.10 introduces a `Application.compile_env/3` function:
By using `compile_env/3`, Elixir will store the values used during compilation and compare the compilation values with the runtime values whenever your system starts, raising an error in case they differ. This helps developers ensure they are running their production systems with the configuration they intend to.
69
+
70
+
### Compiler tracing
71
+
72
+
This release brings enhancements to the Elixir compiler and adds new capabilities for developers to listen to compilation events.
73
+
74
+
In previous Elixir releases, Elixir would compile a database of cross references between modules (such as function calls, references, structs, etc) for each project. Although developers could traverse this database, they often requested more events or more information to be made available.
75
+
76
+
In Elixir v1.10, we have replaced this database by compiler tracing. This means that developers can now directly listen to events emitted by the compiler to store and collect all the information they need (and only the information they need).
77
+
78
+
Elixir itself is already using the new compiler tracing to provide new functionality. In particular, the compiler now checks for undefined function warnings more consistently. In previous versions, we would emit undefined function warnings only for files in `lib`, skipping test files and scripts.
79
+
80
+
Furthermore, in Elixir v1.10 developers can now disable undefined function warnings directly on the callsite. For example, imagine you have an optional dependency which may not be available in some cases. You can tell the compiler to skip warning on calls to optional modules with:
81
+
82
+
@compile {:no_warn_undefined, OptionalDependency}
83
+
defdelegate my_function_call(arg), to: OptionalDependency
84
+
85
+
Finally, as consequence of these improvements, some functionality related to `xref` (our previous database), has been deprecated in favor of the new compiler tracing.
86
+
87
+
### Other enhancements
88
+
89
+
The calendar data types got many improvements, such as sigil support for third-party calendars, as well as the additions of `DateTime.now!/2`, `DateTime.shift_zone!/3`, and `NaiveDateTime.local_now/0`.
90
+
91
+
There are many improvements related to the Elixir AST in this release too. First of all, `Code.string_to_quoted/2` has two new options, `:token_metadata` and `:literal_encoder`, that give more control over Elixir's parser. This information has already been available to the Elixir formatter for a couple versions and has now been made public. Furthermore, all public metadata entries in the AST nodes have been extensively documented. These changes alongside the compiler improvements from previous section means tools like Credo and Boundary now have a better foundation to analyze the source code.
92
+
93
+
Finally, ExUnit comes with two small but important improvements: `ExUnit.CaptureIO` can now be used in tests that run asynchronously and we have added "data-structure diffing" when performing assertions with pattern matching. So now, whenever an assertion such `assert %{field: value} = expression()` fails, ExUnit will show both left-hand and right-hand sides, highlighting the parts that did not match in red.
0 commit comments