For an ecosystem as large as Erlang/OTP, it actually has surprising little investment relative to its size.<p>An area impacted the most, is R&D into improving raw performance.<p>It's effectively just Lukas Larsson & Björn Gustavsson trying to solve this problem for the past <i>10-years</i> or more.<p>Their work is hugely appreciated, yet they get little to no support on this front.<p>It's definitely beyond my technical abilities to help, but I would financially sponsor focus in this area.<p>Does anyone know how I can donate/sponsor more focus on improving raw performance?
I think the most exciting part is the new documentation format, as someone who primarily works in elixir, I do reference the erlang standard library every now and then so an easier and familiar documentation format is welcomed.<p>I just hope that "h :ets" works in iex later (for those who don't know, it shows the help/module/function documentation of the value specified)
Fascinated to see the mutable tuple optimization. Tuples are dense contiguous vectors in memory, which provide O(1) access - like binaries, but unlike lists.<p>It would be amazing if tuples could also provide O(1) mutable update, in special situations when the original value is not accessed again.<p>The Release Notes show record syntax example.<p>Most tuple changes in code are done through pattern-matched deconstruction, then independent re-construction, which is impossible for the compiler to recognize.<p>So the first step to wider optimization would be common use of <i>'setelement'</i>, very well hidden in the erlang module (i.e. not 'set_element', and no Elixir 'Tuple.set' or 'Tuple.update_at').<p>Then later, that function would get optimized away in many situations. Given that tuples can be up to 60m elements, it would give Erlang a big boost to have O(1) mutable vectors (note the `array` module is a functional tree, not a mutable 1D vector).<p>I am thinking about graphics and data analysis - a huge win. Elixir could also benefit tremendously. Various packages, like 'array' module in Erlang, and 'Nx' in Elixir, would be radically changed. Maybe Elixir could extend '[i]' syntax to access tuples.<p>Let's go for OTP 28!
It's exciting to see the Elixir community contributing to this release: the key feature called out was the new documentation features, which were authored by Jose Valim, the creator of Elixir.<p><a href="https://www.erlang.org/eeps/eep-0059" rel="nofollow">https://www.erlang.org/eeps/eep-0059</a>
Author: José Valim <jose(dot)valim(at)gmail(dot)com>
Status: Draft
Type: Standards Track
Created:02-Jun-2021
EEP 59: Module attributes for documentation #
congrats on another awesome release. such an incredible runtime system. I keep solving the same problems with half assessed solutions that I would otherwise get for free from Erlang.
If they add fstrings, some type of easier map get/put syntax eg #map.value = 1, and maybe a shorter hand fun syntax, then Erlang feels like it's gotten all the conveniences of python. Amazing how far things have come
Reading the change logs speaks volumes to the maturity of this ecosystem. A lot of really great quality of life improvements here and the always welcome performance improvements.<p>Congratulations and thank you to everyone involved!
I'm curious what the default memory usage will be with the raising of the default process limit to 1_048_576?<p>I think it's a good move, if nothing else people who do benchmarks with 1 million processes but don't know those settings are changeable will get further.