Erlang/OTP 26.1 Released
221 points
8 months ago
| 6 comments
| erlangforums.com
| HN
sph
8 months ago
[-]
This is a good place as any to ask: I'm an experienced Elixir dev so I know my way around Supervisors, GenServers, Registries, etc. but I feel there is more to OTP, the myriad of erlang modules for fault tolerance, which are not immediately visible unless you spend a lot of time reading the erlang docs.

Is there a good book that is focused on advanced OTP? On the internals of the BEAM and the hairier parts of the Erlang ecosystem? I can only find basic to intermediate introductory material. Perhaps I should just spend time reading the erlang website back-to-front...

---

1: I'm taking a small break from writing a parallel, distributed website crawler with homegrown HTTP client. Quite fun, very fast, to replace my first, rough prototype written in Rust. The hard part is accepting that most HTTP servers on the open Internet are hopelessly broken in a million ways.

reply
di4na
8 months ago
[-]
reply
KMag
8 months ago
[-]
> most HTTP servers on the open Internet are hopelessly broken in a million ways.

20 years ago, picking up OCaml, as an initial project I decided to write a password cracker to run against my WiFi router. The webserver on my WRT-54G was sending back errors, but Yahoo's webserver (more popular than Google at the time) was perfectly happy replying correctly to my HTTP client's requests.

I had to break out Ethereal (since renamed Wireshark) to debug why Yahoo was fine with my HTTP client but my WRT-54G wasn't. It turns out I didn't realize that OCaml character escapes that began with zero were still decimal, not octal (unlike C). So, I was sending a line terminator of vertical-tab shift-in instead of carriage-return line-feed. I guess kudos to whomever wrote Yahoo's webserver to make proper sense of such wonky requests, though I think it was far too liberal in what it accepted.

reply
toast0
8 months ago
[-]
> I guess kudos to whomever wrote Yahoo's webserver to make proper sense of such wonky requests, though I think it was far too liberal in what it accepted.

Depending on exactly when, you may have been hitting Yahoo's custom http server originally written by David Filo or yapache, a patched version of Apache 1.3.

reply
rramadass
8 months ago
[-]
In addition to the other recommendation;

1) The BEAM book - https://blog.stenmans.org/theBeamBook/

2) Erlang and OTP in Action by Merritt, Logan and Carlson

reply
_susanoo
8 months ago
[-]
Designing for Scalability with Erlang/OTP by Francesco Cesarini and Steve Vinoski
reply
knewter
8 months ago
[-]
This one
reply
bosky101
8 months ago
[-]
reply
abrookewood
8 months ago
[-]
It would be interesting to hear about a comparison between the two - though it sounds like you aren't as skilled in Rust?
reply
rdtsc
8 months ago
[-]
It's a minor version release, mostly with bug fixes. But I also liked these improvements:

* In Erlang/OTP 27 we're getting triple-quoted strings, so this patch adds a warning for "accidental" triple-quoted strings.

* In Erlang/OTP 27 exact comparison of 0.0 and -0.0 will change so there is a warning for that as well to help detect issues earlier.

* FIPS support in crypto module for OpenSSL 3.x

reply
dlachausse
8 months ago
[-]
I’m really looking forward to triple quoted strings! I definitely could have used them in my last project.
reply
rdtsc
8 months ago
[-]
Me too! I think of it every time I have to escape quotes when handling json documents. It will be very nice not to have to do it.
reply
alberth
8 months ago
[-]
What’s the major thing that Erlang/OTP (or Elixir) needs for greater adoption?
reply
thibaut_barrere
8 months ago
[-]
Being taught, or at least mentioned, in schools with programming courses.

Resources that target young people or beginner (we already have some, but more, and more widespread).

Advertising outside the Elixir circle (Chris McCord asked the other day what podcasts would be a good fit for that).

Python has a major edge in France, being defined as the reference language (teached at high school and engineering schools), and as such it sets the frame.

For now, when I mention Elixir around me, although there is interest, the feedback is that it seems like a great language for connoisseurs and people with special needs (e.g. very high concurrency), which most people have no need for.

