[HN Gopher] OTP at a High Level (2019)
___________________________________________________________________
OTP at a High Level (2019)
Author : todsacerdoti
Score : 134 points
Date : 2024-02-19 17:06 UTC (5 hours ago)
(HTM) web link (adoptingerlang.org)
(TXT) w3m dump (adoptingerlang.org)
| asaph wrote:
| Am I the only one who saw the title and thought OTP was "one time
| password"?
| LoganDark wrote:
| Nope. Should really say "Erlang OTP" or something
| Zondartul wrote:
| 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."
| LoganDark wrote:
| Then maybe the acronym should just be expanded.
| Jtsummers wrote:
| The URL kind of gives away the theme of the site. And the
| first sentence starts with "Erlang/OTP".
| chefandy wrote:
| 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?
| LoganDark wrote:
| 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".
| Jtsummers wrote:
| "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.
| eindiran wrote:
| I clicked thinking it was going to be about one-time
| programmable memory.
| p1necone wrote:
| I read it as "On The Piss".
| LorenzoGood wrote:
| Just out of curiosity for anyone starting a new Erlang project:
| Why use Erlang over Elixir?
| mekoka wrote:
| 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.
| Miner49er wrote:
| 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.
| square_usual wrote:
| 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.
| Miner49er wrote:
| 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.
| troupo wrote:
| > 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: maybe x do ...
| end # is really maybe x, do: ...
| # which ends up being a macro call with a named parameter
| maybe(x, do: ...)
|
| Same goes for many (all?) other things in Elixir:
| if x do ... end # is really
| if x, do: ... # which ends up being a macro
| call with a named parameter if(x, do: ...)
|
| And so on.
|
| But it took me a very long to come to grips with this,
| too :)
| square_usual wrote:
| I think GP is talking more about the fact that you can
| have a do block, not about what it is.
| Miner49er wrote:
| Yeah exactly, in Erlang the 'do' portion would just go in
| the same code block as the conditionals.
| denvaar wrote:
| 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.
| waynesonfire wrote:
| 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.
| pmw wrote:
| 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.
| lawn wrote:
| 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.)
| lpil wrote:
| I would definitely bet my start up on Gleam!
| slekker wrote:
| Congrats on the upcoming v1 release!
| vegabook wrote:
| but does it have a REPL?
|
| Lots of BEAM's runtime interaction capability is lost
| without one.
| rdtsc wrote:
| 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.
| lolinder wrote:
| > 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": x = 10 closure = fn () ->
| x end x = 20 IO.puts closure.() # 10
|
| Contrast that with the otherwise equivalent JavaScript:
| let x = 10; const closure = () => x; x = 20
| console.log(closure()) // 20
|
| Shadowing allows you the convenience of reusing names
| _without_ the risk of a variable changing out from under you
| via spooky action at a distance.
| rdtsc wrote:
| 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.
| ramchip wrote:
| It's called rebinding, rather than mutation. Good
| background here:
|
| https://dashbit.co/blog/comparing-elixir-and-erlang-
| variable...
| rdtsc wrote:
| Thanks, but I prefer immutable data vs variables as
| opposed to introducing a new term. I think it's a bit
| simpler.
| lolinder wrote:
| 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
| bmitc wrote:
| 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.
| lpil wrote:
| I prefer the simplicity of Erlang, Elixir is a much larger
| language and has some quirks.
| crowdhailer wrote:
| 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
___________________________________________________________________
(page generated 2024-02-19 23:00 UTC)