5 ms·

OTP 23

395 points by nifoc 6y ago

conradfr 6y ago
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 6y ago
  I'm curious what the short and long-term performance implications are for Elixir with OTP 23. Has anyone offered up opinions or benchmarks?
sitkack 6y ago
> Support for SSL 3.0 is completely removed. Yay! We need to actively and in a strong forceful manner remove broken security products.
ponyous 6y ago
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?
- brudgers 6y ago
  What I appreciate about this update is how little code it breaks and how little future code is likely to be backwards incompatible. Or to put it another way, what I appreciate is the sameness of the programming environment. To a first approximation nothing needs to be rewritten and newly written code will look just like existing code. What I appreciate is OTP is better and there's nothing programmers have to do (to a first approximation) to get that betterness. Instead, rolling out the betterness is a system administration task. Basically, what is exciting is how well engineered it is.
  - yellowapple 6y ago
    > What I appreciate about this update is how little code it breaks Other than a bunch of code reliant on the stuff removed from erl_interface, of course. No idea how big of an impact that has on real-world projects, though. The deprecation of erlang:get_stacktrace/0 also gave me a brief heart attack for one of my projects¹, but luckily I had the foresight to gate that to older OTP versions (and with newer versions the relevant code already removes dependence on that function), so I can rest at least a little bit easy. ---- ¹: https://github.com/otpcl/otpcl/blob/73167c58771f700963cbd9f70528456bf745ccbe/src/otpcl_repl.erl#L11 https://github.com/otpcl/otpcl/blob/73167c58771f700963cbd9f7...
- dnautics 6y ago
  much of it is a lot of hard work getting to support TLS 1.3, which is nice. I have some TLS-dependent things in prod and let me say, it is really easy to do TLS in OTP. It's also easy to do TLS wrong in OTP, so I recommend watching all of Bram Verburg and Ingela Anderton Antin's videos first. the socket library (if I am correct) is the beginning of redoing the entire network stack in a way that is more commensurate with the way that typical programmers expect (but with the right erlang-ey). > Allow underscores in numeric literals to improve readability This is great whenever a language does it. > The embedded documentation is created as docchunks (EEP 48) It looks like the erlang community is converging on the elixir strategy for documentation. This is fantastic, since elixir documentation is quite good, and it shows that the two languages are starting to put their friendly animosity aside and really working together. > distributed named process groups is introduced This is kind of huge. Sometimes you want a locking, fully consistent process management (so CRDTs are inappropriate), and you don't want a full raft/paxos under the hood.
- tyurok 6y ago
  I personally like a lot the help in the shell feature that is one of the awesome things in elixir's shell that is now on erlang.
- hinkley 6y ago
  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).
  - tandr 6y ago
    This is beautiful, and quite precise (imho). Thank you!
  - liveoneggs 6y ago
    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 6y ago
      I usually blame nodejs. It came around and pushed out what little traction Erlang was gaining in the late 00s.
moviedo 6y ago
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-erlang https://www.futurelearn.com/courses/functional-programming-e....
- Grimm1 6y ago
  I was in the same boat until discovering elixir/erlang it has by far been the most approachable functional language for me and it has been a gateway drug of sorts into experimenting with ocaml and various lisps. I personally think elixir is really special and an amazing fit for any project that needs high IO concurrency.
  - unvs 6y ago
    Agreed! I found learning Elixir to be a great gateway to learn Erlang as well. When I first tried learning Erlang (before Elixir was released), it became a bit too much to wrap my head around. It was a lot easier when I had gotten the fundamentals of FP down through Elixir, though!
    - Grimm1 6y ago
      Yes definitely, I would have never even bothered with Erlang before using Elixir and having it introduce me in a friendly way to Erlang, which is a shame because honestly the EVM and OTP are amazingly strong at what they both do.
  - dnautics 6y ago
    IMO erlang (and arguably even more, elixir) is "functional for the working programmer". It doesn't drown itself in academic abstractions, uses functional programming as a tool to guardrail you from mistakes (in the same way that C guards the programmer from making asm mistakes), with escape hatches that are battle-tested and justified based on decades of experience. I would say the only other functional language that has the same bent is Julia, which is "functional for the working scientist". It makes different choices about where to expose state, understandable, since scientific computing has different tradeoffs from systems programming.