I personally think it's a great language overall, including from a maintenance point of view, and I try to advertise it as such.

Source: a dad with a 15-yo son who is totally into programming, and quickly saw that Python is everywhere together with Javascript (from a YouTube / blog posts / discord point of view). He doesn't understand why I "bother" with Elixir :-)

reply
ekidd
8 months ago
[-]
As someone who's enough of an early adopter to have been running Rust in production since ~2016, and who takes a good look at Elixir every few years, there are two major things holding me back:

1. Lack of strong typing. Dynamic typing is great on 10,000 line projects with two developers. Once you reach 50,000 lines and have a little developer turnover, it stops being fun. And dynamic typing also usually means far less IDE support. I'm spoiled; I want auto-complete.

2. Elixir is amazing for UIs like Discord, where your users interact in real time. If each of your users lives in their own little world, Elixir's greatest strengths have less chance to shine.

Right now, TypeScript is a no-brainer, because React is the dominant choice for UIs, and using the same language on both client and server is a win. And frankly, TypeScript's lovely, even if the ecosystem is a constantly-churning trash fire. So for a variety of commercial projects, TypeScript is a responsible choice. Typed Python, C#, Java, Kotlin, Swift or Rust all have compelling use cases, too.

But given stronger typing and an project that needed Elixir's strong support for distributed systems, I'd definitely consider Elixir.

reply
jswny
8 months ago
[-]
reply
_trapexit
8 months ago
[-]
Strong typing would not be an unwelcome addition to the Erlang space but compared to most dynamically typed languages I find Erlang/Elixer to be infinitely more usable. If you aren't using guards and specific type pattern matching you arguably are doing it wrong. And those things give you much of the type info you need while developing. No compile time help but it's a lot better than most other dynamic languages. I've built very large projects in Erlang and didn't find typing a real issue.
reply
ekidd
8 months ago
[-]
> I've built very large projects in Erlang and didn't find typing a real issue.

So I want to put on my consultant/lead engineer hat for this discussion. :-) I've worked for years in Ruby, Lisp, Scheme and other untyped languages, and shipped some fairly large projects.

