
OTP 23 - nifoc
http://www.erlang.org/news/140
======
moviedo
I'm currently learning erlang/elixir and I'm really enjoying the language
constructs.

I had originally taken a Programming Language Paradigms class in college with
racket, and I really didn't appreciate functional ideas(i.e. syntax is my
excuse). I'm now a really big fan of functional language idioms.

Anyone interested should try the futurelearn class,
[https://www.futurelearn.com/courses/functional-
programming-e...](https://www.futurelearn.com/courses/functional-programming-
erlang).

~~~
skrebbel
I never understood why people rave so much about functional programming wrt
Erlang/Elixir, when its functional programming is clearly only a means to an
end (fast and safe message passing requires immutable data, which requires FP)
and not a driving design goal in its own right.

I mean, unlike in typical hard FP languages like Haskell or Elm, mutable state
is _rampant_ in your average Elixir app, it's just spread out across many
(global singleton) little processes. Only inside a process you're doing "true"
FP but given how small the average process is in scope, in practice the only
real big difference is that you can't to an `i++` style for loop. Oh no!

But once you leave the process boundary, and often even before it, all bets
are off. The amount of Elixir forum messages I've read that go "you can't do X
at that point, because Y hasn't completed yet" is nuts.

Eg you can't broadcast in a phoenix channel `join` because the channel hasn't
been fully initialized yet. So you send yourself an :after_join message and do
the broadcast in there. I don't know about you but to me this feels a lot more
like C++ than like Haskell.

Or consider the library module Agent which is _exactly identical_ in semantics
to a global singleton variable in an OO/imperative language. It's just a blob
of data that you can get or set.

Now, I don't think any of these are disadvantages. I did mostly C# and
JavaScript before Elixir, so I'm used to the occasional mutable state flying
around.

But I'll never understand that people like Elixir _for being FP_. You just get
such a small subset of the usual advantages of FP that it feels like an
implementation detail. There's lots of advantages, but freedom from thinking
about state isn't one of them.

~~~
brokencode
If you look closely enough at Haskell, you’ll realize that it also can have a
lot of mutable state. Haskell just puts state into various monads and STM to
make its functions pure. You can even spawn numerous isolated threads, all
with their own state, and have them communicate with one another like you do
in Elixir. It does provide a lot of structure and guarantees compared to your
standard imperative language, but I assure you mutable state is still there.

To be clear, the Elm model of putting everything into a big tree and and
transforming that at every user input is very unusual among even FP languages,
and is not the model typically used in Haskell. This might be what you are
thinking of.

Edit: I also want to point out that Elixir processes can be registered
globally to act as singletons, but by default you can spawn any number of
agents or other processes at runtime, meaning they are not singletons.

~~~
coderdd
Actor frameworks with message passing, just like direct mutation, don't
compose.

On Haskell, yes, you can just work off a thread and write shared buffers. But
you are better off using STM or Async (these are a bit like futures), which
compose, and you can write pipelines out of them.

~~~
pdimitar
Everything that you pointed out can be achieved in Elixir, quite easily too.
If I understood you correctly.

Not sure what you mean by "actor frameworks don't compose"?

~~~
dnautics
Actor frameworks don't compose, because actors are an atomic compute unit. You
can't really take a horse actor and a bird actor and turn them into a pegasus
actor. There are non-trivial interactions between message handling logic that
would prevent such a thing with some fairly trivial-to-generate breaking
cases.

Maybe composition for compositions' sake isn't that important?

~~~
pdimitar
> _Maybe composition for compositions ' sake isn't that important?_

Definitely. I was about to ask "but when did you actually need to compose
actors and how does that even make sense?" \-- and while I am sure there are
people who would find a scenario I feel that would still be tarrying on
minutiae.

Obviously the actor model is not a panacea. But for my commercial work Elixir
-- and thus Erlang's OTP -- has been a true blessing. There aren't many
commercial scenarios where OTP is a very poor fit. They do exist but I'd dare
saying they are no more than 10-15% of everything you can stumble upon out
there.