lelf 6y ago
See also: http://blog.erlang.org/OTP-23-Highlights/ http://blog.erlang.org/OTP-23-Highlights/
localcdn 6y ago
Nice to see default TLS 1.3 support. Though it looks like the use_srtp extension for DTLS is still being worked on.
mikece 6y ago
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.
- bicx 6y ago
  It's apples and oranges. OTP paradigms are definitely intended for a larger system that needs its own distribution schemes, handles its own internal process uptime and restarts, and for some use cases, hot code updates (running servers that update without restarting). OTP nodes can also easily and natively communicate between each other across the network, allowing for some pretty sophisticated distributed systems. There are many solutions that could be more easily implemented on some sort of serverless architecture, but in cases where you want to maintain a service with a high degree of reliability and distributed capability, OTP is a good choice. After all, it was developed for the telecom industry to handle phone system communications loads. Worth noting: there are other solutions (some of which are already in serverless environments) that solve the same problems of service uptime during code updates/deployment by keeping an older instance running until the new instance is ready to accept traffic. Services like Kubernetes also implement a lot of cluster management capabilities that solve the same problems OTP was attempting to solve, and you can use whatever language and engine/framework you want. Personally, I think if you wrote a service purely in Erlang/Elixir and directly applied all OTP solutions for uptime, process communication, and distribution, it would be faster and more efficient than a typical serverless or container-based system. But, it would also lock you into that system and make any non-OTP tech more difficult to integrate.
- macintux 6y ago
  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 6y ago
    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.
xutopia 6y ago
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 6y ago
  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).
  - dnautics 6y ago
    There's a reputation that functional programming is harder than object-oriented. I think this comes from the very difficult functional programming languages that exist out there. I think that can be an obstacle. People hear "fp" and think "hard". I personally find Elixir's functional programming is easier, because there are fewer things you have to deal with than object oriented. There are basically no constructs in Elixir that you don't have out of the box in an OO language like Javascript or Python. You just have to deal with that you can't do things like assign variables in if statements (you just have to explicitly export them) and you don't have for loops. Having said that, Enum.map and Enum.reduce are really hard to get used to and can be an obstacle in terms of "why can't I do this thing that is so easy in X". In the long run, once you get used to reading them (which honestly took me about 4-5 months, I have like 20+ years of programming experience) I think they are easier because they are declarative -- you can see exactly what is happening to each piece of your list and in the case of reduce, what state is being passed through each iteration. For loops are far more unstructured, literally anything in any of your parent scopes could be what you're keeping track of through iterations, which means, your mistake surface area is much much higher. The same goes for getting used to "if statements that export values" but, maybe, less dramatically. I know this is difficult to hear since you gave up, but I promise you if you push through it, eventually it will feel like writing elixir is "programming with training wheels on" you can do crazy hard things without worrying about large classes of logical and structural programming errors. Hope you come back to it!
mcmatterson 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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}.
waltfy 6y ago
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!
bsaul 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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.
    - lawik 6y ago
      I'm not using it in huge scale. But I've worked with companies that run it in production, yes. There are a lot of Elixir products and systems out there and before those there were quite a few in Erlang. I don't have a sufficient sample size from my own experience but it is hardly old and disused or too new to be sure. Changelog podcast runs on it. Dockyard build with it. It seems the new default for many previously Rails shops.
rwmj 6y ago
Breaks all of our Erlang bindings (which use erl_interface) ...
- liveoneggs 6y ago
  bummer. What specifically?
  - rwmj 6y ago
    libguestfs is the main project we have with erlang bindings.
elcritch 6y ago
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-example https://github.com/elcritch/einode/tree/master/tests/c-nodes...
- strmpnk 6y ago
  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 6y ago
    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!
