On Wed, 12 Dec 2018 00:09:11 +1000, Henrik Nord X
<
[hidden email]> wrote:
> Erlang/OTP 21.2 is the second service release for the 21st major
> release with, improvements as well as a few features!
>
> Highlights:
>
> SSH:
>
> * Public key methods: ssh-ed25519 and ssh-ed448 added. Requires OpenSSL
> 1.1.1 or later as cryptolib under the OTP application
>
> SSL:
>
> * ssl now uses active n internally to boost performance. Old active
> once behaviour can be restored by setting a application variable.
>
> ERTS, Kernel:
>
> * New counters and atomics modules supplies access to highly efficient
> operations on mutable fixed word sized variables.
>
> * New module persistent_term!. Lookups are in constant time! No copying
> the terms!
>
WOW! This persistent_term module is very interesting [1], and already see
many places in both my private and work codebase where it will be a
godsend.
However, I fear that there is going to be a lot of abuse.
The temptation to use this as a global shared memory quick-and-dirty
alternative to more elaborate better thought through designs is going to
be too irresistible to many. The downside to many projects these days
using rebar3 and the resulting deep dependencies, is that it's
increasingly more difficult to avoid abuse instigated by others being
introduced into your system (as we're seeing with quick-and-dirty NIFs).
I foresee many projects looking at those warnings in the persistent_term
docs and thinking "I've weighed it, and I think my project is 'special'
enough to call put/1 and erase/1 a little more frequently than the
documentation suggests, or have more entries than is recommended, and I
have my reasons for not using ETS instead". With deep dependencies pulled
down from github, this kind of thinking gets compounded and infectious.
I wish there was a way of providing protections against that sort of
thing. I can't think of one.
Other than that, bravo! This is a very useful feature.
[1] My immediate thought is a replacement for runtime re-compiled and
re-loaded configuration modules which make use the ERTS constant pool --
I've been using these a lot. persistent_term would solve the lingering
purge process-killing problem that the hot-loading approach to config
suffers from.
--
Using Opera's mail client:
http://www.opera.com/mail/_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions