OTP at a High Level (2019)(adoptingerlang.org)
adoptingerlang.org
OTP at a High Level (2019)
https://adoptingerlang.org/docs/development/otp_high_level/
63 comments
Am I the only one who saw the title and thought OTP was "one time password"?
Yes. OTP is engrained in my head as the One True Programming (way of building large systems).
Googling OTP it Erlang comes no 9 in the results. The first three are One Time Password. I think there should be a rule to avoid unexplained abbreviations unless the meaning comes up easily in Google.
I clicked thinking it was going to be about one-time programmable memory.
The domain name right along the title should give you a hint…
[deleted]
Nope. Should really say "Erlang OTP" or something
Quoting the article: "OTP stands for _Open Telecom Platform_, which is literally a meaningless name that was used to get the stuff open-sourced back in the old days of Erlang at Ericsson."
Then maybe the acronym should just be expanded.
That would be unfitting. OTP started as "Open Telecom Platform", but today the long form is not in use anymore. To quote Wikipedia (with emphasis from me):
"The name OTP WAS originally an acronym for Open Telecom Platform, which WAS a branding attempt before Ericsson released Erlang/OTP as open source."
Today, OTP is the name.
To avoid confusions, it would have been best to add "(Erlang)" before the title.
"The name OTP WAS originally an acronym for Open Telecom Platform, which WAS a branding attempt before Ericsson released Erlang/OTP as open source."
Today, OTP is the name.
To avoid confusions, it would have been best to add "(Erlang)" before the title.
[deleted]
The URL kind of gives away the theme of the site. And the first sentence starts with “Erlang/OTP”.
Sure: you could just have a list of links with the text "click here" that you hover over to see the url, too. If you haven't worked in the BEAM world those terms packed into a URL might not grab your attention enough to trigger recall, and what are headlines for if not telling us what's on the other side of the click?
>and what are headlines for if not telling us what's on the other side of the click?
Wow, good way of putting it.
Wow, good way of putting it.
Sure, if I spent more than half a second deciding if I want to click something, which I usually don't. This isn't "I can't tell this is Erlang without clicking". This is "there are no obvious signs that it's Erlang without clicking".
“adoptingerlang.org” shows up on the discussion page and the HN main list. No need to click, just to read the word “erlang” that is literally right there. It’s pretty easy actually.
What's ingerlang? Some hip new Norwegian programming language?
ParsingAmbiguityError.
adopt ingerlang OR adopting erlang.
adopt ingerlang OR adopting erlang.
Dude, not everyone knows everything. I'd have to have run into this situation before in order to know to look for erlang in the URL here. Plus, do I ever look at the URL before I click something on HN? no.
I had assumed "OTP" was so incredibly obvious that there was no need to look at the URL, that's all.
> It’s pretty easy actually.
Hindsight is 20/20... blaming user error is pretty cheap when my entire point is that it's easy to make user error.
I had assumed "OTP" was so incredibly obvious that there was no need to look at the URL, that's all.
> It’s pretty easy actually.
Hindsight is 20/20... blaming user error is pretty cheap when my entire point is that it's easy to make user error.
probably not.
here is an answer from mistral-next:
> "OTP" can stand for different things depending on the context. However, in the context of transportation, it commonly stands for "One-Time Password". In the context of fanfiction, it can stand for "One True Pairing". In the context of Atlanta, Georgia, OTP stands for "Outside the Perimeter", referring to the areas outside of the Interstate 285 loop that encircles the city. Please provide more context if you meant a different usage.
Erlang OTP makes no sense... just like X, or Alphabet as company names
here is an answer from mistral-next:
> "OTP" can stand for different things depending on the context. However, in the context of transportation, it commonly stands for "One-Time Password". In the context of fanfiction, it can stand for "One True Pairing". In the context of Atlanta, Georgia, OTP stands for "Outside the Perimeter", referring to the areas outside of the Interstate 285 loop that encircles the city. Please provide more context if you meant a different usage.
Erlang OTP makes no sense... just like X, or Alphabet as company names
The article itself has a blurb that says what it stands for:
> OTP stands for _Open Telecom Platform_, which is literally a meaningless name that was used to get the stuff open-sourced back in the old days of Erlang at Ericsson.
> OTP stands for _Open Telecom Platform_, which is literally a meaningless name that was used to get the stuff open-sourced back in the old days of Erlang at Ericsson.
Outlaw Techno Psomething
of course it has to, because no one knows about it... too bad they didnt use it in the title, because even with HN's highly limited title length, I think it would have fit
Just out of curiosity for anyone starting a new Erlang project: Why use Erlang over Elixir?
I find Erlang is a bit simpler. Some of the macros and so many ways of doing things in Elixir is a tad too much for me. I may be in the minority here, but I also prefer immutable variables.
Other factors: Erlang/OTP base libraries are written in Erlang, so it feels like there is less friction when using them. With a lot of recent language improvements in Erlang like maps, better command line completion, sigils, etc., I feel like I am not missing too much from Elixir's ergonomics.
One caveat might be if I had do a web app, then Phoenix just has a lot of goodies that are nice to have, and maybe then only then I might consider Elixir.
And not make it sound like I am berating Elixir, and to balance things out, I'd like to say the Elixir community is amazing and the collaboration and improvement they've brought to Erlang/OTP are significant in the recent years. It's nice to collaborate and be part one one large BEAM VM community.
Other factors: Erlang/OTP base libraries are written in Erlang, so it feels like there is less friction when using them. With a lot of recent language improvements in Erlang like maps, better command line completion, sigils, etc., I feel like I am not missing too much from Elixir's ergonomics.
One caveat might be if I had do a web app, then Phoenix just has a lot of goodies that are nice to have, and maybe then only then I might consider Elixir.
And not make it sound like I am berating Elixir, and to balance things out, I'd like to say the Elixir community is amazing and the collaboration and improvement they've brought to Erlang/OTP are significant in the recent years. It's nice to collaborate and be part one one large BEAM VM community.
> but I also prefer immutable variables
Just to clarify in case anyone gets the wrong idea about Elixir—Elixir data is immutable (you can't modify structures, only make new ones) and variables cannot be reassigned, but Elixir does allow shadowing variable names.
The difference between shadowing and reassignment is significant, because it means that this code outputs "10", not "20":
Just to clarify in case anyone gets the wrong idea about Elixir—Elixir data is immutable (you can't modify structures, only make new ones) and variables cannot be reassigned, but Elixir does allow shadowing variable names.
The difference between shadowing and reassignment is significant, because it means that this code outputs "10", not "20":
x = 10
closure = fn () -> x end
x = 20
IO.puts closure.()
# 10
let x = 10;
const closure = () => x;
x = 20
console.log(closure())
// 20
Indeed, thanks for clarifying, lolinder. I assumed the audience would be familiar with the differences as it's Elixir vs Erlang here.
So it's immutable variables vs immutable data. Both Erlang and Elixir have immutable data. That's the stuff variables refer to. But in Erlang the variables are also immutable, so X = X + 1, just like in basic math, doesn't make sense.
So it's immutable variables vs immutable data. Both Erlang and Elixir have immutable data. That's the stuff variables refer to. But in Erlang the variables are also immutable, so X = X + 1, just like in basic math, doesn't make sense.
I think the more accurate thing to say is Elixir allows you to rebind variable names whereas Erlang doesn't. Elixir will allow you to pin a name though such that the pattern matches against the already existing variable name's value. Talking about mutability I think confuses this.
It's called rebinding, rather than mutation. Good background here:
https://dashbit.co/blog/comparing-elixir-and-erlang-variable...
https://dashbit.co/blog/comparing-elixir-and-erlang-variable...
Thanks, but I prefer immutable data vs variables as opposed to introducing a new term. I think it's a bit simpler.
It's simpler, but it's also incorrect. There are very real differences between rebinding, reassignment, and mutation. All three are distinct from one another in meaningful ways, so reusing the same term is actually wrong and misleading [0].
Besides, "rebinding" is not a new term. A quick search on Google Scholar turned up numerous results that predate Erlang itself [1]. The concept of "binding" a variable dates back at least to Alonzo Church with the lambda calculus, and "rebinding" is the natural term for what happens when you bind the same name again.
[0] As an example of the potential for confusion, see JavaScript's `const` keyword, which prevents reassignment but does not prevent mutation. Sloppy use of the terminology here has lead to real confusion among new JavaScript developers.
[1] For example, 1986: "If the problems illustrated by Mesa are to be avoided, the language should provide some method of unbinding or rebinding a previously bound name." https://dl.acm.org/doi/pdf/10.1145/324634.325436
Besides, "rebinding" is not a new term. A quick search on Google Scholar turned up numerous results that predate Erlang itself [1]. The concept of "binding" a variable dates back at least to Alonzo Church with the lambda calculus, and "rebinding" is the natural term for what happens when you bind the same name again.
[0] As an example of the potential for confusion, see JavaScript's `const` keyword, which prevents reassignment but does not prevent mutation. Sloppy use of the terminology here has lead to real confusion among new JavaScript developers.
[1] For example, 1986: "If the problems illustrated by Mesa are to be avoided, the language should provide some method of unbinding or rebinding a previously bound name." https://dl.acm.org/doi/pdf/10.1145/324634.325436
> There are very real differences between rebinding, reassignment, and mutation.
Hmm, what would be the difference between rebinding and reassignment in Erlang?
To avoid complication, it's simpler to just use "change" and understand that there are variables and data. The variables themselves may change or may not change. In Erlang they don't, while in Elixir they do. The data won't change in either language, unless we are playing with NIFs or use atomics or counters.
> All three are distinct from one another in meaningful ways, so reusing the same term is actually wrong and misleading
If we're talking in the context of Erlang is quite simple, it's enough to just say variables are immutable. When it comes to Elixir we need to add a distinction, and that complicates things. When talking about Javascript or C++ or other languages, then more nuances are needed.
Hmm, what would be the difference between rebinding and reassignment in Erlang?
To avoid complication, it's simpler to just use "change" and understand that there are variables and data. The variables themselves may change or may not change. In Erlang they don't, while in Elixir they do. The data won't change in either language, unless we are playing with NIFs or use atomics or counters.
> All three are distinct from one another in meaningful ways, so reusing the same term is actually wrong and misleading
If we're talking in the context of Erlang is quite simple, it's enough to just say variables are immutable. When it comes to Elixir we need to add a distinction, and that complicates things. When talking about Javascript or C++ or other languages, then more nuances are needed.
> To avoid complication, it's simpler to just use "change" and understand that there are variables and data.
If you're just talking about Erlang, sure. But as soon as you're comparing languages to each other (which you are) then you have to use the precise terminology if you don't want to confuse people. You can complain about the need for the terminology, and you're certainly welcome to prefer the language that doesn't allow rebinding, but that doesn't actually make the terminology unnecessary.
If you're just talking about Erlang, sure. But as soon as you're comparing languages to each other (which you are) then you have to use the precise terminology if you don't want to confuse people. You can complain about the need for the terminology, and you're certainly welcome to prefer the language that doesn't allow rebinding, but that doesn't actually make the terminology unnecessary.
Binding is not a new term. And here, it is the term. No object is getting mutated. The name is rebound. This is also known as shadowing.
This would make me choose erlang over Elixer. It's convenient to find an assignment to a variable and not have to worry there might be another.
It really isn't a problem... like, at all as it only affects variables within the same scope.
foo = "Hello"
if true do
foo = "Bye!"
end
foo # `foo` is still "Hello" here
Yep, I can see why someone would prefer preventing shadowing even though I don't. I just wanted to be clear on what the actual behavior was.
I've worked with both extensively and I agree that Elixir's rebinding is a bit of a wart. FWIW you can get the Erlang behaviour by using the "pin" operator:
iex(1)> x = 4
4
iex(2)> ^x = 3
** (MatchError) no match of right hand side value: 3I agree with this sentiment. I programmed in Erlang for more than a decade before Elixir came along and I couldn't see the point of it. When I first picked up Erlang in '99 it was a breath of fresh air. The simplicity of the language blew me away (or maybe I just had a very good tutor).
[deleted]
TLDR; I prefer the Erlang syntax. Since I use Erlang VM for hobby / side projects, it's easier for me to come back to after some time away.
You can't go wrong. Inevitibly, which every you start with, you'll learn both.
My personal journay started with learning Elixir. I soon discovered that I was reading Erlang docs, encountering Erlang stack traces, and using many fantastic Erlang lirbaries. I decided I wanted to be build stronger Erlang experience and havn't looked back.
I still create Elixir projects from time to time, especially to leverage Ecto (for databases). Also, on my todo list is to play with the Phoenix (web framework) project.
I'm suspect my journey is rather common, I see Elixir developers comfortable with Erlang and vice-versa. Though, I'm sure each has a perference like a dominant hand. You'll find yours as you explorer this fantastic technology.
You can't go wrong. Inevitibly, which every you start with, you'll learn both.
My personal journay started with learning Elixir. I soon discovered that I was reading Erlang docs, encountering Erlang stack traces, and using many fantastic Erlang lirbaries. I decided I wanted to be build stronger Erlang experience and havn't looked back.
I still create Elixir projects from time to time, especially to leverage Ecto (for databases). Also, on my todo list is to play with the Phoenix (web framework) project.
I'm suspect my journey is rather common, I see Elixir developers comfortable with Erlang and vice-versa. Though, I'm sure each has a perference like a dominant hand. You'll find yours as you explorer this fantastic technology.
> I see Elixir developers comfortable with Erlang and vice-versa
I agree with this. I was an "in theory" fan of erlang for a long time, but was always put off by its syntax, which I don't find too pleasing. But after a lot of elixir, and kind of rubbing up against erlang anyway, you sort of can't help but learn it, or at least learn to read it. Once you start using things like ETS, for example, you're going to be reading erlang docs. By the time you even know about ETS, though, you've probably seen enough erlang that it's not scary anymore.
I do prefer elixir - but I admit it's purely a subjective, aesthetic preference. They're both good and I can imagine jumping back and forth as needed.
One thing I will say though is that once you've worked with the BEAM enough you ain't going back. You will rip my genservers out of my cold, dead hands.
I agree with this. I was an "in theory" fan of erlang for a long time, but was always put off by its syntax, which I don't find too pleasing. But after a lot of elixir, and kind of rubbing up against erlang anyway, you sort of can't help but learn it, or at least learn to read it. Once you start using things like ETS, for example, you're going to be reading erlang docs. By the time you even know about ETS, though, you've probably seen enough erlang that it's not scary anymore.
I do prefer elixir - but I admit it's purely a subjective, aesthetic preference. They're both good and I can imagine jumping back and forth as needed.
One thing I will say though is that once you've worked with the BEAM enough you ain't going back. You will rip my genservers out of my cold, dead hands.
I have been solidly in the just use Elixir camp, but I'm debating that on some new projects. For one, if you want a library to be used in both, it's best to write it in Erlang. Then Elixir can just directly call the functions or you could build Elixir-specific wrappers of the Erlang functions. The other is that Erlang just has a bit of simplicity and rawness about it that I like, not to mention it is the OG language. I would miss piping and variable name rebinding though.
At the end of the day, I do think that Elixir has the better tooling ecosystem. Mix, Hex, the formatter, Credo, ExUnit, Livebook, etc. are really nice.
At the end of the day, I do think that Elixir has the better tooling ecosystem. Mix, Hex, the formatter, Credo, ExUnit, Livebook, etc. are really nice.
Also, Phoenix and Liveview.
If your working on a distributed system, i think Erlang still has better tooling compared to Elixir. For example common test for integration/system testing and snabbkaffe for trace based testing.
Depends on the project, but let's say you're writing something that should or could be made a part of other projects. I might be mistaken and correct me if I'm wrong, but I think it might be easier for an Erlang project to be integrated into an Elixir one than the reverse.
I can speak on this a bit. I'm fairly new to Erlang, but the team I'm on has been using Erlang since before Elixir was created. So we've been doing Erlang just because it's what we've been using, and the team knows it, not Elixir.
However, we recently just decided to start new projects in Elixir rather then Erlang.
One argument a former team member would make against Elixir is that it has almost too many ways of doing things, in some cases. Erlang is a much simpler language. One example he used was sigils. Sure, they're nice, but it also means there's multiple ways to define a binary string, for example. Sometimes it is nice to have a single way to do something and not have to worry about making a decision about it. This example isn't great anymore though since Erlang is getting sigils in OTP 27.
Another argument I can think of is that Erlang is learning from Elixir. Erlang took its maybe expression from Elixir's `with`, and, IMO, the maybe expression is better. They're also adopting sigils.
But, like I said, we ended up deciding to go with Elixir for new projects, so I would be curious to see what reasons other people have for picking Erlang.
However, we recently just decided to start new projects in Elixir rather then Erlang.
One argument a former team member would make against Elixir is that it has almost too many ways of doing things, in some cases. Erlang is a much simpler language. One example he used was sigils. Sure, they're nice, but it also means there's multiple ways to define a binary string, for example. Sometimes it is nice to have a single way to do something and not have to worry about making a decision about it. This example isn't great anymore though since Erlang is getting sigils in OTP 27.
Another argument I can think of is that Erlang is learning from Elixir. Erlang took its maybe expression from Elixir's `with`, and, IMO, the maybe expression is better. They're also adopting sigils.
But, like I said, we ended up deciding to go with Elixir for new projects, so I would be curious to see what reasons other people have for picking Erlang.
What do you think is better about the maybe expression? Just curious, haven't looked into it too deeply and I thought it behaved exactly like when.
Well, I haven't written any Elixir yet, so I'm probably saying that without really knowing.
The main thing, and maybe I just am missing something, but I don't really understand what the point of the 'do' in Elixir's 'with' is? In Erlang you just have the maybe and anything that would go in that do block would just go inside the maybe expression. That seems a lot better to me.
I also just prefer the look of Erlang's maybe. I think maybe is a clearer name for what the statement is doing and the lack of the 'do' block looks better to me and makes it easier to read.
The main thing, and maybe I just am missing something, but I don't really understand what the point of the 'do' in Elixir's 'with' is? In Erlang you just have the maybe and anything that would go in that do block would just go inside the maybe expression. That seems a lot better to me.
I also just prefer the look of Erlang's maybe. I think maybe is a clearer name for what the statement is doing and the lack of the 'do' block looks better to me and makes it easier to read.
So you say `maybe` is better than `with` without ever using Elixir, and `with`? I hope your team is not full of people making blanket statements like this.
> I think maybe is a clearer name for what the statement is doing and the lack of the 'do' block
It's because basically everything in Elixir is a macro :), and the do block is an argument/parameter to that macro:
But it took me a very long to come to grips with this, too :)
It's because basically everything in Elixir is a macro :), and the do block is an argument/parameter to that macro:
maybe x do
...
end
# is really
maybe x, do: ...
# which ends up being a macro call with a named parameter
maybe(x, do: ...)
if x do
...
end
# is really
if x, do: ...
# which ends up being a macro call with a named parameter
if(x, do: ...)
But it took me a very long to come to grips with this, too :)
I think GP is talking more about the fact that you can have a do block, not about what it is.
Yeah exactly, in Erlang the 'do' portion would just go in the same code block as the conditionals.
I think that it would come down to personal/team preference. Maybe you need to create a library that can be used in both Erlang/Elixir, so it may make more sense to do it in Erlang.
Everything in this article about OTP, Supervision trees, etc. carries over to Elixir, just with slightly different syntax.
Everything in this article about OTP, Supervision trees, etc. carries over to Elixir, just with slightly different syntax.
Those two aren't even the only options. There's also Lisp-Flavored Erlang (LFE), and maybe other languages targeting the virtual machine BEAM.
https://lfe.io/
It's similar to a multitude of languages targeting the Java Virtual Runtime (JVM) -- functional, imperative, object-oriented, actor-based -- whatever you want, but they all produce interoperable bytecode.
https://lfe.io/
It's similar to a multitude of languages targeting the Java Virtual Runtime (JVM) -- functional, imperative, object-oriented, actor-based -- whatever you want, but they all produce interoperable bytecode.
also Lua in Erlang
https://news.ycombinator.com/item?id=29703949
https://news.ycombinator.com/item?id=29703949
I'm personally a big fan of Gleam.
Bringing static typing to the BEAM is like a dream come true!
It's a young language to be sure, but I see the potential. (Maybe don't bet your startup on it.)
Bringing static typing to the BEAM is like a dream come true!
It's a young language to be sure, but I see the potential. (Maybe don't bet your startup on it.)
I prefer the simplicity of Erlang, Elixir is a much larger language and has some quirks.
This is a great series of posts. I get so used to the erlang environment I forget to share the cool bits because they become normal