~~~
dnautics
Yep I love Elixir too. Just, you know, I try to only sip the kool-aid.

~~~
pdimitar
Well, I am just now arguing with people in another thread that nobody claims
that Elixir is an end-all be-all.

It's quite sad how fiercely the average HN audience is attacking people who
are trying to show an alternative way of doing things.

------
conradfr
[https://twitter.com/elixirlang/status/1260556559165292544](https://twitter.com/elixirlang/status/1260556559165292544)

> Elixir v1.10.3 is fully compatible with Erlang/OTP 23.0 - so up to date
> Elixir users are ready to give it a try!

~~~
hinkley
I'm curious what the short and long-term performance implications are for
Elixir with OTP 23. Has anyone offered up opinions or benchmarks?

------
lelf
See also:
[http://blog.erlang.org/OTP-23-Highlights/](http://blog.erlang.org/OTP-23-Highlights/)

------
waltfy
Not mentioned in the link above but something super cool with this release is
that

> CPU quotas are now taken into account when deciding the default number of
> online schedulers. > Thus, automatically making Erlang a good citizen in
> container environments where quotas are applied, such as docker with the
> --cpus flag.

Super happy about this!

------
ponyous
Couple of times when somebody posted an OTP erlang update I had no clue what I
was reading. Then I came back to HN and somebody broke down why some things
are really useful/changed and it was mind blowing.

Can some erlanger explain why you are excited about certain things from the
update?

~~~
hinkley
Erlang may be the sturgeon of the software world. It has survived since the
Triassic and yet is somehow prized for specific use cases and discerning
tastes.

It is nowhere near as ancient as sharks, nor as vicious, but it employs some
new physiology, and can survive just as long.

But that was a very different world and it sticks out like an outsider, when
really it's been there the whole time.

(sorry, this analogy got away from me a bit).

~~~
liveoneggs
the story I like to use is -- "imagine a world where java never happened,
where servers were abstracted into HA clusters automatically by your
programming language, and where horizontal scaling was automatic and free"

~~~
bcrosby95
I usually blame nodejs. It came around and pushed out what little traction
Erlang was gaining in the late 00s.

------
elcritch
Looking at the changelog I don't see what the current situation with
erl_interface is. I've been working on some `erl_interface` code using C [2]
and Nim [1], and the headers warn that older `erl_interface` headers would be
deprecated in OTP 23. All the release note highlights mention is a new
`erl_call` program.

Anyone know about the status / rational for the `erl_interface.h` API?

1: 1:
[https://github.com/elcritch/einode/](https://github.com/elcritch/einode/) 2:
[https://github.com/elcritch/einode/tree/master/tests/c-nodes...](https://github.com/elcritch/einode/tree/master/tests/c-nodes-
example)

~~~
strmpnk
Much of the erl_interface functionality prefixed with erl_ names has been
deprecated since OTP 22 and has been removed. The API has shifted to newer ei_
prefixed functions. I believe there are some new deprecations in place as well
which you can find the longer form release notes.

erl_interface itself is not going away but it is evolving with the BEAM VM.
Deprecation warnings should be checked when compiling code on each major
release to avoid surprises as features are usually deprecated for one release
and then removed in the next release each year. The erl_interface
documentation should be up to date with regards to new APIs and might be worth
browsing again to get an idea of the what changes look like.

~~~
elcritch
Thanks! That's good info. The hardest part was that in OTP 22 the examples
given used many of the deprecated erl_* apis. I was able to update the C
examples (see the second link) to use non-deprecated ei_* api calls. Mostly
small changes and a bit better buffer management. Though, I don't like the
lack of buffer length check in even the newer ei_encode_* functions. :/ I
added a 24 byte padding guessing most single item encodes are less than that,
and then check variable length items for size. Still hard to use safely
without a buffer overrun. I'll take a look and see what else may have changed.
It's exciting seeing all the continual beam improvements!

------
sitkack
> Support for SSL 3.0 is completely removed.

Yay! We need to actively and in a strong forceful manner remove broken
security products.

------
xutopia
Though I am not working with Erlang or Elixir right now I am so pleased that
this is seeing improvements. I had as much fun learning Elixir as I did
learning Ruby ages ago. It's just a fun language with great construct!

~~~
organicfigs
I've wanted to work with Elixir for 5 years now. I attempted to go through The
Pragmatic Programmer's Elixir textbook and couldn't make it through. This
comment applies solely to me, I feel I didn't have the aptitude to pick up
functional programming (and that's coming from someone who graduated in CS
from a T3, had years of experience, and starting med school next month).

~~~
brudgers
Since it's already been five years, it might be worth considering Erlang
instead of Elixr. I'd recommend _Programming Erlang: Software for a Concurrent
World_. It was written by Joe Armstrong who designed Erlang and "sold" it
internally across Ericsson to people who were not programmers. They were
people who were using Erlang to solve some other problem.

The paradigm of Erlang is message passing. The primary idiom is logic
programming (like Prolog). Functional programming is related to logic
programming. Between message passing, logic programming, and simple primitives
for concurrency; Erlang programs tend to look a little strange. But it all
hangs together in a way that has been field tested for thirty years. Erlang is
a language that was engineered for use by engineers for solving engineering
problems.

Elixr is mostly a way of avoiding learning Erlang and making the Beam VM
popular. It is a procedural programming abstraction layer. For me, Elixr's
abstractions generate an impedance mismatch and Erlang's syntax better
expresses the engineering mechanisms of concurrent systems and logic
programming. YMMV.

~~~
zeroc8
I've tried learning both and Erlang seems to be less magical and more
consistent. That said, I wouldn't dare to start an important project in either
language for the fear of getting stuck somewhere along the way. With Go, there
are no such concerns, even though the language itself is by far less elegant.

~~~
pdimitar
A valid concern but you should have in mind that ElixirForum is one of the
friendliest and most helpful programming communities that you will find out
there. And that's not coming from me or Elixir veterans but from a ton of
newbies, regularly.

------
mcmatterson
The use of prior matches in guards is super useful for parsing TLV style
payloads where you first match on a size/length field and then match on the
value itself as that number of octets. Does anyone have any insight into how /
when similar support will make its way into Elixir?

~~~
dnautics
I think it's already there?

    
    
        Erlang/OTP 22
        Interactive Elixir (1.10.3)
    
        defmodule Test do
          def matchme(value) do
           x = :foo
           %{^x => bar} = value
           IO.puts(bar)
          end
        end
    
        > Test.matchme(%{foo: "bar"})
        bar
        :ok

~~~
mcmatterson
My goodness, you're right (well, your example isn't, but the feature I'm
talking about has been present since at least 1.8 (the earliest install I have
handy):

    
    
      > <<len::8, val::binary-size(len)>> = <<3>> <> "abc"
        <<3, 97, 98, 99>> 
      > val
        "abc"
    

I don't know how I'd missed that.

(Your example demonstrates 'pinning' which has been a thing since always I
think).

~~~
derefr
Your example is not what EEP-52 adds. The code that didn't used to compile
before Erlang 23 is when the `size` attribute of a match-segment requires an
expression (i.e. math) to be resolved.

One common use-case, is where a payload's prefix-length field encodes the
number of bytes of payload _minus one_. You'll see this in many protocols as
an optimization: if the payload is always at least one byte, then one byte of
payload can be represented as a length of 0, allowing up to 256 bytes of
payload rather than 255.

Here's an example of how the new syntax would be used for that, from the
EEP-52 proposal
([http://erlang.org/eeps/eep-0052.html](http://erlang.org/eeps/eep-0052.html)):

    
    
        example1(<<Size:8, Payload:(Size+1)/binary, Rest/binary>>) ->
           {Payload,Rest}.
    

Before v23, you'd have to do this instead:

    
    
        example1(<<Size:8, Rest0:binary>>) ->
          PayloadSz = Size + 1,
          <<Payload:PayloadSz/binary, Rest1:binary>> = Rest0,
          {Payload, Rest1}.
    

Besides the reduction in code, I _believe_ that the old code has an
optimization fence (the math expression) that the new code doesn't—you get
more optimized code out of the newer expression, because BEAM's runtime loader
gets a bigger contiguous chunk of bitstring ops to specialize across.

Oh, _and_ since the newer code is all in a head-clause, if it fails on
matching Payload, it'll move on to attempting to match on the next head-
clause, rather than generating a badmatch error. Just like if you produce an
error in a head clause's guard clause expression.

\-----

On a separate note, despite this example being simple, you can actually do
arbitrarily-complex things:

    
    
        example2(<<HeaderSize:8, BodyChunkSize:8, BodyNumChunks:8,
                   Payload:(HeaderSize + (BodyNumChunks * BodyChunkLen))/binary,Rest/binary>>) ->
           {Payload,Rest}.

------
bsaul
I would love it so much that someone took the time to correctly evaluate the
pros and cons of OTP vs the current stacks we see those days (stateless
services deployed and configured with kubernetes, with an event-bus backbone
for service 2 service communication).

I've always wanted to try OTP for a real world project (simply because it
looks more elegant and has less parts), and now may be the time, but i'm so
scared of discovering huge pitfalls down the road that are better solved by
more recent techs..

~~~
lawik
I think I understand your concern as the foundation is arguably old. But as
someone actively following Erlang and Elixir the sentiment feels absurd.
Elixir is very recent, very modern and Erlang/OTP has a very strong track
record.

There are drawbacks of course but having worked with Python, PHP and JS. I
haven't seen any real drawbacks. I wouldn't choose it for minimal overhead or
the fastest compute maybe..

Edit: typo

~~~
bsaul
Are you "following" or are you actually using it in production for a real
service ?

I'm asking, because to my knowledge, the only "huge number of users" recent
success story is whatsapp, and after having viewed all the talks about their
stack and experience, it seems that the team was so extremely talented that
they probably would have made something good with any tech.

~~~
ricketycricket
Discord uses Elixir heavily. But if you are scaling to 10s of millions of
concurrent users, you're going to need those types of skills no matter the
language.

------
pbadenski
A few random questions.. hopefully a person more knowledgable in the topic can
help me out:

\- from what I understand Akka (Scala) heavily borrows from Erlang/OTP - is
this correct? What would be the biggest similarities/differences?

\- to what extent OTP is unique to Erlang and to what extent it can be
implemented in another language?

\- any articles/materials out there showing the most valuable bits of OTP
applied in JavaScript/NodeJS?

------
Multicomp
I must admit, I have been watching erlang for a while trying to decide when to
hop in, and I have increasingly come to the conclusion that I will not be
learning erlang as such, although I will be buying the books and reading them,
but I will be learning gleam, which is erlang with types.

I'm too used to the safety that rust or F# gives at compile time to give that
up.

------
localcdn
Nice to see default TLS 1.3 support. Though it looks like the use_srtp
extension for DTLS is still being worked on.

------
mikece
Does cloud-based serverless computing compete with or complement
Erland/Elixir? As a dotNetCore developer who writes a lot of Lambda and Azure
function code I am trying to understand how OTP relates to these paradigms or
if they are apples and oranges.

~~~
macintux
I’ve been out of the Erlang world for a few years now, but it doesn’t seem
like a great fit for serverless. The VM has a non-trivial overhead, and the
language (and VM) design is optimized for long-running, high availability
services.

~~~
micmus
I would say it's mostly that nobody optimized it (perhaps yet) for that
environment. There's generally nothing inherently slow in the VM boot sequence
- it's just that this was not a priority, so it's slow. There are some
attributes suggesting it could be a good fit for that environment, for
example, the VM is generally very small - you can get a full system in ~20MB -
and that again wasn't something that was heavily optimized.

~~~
anthony_doan
There was Erlang on Xen using LingVM awhile back.

------
rwmj
Breaks all of our Erlang bindings (which use erl_interface) ...

~~~
liveoneggs
bummer. What specifically?

~~~
rwmj
libguestfs is the main project we have with erlang bindings.

------
alberth
What’s the latest on BEAMJIT progress?