Any project where you can rightfully say "I've built it" is small enough that dynamic typing can be a pretty pleasant strategy. (I'd miss good auto-completion, though.)

But when I walk onto a project with 5-20 engineers and 5 years of code, dynamic typing typically makes everything slow and painful. "We need to update two major Rails versions and deal with 40 supporting libraries. What's the plan for making sure everything still works? We have OK test coverage, but can we pull half the team for 2 weeks to work through the breakage?"

Or perhaps you reach a scale where you need to onboard a bunch of junior developers or data scientists. Here, static typing helps people get up to speed, it encourages them to refactor aggressively, and it limits breakage caused by miscommunication.

50,000 to 250,000 lines of statically-typed code maintained by a 5 person team with normal turnover can make for a very pleasant project. But in that size range, I really don't enjoy dynamic typing. It's doable, but I can really feel the difference.

I am extremely optimistic that Elixir could support excellent static types. And if it does, I'd definitely consider it for a wider range of projects.

reply
plumeria
8 months ago
[-]
Gleam [0] is typed and runs on BEAM.

[0] https://gleam.run/

reply
ralphc
8 months ago
[-]
I'm still new to Elixir, and see Erlang from over here in Elixir land. Recently on Twitter there were debates on static vs. dynamic typing, and the static typists said that it made software more reliable. Which made me think about all the literature I see about dynamically-typed Erlang has been making the most reliable software around for 30 years. I don't know how large Ericsson's telephone switching software is but I think it's more that 50,000 lines.
reply
irq-1
8 months ago
[-]
For anyone who hasn't seen it: https://gleam.run/

> The power of a type system, the expressiveness of functional programming, and the reliability of the highly concurrent, fault tolerant Erlang runtime, with a familiar and modern syntax.

Haven't used it, but I'd like to hear about others experience.

reply
alberth
8 months ago
[-]
Official Elixir blog post on this exact topic from just 2-days ago.

https://elixir-lang.org/blog/2023/09/20/strong-arrows-gradua...

reply
dlachausse
8 months ago
[-]
Honestly, I think a lot of Erlang's issues are superficial (some people find its syntax to be ugly and a bit warty). The other thing it seems to suffer from is the chicken and the egg of it's not popular because it's not popular. It is also a poor fit for certain domains, such as mobile apps.
reply
rockwotj
8 months ago
[-]
If you don’t like the syntax highly recommend giving https://gleam.run a try
reply
dlachausse
8 months ago
[-]
Other than the different line endings I love Erlang’s syntax, but I think the Prolog inspired syntax can be a turn off to people used to more mainstream languages.
reply
melx
8 months ago
[-]
Yyyy... Erlang has great adoption - examples:

- Ericsson (they designed Erlang) is using it for its mobile products/networks. Approx 40% of all mobile traffic worldwide goes through Ericsson's infra.

- WhatsApp used/uses Erlang - again millions (billions?) of users

- Bet365 / Klarna use Erlang - millions of users

- from OSS, RabbitMQ, is written in Erlang

I could go on... Erlang has great adoption, but it's probably smaller than, e.g. Python, due to Erlang's specific applications.

reply
yakubin
8 months ago
[-]
I thought Armstrong wrote that Ericsson replaced Erlang with C++ or some such thing, because they didn’t want to maintain a language and wanted something more off-the-shelf.
reply
macintux
8 months ago
[-]
They tried to drop it in favor of C++ but eventually realized their mistake, IIRC.
reply
tguvot
8 months ago
[-]
you should finish reading. they failed with replacement and went back to erlang. though it's not 100% pure erlang
reply
whalesalad
8 months ago
[-]
lots of users using a tool built on erlang != lots of users using erlang.

in the programming community as a whole erlang/elixir are not very common.

it's important to ack this distinction becuase we still have a hill to climb with spreading awareness for OTP.

reply
adius
8 months ago
[-]
For me: Proper type system. But they are apparently working on it, so there is hope: https://elixir-lang.org/blog/2023/06/22/type-system-updates-...
reply
xvilka
8 months ago
[-]
There's already an update on the progress: https://elixir-lang.org/blog/2023/09/20/strong-arrows-gradua...
reply
xvilka
8 months ago
[-]
But I am doubtful of how actually useful it will be given how typing isn't very popular with real world code in TypeScript or Python. Too many people prefer to cut corners if they can. It should be either strict typing or none of it.
reply
fastball
8 months ago
[-]
Typescript is how it is because it is a strict superset of javascript and because they needed a type system which would describe all the existing Web APIs, which are a nightmare.
reply
rockwotj
8 months ago
[-]
You should check out https://gleam.run
reply
orangepurple
8 months ago
[-]
Gleam is great but it suffers from massive key person risk right now.
reply
roblh
8 months ago
[-]
I’m fairly new to elixir, but the two things I liked the least were having to use asdf to get a working version of it that didn’t fight with the language server, and really the language server not being particularly smart or fleshed out. It’s not catastrophic, but there are many other languages that are much smoother. Particularly the auto-formatting leaves a lot to be desired. Thankfully these really aren’t existential problems because the language itself is so pleasant to use.
reply
bcardarella
8 months ago
[-]
Here is the list of things that I feel are still holding Elixir back from wider adoption:

1. Not enough companies sharing their experience - most companies want to lead and not follow. There has been a lot of success with Elixir but too often I've heard companies not wanting to indicate they're using Elixir out of concern that it will tip off their competition (I've heard this from two companies now, big ones) or they just don't have a culture of sharing. The most impactful case study on Elixir was one of the first, the Bleacher Report case study https://www.erlang-solutions.com/case-studies/bleacher-repor.... They did an excellent job of articulating the direct business value of transitioning from Rails to Phoenix. We need more of these stories shared

2. Lack of talent - this is a chicken or egg problem but one thing that comes up quite often. If there were more companies actively hiring in Elixir there would be more devs learning Elixir but companies are reluctant to hire for Elixir because there aren't enough devs. Most of the courses/guides are aimed at transitioning Senior level talent. At DockYard through our Academy https://academy.dockyard.com/ we decided to tackle this from the opposite end and commit to producing high quality junior Elixir engineers.

3. Higher price point for talent - the recent Stack Overflow surveys regularly rank Elixir at the top for cost. Personally I think this stat is being influenced by the fact that Elixir has a higher % of more Senior level talent so the average salary will be skewed higher. But that nuance doesn't come through in the cost rankings. If true then as the ecosystem's talent pool starts to normalize we should see this cost average out.

4. Lack of off-the-shelf solutions - Objectively Elixir is faster to build and less costly to maintain than nearly every other tech stack I've ever used. However, because it is so easy to build something we have developed a culture of "just make it from scratch" too often. When newbies ask "how do I do X" questions like auth or something else in another tech stack that they can simply add a node module or a Ruby gem in Elixir most times we lack those pre-built solutions. So the actual build cost is higher because we can't simply drop that solution in and accelerate the dev process.

I've been selling Elixir services for almost a decade at this point and I'm still very bullish on Elixir. We, along with many others, have been trying to close these gaps. It's happening but the most impact anyone reading this can make that is using Elixir is to share your experiences. Write blog posts. Publish case studies. Indicate the reduction in cost, faster times to market, etc... these are the data points that are going to be most compelling and important in the coming decade.

reply
nesarkvechnep
8 months ago
[-]
It’s been hard to find part-time Elixir jobs to supplement my main income. I can make their services fly but nobody wants to listen.
reply
arrowsmith
8 months ago
[-]
Re: your first point - I don't get it. Why would companies not want to "tip off their competition" that they're using Elixir? What are they scared of?
reply
bcardarella
8 months ago
[-]
I don't get it either. But this is the response that I've been given. I think they view Elixir as a competitive advantage. TBH it's a dumb look.
reply
daitangio
8 months ago
[-]
The heart of Elixir :)
reply
jacquesm
8 months ago
[-]
Elixir: a relatively thin layer around Erlang that you eventually have to learn anyway.

Elixir is sort of a gateway drug to Erlang, sooner or later you want the real thing.

reply
di4na
8 months ago
[-]
I maintain erlang libraries. I contributed to OTP. I am from Elixir.

I cannot agree. Erlang is a pita to with. From the lackluster test libraries, the lack of module aliasing, the atrocious UX of parse transform, and so much more.

Erlang bring nearly nothing that Elixir cannot do and the UX of elixir is by far better.

And I am not talking of syntax here.

reply
jacquesm
8 months ago
[-]
I think what you're seeing here is a difference in age and general approach to programming. I learned how to program in the 70's and early 80's. Back then anything that didn't require punch cards and line editors was considered an amazing luxury. I never really grokked IDE's (though: TurboC and TurboC++ got pretty close on Windows) and I tend to remember the bits of a language and eco-system that I need.

Erlang was made by and for that generation, with the tools that were there at the time and so it 'speaks to me' in a way that I'm familiar with. Going on the assumption that you've learned to program a little later, by the time that eco systems were more fully featured, IDEs were commonplace and things like test libraries and namespaces were common I can totally understand why something like Erlang would leave you frustrated.

But to me it is a luxury and always will be. So long term, Elixir probably has the future, but that battle hardened foundation that it builds on stems from a different era, where reading the documentation was a prerequisite for doing anything with a system and all systems had their little quirks. Erlang's roots in turn are partially in Prolog, which is another one of those beasts of times long gone, it too is quirky and some of that shows through in Erlang and the way it approaches things.

In my experience it pays off to embrace such things rather than to fight them, then you can spend your time and energy far more productive rather than to let it be in the front of your focus while you're trying to get some work done. In the end it is all tools, and just like in the trades there are no bad tools.

reply
di4na
8 months ago
[-]
So... this is so funny because it feels like you totally missed my point.

I did not talk of reading documentation because i am literally one of the person you should come to if you need something in the doc. I learned how to write elixir and erlang by reading their doc.

I also do not use an IDE and am really relucant of them because i don't find them useful.

And I am a big defender of prolog. And i am not denying the strong architecture and infrastructure of erlang. I literally contribute to it.

But what you have not addressed is ... all I mentioned. The broken testing libraries. The inability to do the right thing nicely because the parse transform are a pita. The fact that modules names cannot be aliased, generating painful to navigate file structure and names. Etc etc.

And look. It can be made better. We have worked on documentation and there is more coming. We are getting multiline strings. Rebar3 mostly work. Hex can be used for erlang projects.

But in order to do things better we need to acknowledge the problems. Not just say that the kids don't understand. Especially when the person you say that to is actually understanding it pretty well thank you.

reply
jacquesm
8 months ago
[-]
I'm not addressing those things because we are in agreement there.
reply
enraged_camel
8 months ago
[-]
As a third person reading the conversation, your original post came across as dismissive in the sense that you referred to Elixir as merely a "gateway drug" and Erlang as "the real thing", an opinion that you provided zero support for. When someone pointed out some of Erlang's significant shortcomings and pain points relative to its modern counterpart, your reply came across as somewhat condescending, in a "oh yeah? well, back in my day..." sort of way, which is how a lot of old people talk down to younger people.
reply
jacquesm
8 months ago
[-]
It was a response to the top level comment which did the same thing in reverse.

Anyway, I'm kind of done with the personal attacks so have a nice day.

reply
enraged_camel
8 months ago
[-]
No need to play the victim, because I didn't attack you personally, merely pointed out why your tone was off-putting. /shrug
reply
pmontra
8 months ago
[-]
I'm a bit younger than you but not much. I looked at Erlang when I learned Elixir because it's handy to be able to read the source code of some modules or understand some examples. There is usually a 1:1 transposition between the two languages. That is, they are the same language with different syntax and a very simple way to translate between them.

That said, Elixir is nicer to read but I was spoiled by Ruby. Erlang is nicer than most of the stuff of the 80s though.

However I wish the Elixir team had more courage and did without all the boilerplate of those handle casts and calls in servers. They used macros to do all sort of things, so I guess they could use them to bury that complexity into the depths of the language and let us use real function names to call servers. It would start to open a gap between Elixir and Erlang but it would be worth it.

reply
kaycey2022
8 months ago
[-]
I'm quite junior in my Elixir experience at this point.

I've found that reading any source code is made orders of magnitude difficult by the use of metaprogramming. Sure, it makes things much easier for people who are just picking up the language, but at the cost of imposing a literal wall in front of them when they try to go in deeper.

Case in point, is metaprogramming in Ruby on Rails. It's just not worth it if used that extensively. I'm very thankful that the Elixir source is super approachable for anyone who wants to read it.

reply
davidw
8 months ago
[-]
I've been using Erlang for something like 20 years, and Elixir has some genuine improvements over it, like using "binaries" for strings instead of the linked list/array things.
reply
jacquesm
8 months ago
[-]
Yes, strings are a real pain point. And I absolutely believe that if Erlang were to be created from scratch today it would be much closer to Elixir than to the Erlang that is there with all of the historical baggage. But what surprises me is how well it is geared to the problems of the modern web, almost no other platform seems to be so tailor made for web scale event and request processing.
reply
davidw
8 months ago
[-]
Out of curiosity, what have you built that really took advantage of what BEAM does well?
reply
jacquesm
8 months ago
[-]
A message switch.
reply
wink
8 months ago
[-]
We'd been using erlang and it was perfectly fine. Then we needed a REST API and I looked at how much work it would need to make it nice and chose Phoenix. For some reasons I still wrote a lib that I'm calling in erlang and because of different string handling it's a bit of a pain.

So for me at least, both have their strength but I wouldn't say you need Erlang, Elixir can work fine on its own.

reply
depr
8 months ago
[-]
If there are no bad tools, why use Erlang at all instead of for example, Java, C, C++ or Python which all have a larger ecosystem and user base?
reply
jacquesm
8 months ago
[-]
Because tool quality is only one dimension to a choice. There are no bad tools: but there are tools that are more suitable to a particular purpose. For instance because of interop, existing infrastructure, team experience, access to specialists, natural fit between tool and problem, availability of existing libraries and so on.
reply
sodapopcan
8 months ago
[-]
So TL;DR: "Elixir is a gateway drug to Erlang, unless you were born after 1979" ;)
reply
jacquesm
8 months ago
[-]
The Elixir programmers that I know describe it as 'biting the bullet', going from their familiar environment into something that is pretty alien to them. Instead of all the luxury you are used to suddenly you have to get into the mindset of programmers that didn't have access to all of these fancy tools (and sometimes very useful tools). For example, debuggers are to me a luxury, I am used to reason about what my code does before writing it. If your first reflex upon reaching an issue with your code is to reach for a debugger to see what it does instead of what you meant then you will probably never really train that reasoning ability. This also tends to be a dividing line between 'gluing APIs together to get something that works' versus building something from the foundational pieces offered by the language and then integrating that into a larger whole.

