Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Brief Guide to OTP in Elixir

serokell.io

Post reply on HN
Print view View original

41–50 of 100 posts

Re: A Brief Guide to OTP in Elixir

#41

Post by rectang »

dnautics wrote: post #36
rectang wrote: post #30

Earlier quoted context omitted.

Or "One Time Password" if you're an idiot like me. Gotta love an introductory article on "OTP" which even includes a section entitled "What is OTP?" but doesn't expand the acronym.

It's no longer considered a correct acronym as erlang is not really a telecoms language anymore. It's been a problem where outsiders are quick to think or say, "I am not writing a telecoms app" and dismiss it.

I understand this reasoning. The conclusion I draw is that "OTP" is truly a miserable name — like "car cdr" level bad.

As a newcomer to Elixir's OTP, I cannot divine that experts hold the opinion that the acronym expansion is misleading when that information is deliberately withheld. The first thing this article did was send me off to search the web.

Folks should use a backronym, like "Opinionated Threading Platform".

Re: A Brief Guide to OTP in Elixir

#42

Post by patrec »

riquito wrote: post #34
toast0 wrote: post #31

Earlier quoted context omitted.

> There's usually (almost always) durable storage required somewhere. Despite the name, mnesia can provide durable storage, without using anything outside of OTP and your nodes' (hopefully durable) filesystems.

Despite? It pretty much means "to remember", it doesn't have the alpha privative of amnesia, "to forget"