alberth 6y ago
What’s the latest on BEAMJIT progress?
pbadenski 6y ago
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 6y ago
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.

395 points by nifoc 6y ago

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 6y ago
I'm curious what the short and long-term performance implications are for Elixir with OTP 23. Has anyone offered up opinions or benchmarks?

sitkack 6y ago

> Support for SSL 3.0 is completely removed. Yay! We need to actively and in a strong forceful manner remove broken security products.

ponyous 6y ago

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?

brudgers 6y ago
What I appreciate about this update is how little code it breaks and how little future code is likely to be backwards incompatible. Or to put it another way, what I appreciate is the sameness of the programming environment. To a first approximation nothing needs to be rewritten and newly written code will look just like existing code. What I appreciate is OTP is better and there's nothing programmers have to do (to a first approximation) to get that betterness. Instead, rolling out the betterness is a system administration task. Basically, what is exciting is how well engineered it is.
- yellowapple 6y ago
  > What I appreciate about this update is how little code it breaks Other than a bunch of code reliant on the stuff removed from erl_interface, of course. No idea how big of an impact that has on real-world projects, though. The deprecation of erlang:get_stacktrace/0 also gave me a brief heart attack for one of my projects¹, but luckily I had the foresight to gate that to older OTP versions (and with newer versions the relevant code already removes dependence on that function), so I can rest at least a little bit easy. ---- ¹: https://github.com/otpcl/otpcl/blob/73167c58771f700963cbd9f70528456bf745ccbe/src/otpcl_repl.erl#L11 https://github.com/otpcl/otpcl/blob/73167c58771f700963cbd9f7...
dnautics 6y ago
much of it is a lot of hard work getting to support TLS 1.3, which is nice. I have some TLS-dependent things in prod and let me say, it is really easy to do TLS in OTP. It's also easy to do TLS wrong in OTP, so I recommend watching all of Bram Verburg and Ingela Anderton Antin's videos first. the socket library (if I am correct) is the beginning of redoing the entire network stack in a way that is more commensurate with the way that typical programmers expect (but with the right erlang-ey). > Allow underscores in numeric literals to improve readability This is great whenever a language does it. > The embedded documentation is created as docchunks (EEP 48) It looks like the erlang community is converging on the elixir strategy for documentation. This is fantastic, since elixir documentation is quite good, and it shows that the two languages are starting to put their friendly animosity aside and really working together. > distributed named process groups is introduced This is kind of huge. Sometimes you want a locking, fully consistent process management (so CRDTs are inappropriate), and you don't want a full raft/paxos under the hood.
tyurok 6y ago
I personally like a lot the help in the shell feature that is one of the awesome things in elixir's shell that is now on erlang.
hinkley 6y ago
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).
- tandr 6y ago
  This is beautiful, and quite precise (imho). Thank you!
- liveoneggs 6y ago
  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 6y ago
    I usually blame nodejs. It came around and pushed out what little traction Erlang was gaining in the late 00s.

moviedo 6y ago

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-erlang https://www.futurelearn.com/courses/functional-programming-e....

Grimm1 6y ago
I was in the same boat until discovering elixir/erlang it has by far been the most approachable functional language for me and it has been a gateway drug of sorts into experimenting with ocaml and various lisps. I personally think elixir is really special and an amazing fit for any project that needs high IO concurrency.
- unvs 6y ago
  Agreed! I found learning Elixir to be a great gateway to learn Erlang as well. When I first tried learning Erlang (before Elixir was released), it became a bit too much to wrap my head around. It was a lot easier when I had gotten the fundamentals of FP down through Elixir, though!
  - Grimm1 6y ago
    Yes definitely, I would have never even bothered with Erlang before using Elixir and having it introduce me in a friendly way to Erlang, which is a shame because honestly the EVM and OTP are amazingly strong at what they both do.
- dnautics 6y ago
  IMO erlang (and arguably even more, elixir) is "functional for the working programmer". It doesn't drown itself in academic abstractions, uses functional programming as a tool to guardrail you from mistakes (in the same way that C guards the programmer from making asm mistakes), with escape hatches that are battle-tested and justified based on decades of experience. I would say the only other functional language that has the same bent is Julia, which is "functional for the working scientist". It makes different choices about where to expose state, understandable, since scientific computing has different tradeoffs from systems programming.