OTP is a fantastic example of this sort of thing: it is arcane, fairly complex but surprisingly well built and the quality of the architecture is something most modern frameworks can only dream of. The only reason it is still around is for the same reason that crocodiles are still around: it is extremely well adapted to the niches where it is present, all the other stuff has died out. You can re-invent all (or usually part) of OTP in any language and there have been many attempts at doing just that. But why would you? It already exists and it is far more battle hardened and time tested than anything new likely will ever be. Ok, you'll have to bite that bullet...

reply
sodapopcan
8 months ago
[-]
I was mainly making a joke :P

I think many web developers do just fine without ever having to touch Erlang, which is one of the nice things I like about Elixir: it's making a platform that is almost tailor made to web development really accessible to web developers. There is an idea outside the ecosystem that Elixir is "overkill" for simple apps but that's just not true!

For those that find themselves needing to dive into Erlang, I too have seen several people describe it as "Biting the bullet," and I'm a bit in that camp myself. For me it's not Erlang the language that's a problem, it's the documentation. This speaks to what you said about being from another era. I just do not find it enjoyable to read.

You otherwise seem to be saying that modern tooling is bad because it doesn't force you to be as diligent a programmer. I neither agree nor disagree with this but it's a whole other convo.

reply
rz2k
8 months ago
[-]
Add at least twenty years. In fact, I don’t think many good programmers in their 70s and 80s would agree with the sentiments either. The creators of Erlang also seem to think that Elixir adds significantly, according to public statements and interviews.
reply
anonyfox
8 months ago
[-]
While I agree with the sentiment, there are two superpowers in the mix for me (pun intended):