IIRC original name was Amnesia, but Joe was made to change it for marketing reasons (it's in one of his books or blog posts).

Anyway, I do not think Mnesia is a particularly good way to persist stuff, just use postgres.

Re: A Brief Guide to OTP in Elixir

#43

Post by dnautics »

toast0 wrote: post #33
thelazydogsback wrote: post #21

I assume because every process has its own GC that messages are always copied, even on the same node? AFAICT, there is no shared/copy-on-write messages in the BEAM, except for a few cases where you explicitly pass a shared byte buffer for special circumstances? I would think this is worth the cost in most cases, but for some workloads would be prohibitive.

Some binaries (byte buffers as you called them) are stored outside the process heap, and those are messaged by reference, not by copying; but all other terms are messaged by copying. This is a lot of copying, but it makes the GC very simple, so it's usually a positive tradeoff. Although, there's probably some use cases where it's not great. For those, it might makes sense to force things into the off process heap bin…

It is possible to create nif objects which are tied into the garbage collector and reference counted, and bound to a destructor function that gets called when the VM is done with it!

Re: A Brief Guide to OTP in Elixir

#44

Post by dnautics »

mrdoops wrote: post #17

OTP is definitely more of an expert's toolset than a framework for throwing together features quickly. This is a good thing because it's not trying to be more of an abstraction than necessary. With OTP you can make fault-tolerant, concurrent, self-healing applications that handle stateful operations with ease, but you'll still need a fair bit of need-to-know about the callbacks, how to manage process lifecycles, etc.…

Elixir already started the process of extending OTP: Task is a hugely important addition to the family of genserver, genstatem, etc.

Re: A Brief Guide to OTP in Elixir

#45

Post by dnautics »

rectang wrote: post #41
dnautics wrote: post #36

Earlier quoted context omitted.

It's no longer considered a correct acronym as erlang is not really a telecoms language anymore. It's been a problem where outsiders are quick to think or say, "I am not writing a telecoms app" and dismiss it.

I understand this reasoning. The conclusion I draw is that "OTP" is truly a miserable name — like "car cdr" level bad. As a newcomer to Elixir's OTP, I cannot divine that experts hold the opinion that the acronym expansion is misleading when that information is deliberately withheld. The first thing this article did was send me off to search the web. Folks should use a backronym, like "Opinionated Threading Platform"…

Back in the 90s there were plenty of programs which ditched their acronyms: elm, pine, pico, gnu, etc.

Re: A Brief Guide to OTP in Elixir

#46

Post by probotect0r »

tlack wrote: post #29
pmontra wrote: post #5

> In real life, we don’t need to write code with receive do loops. Instead, we use one of the behaviours created by people much smarter than us. I make more than half of my income from Elixir. That said, the naive receive loop is much easier to understand than any of the GenServer examples. They pollute the module logic with all that handle_* boilerplate. I believe that neither Erlang nor Elixir got the right abstrac…

What you said is rarely stated in public, but I've often felt it too: OTP obscures the underlying beauty of the Erlang platform. OTP is well engineered of course, but the basic notion of the spawn -> receive -> loop cycle is so clean and illuminating that I wish newbies would hold out before learning OTP sometimes. It's natural to think of case-specific abstractions around the primitives that are more germane to the…

I finished reading Elixir in Action a few days ago. This was probably the best part of that book. It takes you through building a primitive GenServer with basic processes before moving onto actually using GenServer. It specifically goes over tail recursion optimization before it introduces the receive do loop, which seems like a very important part of the whole thing.

Re: A Brief Guide to OTP in Elixir

#47

Post by Thaxll »

dmitriid wrote: post #39
Thaxll wrote: post #35

Earlier quoted context omitted.

Because why would you do that? Now we have tool and pipeline where testing / deploying ect .. is easy, so I'm not sure why would I risk to do hot load things. I don't think it's useful and I think it's pretty dangerous is the first place. You have code that can run two different things, wcgw.

A very erlang demo showed upgrading code running on a telephone switch without dropping the call. That's why you want hot code loading.

Because control plane does not handle anything phone related most likely? It's like upgrading Kubernates masters, your API servers still works and are not affected.

AFAIK Erlang code does not handle any network traffic, all of that is done in C/C++.

Re: A Brief Guide to OTP in Elixir

#48

Post by Jtsummers »

Thaxll wrote: post #35
abetlen wrote: post #3

OTP = Open Telecom Platform [1], though I think the full name is avoided nowadays. On an unrelated note, I've always been fascinated with the Erlang VM. The idea that you could hot-load modules and have multiple versions of the same module running at once seems really useful. I wonder why other runtimes haven't adopted these features? [1] https://en.wikipedia.org/wiki/Open_Telecom_Platform

Because why would you do that? Now we have tool and pipeline where testing / deploying ect .. is easy, so I'm not sure why would I risk to do hot load things. I don't think it's useful and I think it's pretty dangerous is the first place. You have code that can run two different things, wcgw.

Addressed in part by dmitriid and dnautics, but:

1. You can use this during development (where the tight feedback loop is very nice).

2. You can use this during deployment (after verifying that the process will work as intended, hopefully).

(1) is something you could do every day if it was your daily driver language. (2) would happen less frequently (well, as frequently as you deploy) but permit you to do partial updates without bringing the whole system down.

It's worth remembering that deploying Erlang (and Elixir) can be more like deploying with microservices or applications to an application server. You don't want to bring the whole thing down just to change out one part of the system, so you can update just the parts that have changed and need to be updated.

Re: A Brief Guide to OTP in Elixir

#49

Post by jeremyjh »

buzzerbetrayed wrote: post #25
jeremyjh wrote: post #7

Earlier quoted context omitted.

There are libraries that do this, like https://github.com/sasa1977/exactor but the Elixir community nowadays seems more conservative about macro "magic" than it was a few years ago. Sasa has written an entire book about OTP and if he doesn't recommend using his own library I wouldn't argue with him, but I haven't written a Genserver myself in years despite writing Elixir for a living the past 3.5 years. If you are go…

> There are libraries that do this, like https://github.com/sasa1977/exactor At the very top of the Extractor readme: > I don't maintain this project anymore. In hindsight, I don't think it was a good idea in the first place. I haven't been using ExActor myself for years, and I recommend sticking with regular GenServer instead :-) This both confirms what you said about the Elixir community shying away from macro magi…

Right, thats why I said he doesn't recommend using his own library. My point is people have been down this road, and moved away from it, not that anyone should use it.

Re: A Brief Guide to OTP in Elixir

#50

Post by jeremyjh »

tlack wrote: post #29
pmontra wrote: post #5

> In real life, we don’t need to write code with receive do loops. Instead, we use one of the behaviours created by people much smarter than us. I make more than half of my income from Elixir. That said, the naive receive loop is much easier to understand than any of the GenServer examples. They pollute the module logic with all that handle_* boilerplate. I believe that neither Erlang nor Elixir got the right abstrac…

What you said is rarely stated in public, but I've often felt it too: OTP obscures the underlying beauty of the Erlang platform. OTP is well engineered of course, but the basic notion of the spawn -> receive -> loop cycle is so clean and illuminating that I wish newbies would hold out before learning OTP sometimes. It's natural to think of case-specific abstractions around the primitives that are more germane to the…

> spawn -> receive -> loop cycle is so clean and illuminating that I wish newbies would hold out before learning OTP sometimes

Yes it is neat and its fun to play with but it isn't usually something you want to use in production code. In production code it is important to have processes linked correctly so that errors propagate to callers. GenServer.call handles this for you, and also clarifies intent (blocking call to another process that must respond or fail).

Post reply on HN