lelf 6y ago

See also: http://blog.erlang.org/OTP-23-Highlights/ http://blog.erlang.org/OTP-23-Highlights/

localcdn 6y ago

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

mikece 6y ago

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.

bicx 6y ago
It's apples and oranges. OTP paradigms are definitely intended for a larger system that needs its own distribution schemes, handles its own internal process uptime and restarts, and for some use cases, hot code updates (running servers that update without restarting). OTP nodes can also easily and natively communicate between each other across the network, allowing for some pretty sophisticated distributed systems. There are many solutions that could be more easily implemented on some sort of serverless architecture, but in cases where you want to maintain a service with a high degree of reliability and distributed capability, OTP is a good choice. After all, it was developed for the telecom industry to handle phone system communications loads. Worth noting: there are other solutions (some of which are already in serverless environments) that solve the same problems of service uptime during code updates/deployment by keeping an older instance running until the new instance is ready to accept traffic. Services like Kubernetes also implement a lot of cluster management capabilities that solve the same problems OTP was attempting to solve, and you can use whatever language and engine/framework you want. Personally, I think if you wrote a service purely in Erlang/Elixir and directly applied all OTP solutions for uptime, process communication, and distribution, it would be faster and more efficient than a typical serverless or container-based system. But, it would also lock you into that system and make any non-OTP tech more difficult to integrate.
macintux 6y ago
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 6y ago
  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.

xutopia 6y ago

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 6y ago
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).
- dnautics 6y ago
  There's a reputation that functional programming is harder than object-oriented. I think this comes from the very difficult functional programming languages that exist out there. I think that can be an obstacle. People hear "fp" and think "hard". I personally find Elixir's functional programming is easier, because there are fewer things you have to deal with than object oriented. There are basically no constructs in Elixir that you don't have out of the box in an OO language like Javascript or Python. You just have to deal with that you can't do things like assign variables in if statements (you just have to explicitly export them) and you don't have for loops. Having said that, Enum.map and Enum.reduce are really hard to get used to and can be an obstacle in terms of "why can't I do this thing that is so easy in X". In the long run, once you get used to reading them (which honestly took me about 4-5 months, I have like 20+ years of programming experience) I think they are easier because they are declarative -- you can see exactly what is happening to each piece of your list and in the case of reduce, what state is being passed through each iteration. For loops are far more unstructured, literally anything in any of your parent scopes could be what you're keeping track of through iterations, which means, your mistake surface area is much much higher. The same goes for getting used to "if statements that export values" but, maybe, less dramatically. I know this is difficult to hear since you gave up, but I promise you if you push through it, eventually it will feel like writing elixir is "programming with training wheels on" you can do crazy hard things without worrying about large classes of logical and structural programming errors. Hope you come back to it!

mcmatterson 6y ago

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 6y ago
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 6y ago
  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 6y ago
    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}.

waltfy 6y ago

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!

bsaul 6y ago

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 6y ago
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 6y ago
  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 6y ago
    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.
  - lawik 6y ago
    I'm not using it in huge scale. But I've worked with companies that run it in production, yes. There are a lot of Elixir products and systems out there and before those there were quite a few in Erlang. I don't have a sufficient sample size from my own experience but it is hardly old and disused or too new to be sure. Changelog podcast runs on it. Dockyard build with it. It seems the new default for many previously Rails shops.

rwmj 6y ago

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

liveoneggs 6y ago
bummer. What specifically?
- rwmj 6y ago
  libguestfs is the main project we have with erlang bindings.

elcritch 6y ago

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-example https://github.com/elcritch/einode/tree/master/tests/c-nodes...

strmpnk 6y ago
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 6y ago
  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!

alberth 6y ago

What’s the latest on BEAMJIT progress?

pbadenski 6y ago

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 6y ago

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.