1. Erlang / BEAM itself as the runtim with lots of powerful capabilities (what you probably are talking about) - you need to know this stuff at some point to fully leverage the technology

2. Elixir the language (+ excellent modern tooling) ontop, which really helps to significantly speed up productivity/average code quality - I don't like to over-reductionist approach here, DX is also an important thing to consider instead of the raw foundation

reply
lazysloth
8 months ago
[-]
Elixir brings so much to the BEAM ecosystem with the improved UX from the tooling and libraries. If you want a better language on the BEAM go with LFE in my opinion.
reply
KingMob
8 months ago
[-]
I'm very curious, what's the LFE experience like?

Are you in the REPL all day? Any major interop issues?

reply
toolz
8 months ago
[-]
I've been writing elixir for 8 years. I've never once wanted to write erlang, nor have I ever written erlang programs.
reply
cpursley
8 months ago
[-]
Same. I’ve had to call a handful of Erlang functions from Elixir over the years but never had to dive deeper than that.
reply
redhale
8 months ago
[-]
Probably shouting into the wind here, but it would be amazing to get Erlang compatibility in the Windows Nano Server Docker images [0]

Without it, to run RabbitMQ in a Windows containers, you have to run the enormous Server Core images.

A niche issue, I know, but a constant thorn in my side!

[0] https://github.com/erlang/docker-erlang-otp/issues/360

reply
srik
8 months ago
[-]
Maintenance patch apparently, good work team. Looks like they fixed a few shell issues as well but afaict `ctrl-d` to end session hasn't made the cut again uff.
reply