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

51–60 of 100 posts

Re: A Brief Guide to OTP in Elixir

#51

Post by jeremyjh »

jakeva wrote: post #24
freedomben wrote: post #22

> In a sense, supervisors are very similar to Kubernetes, but they work on the application level instead of the cluster level. Good article, and very worth sharing, but it could have done without that part. That's a terribly unhelpful analogy. For those who Kubernetes it's wildly misleading, and for those who don't it's meaningless.

I use both kubernetes and OTP supervisors and don't find it misleading, rather I quite agree but maybe I'm missing something. I'm curious what you mean by that?

You don't find it misleading because you already know what an OTP Supervisor's role is limited to, and you know that Kubernetes (among a thousand other things) also provides that one feature. But its not a good analogy since it can only be understood by someone who doesn't need it to be explained.

Re: A Brief Guide to OTP in Elixir

#52

Post by pselbert »

atonse wrote: post #15
nickjj wrote: post #9

> Forget using a million different technologies for things like background jobs, OTP can supply you with everything. It's true but in practice this usually doesn't pan out. For example with just background jobs alone there's the idea of queues, tracking failures / successes, exponential back-off retries, guaranteeing uniqueness, draining, periodic tasks and everything else you'd likely want in a production ready app.…

Yep exactly. We process millions of jobs using Exq, mainly because of the retry, persistence of jobs, etc. I don't want to risk leaving that in elixir only. We use Exq because I've used Sidekiq for years. I should check out Oban, since it could reduce the complexity in our stack (we wouldn't need redis anymore).

A lot of people have been moving from Exq to Oban. Come by the #oban channel on Slack if you have any questions.

Re: A Brief Guide to OTP in Elixir

#53

Post by fredliu »

IMO, Erlang/Elixir/BEAM/OTP really is the toolset that can be used to build what the mystical 10x/100x programmer can achieve. But that's also the reason why it's hard to push for its adoption into bigger teams. When the value proposition is "you can do all that by only using Erlang/Elixir/OTP...", while the alternatives are based on multiple, but more "traditional" and well-understood systems (which you are easier to hire for) ,"using one thing for all" sounds more like a risk (and potential tech/dev lock-in) than an advantage to the management. Love to hear success stories of how Erlang/Elixir are pushed into "mainstream" within a relative large org.

Re: A Brief Guide to OTP in Elixir

#54

Post by taywrobel »

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

Then they really need to pick a new name, because OTP is widely understood in programming to be a “One-Time Pad”, and without defining what they think it means in this context this is the least coherent article I’ve read in a while.

Re: A Brief Guide to OTP in Elixir

#55

Post by Thaxll »

fredliu wrote: post #53

IMO, Erlang/Elixir/BEAM/OTP really is the toolset that can be used to build what the mystical 10x/100x programmer can achieve. But that's also the reason why it's hard to push for its adoption into bigger teams. When the value proposition is "you can do all that by only using Erlang/Elixir/OTP...", while the alternatives are based on multiple, but more "traditional" and well-understood systems (which you are easier t…

The problem is that the runtime does too much magic and it's not portable / standard compared to other languages / runtimes. Lot of what BEAM/OTP is doing is done in other tools and it's language neutral.

Not everything is good tbh, when you see the pain it is to deploy an Erlang app in 2020 ...

Re: A Brief Guide to OTP in Elixir

#56

Post by cutety »

Thaxll wrote: post #55
fredliu wrote: post #53

IMO, Erlang/Elixir/BEAM/OTP really is the toolset that can be used to build what the mystical 10x/100x programmer can achieve. But that's also the reason why it's hard to push for its adoption into bigger teams. When the value proposition is "you can do all that by only using Erlang/Elixir/OTP...", while the alternatives are based on multiple, but more "traditional" and well-understood systems (which you are easier t…

The problem is that the runtime does too much magic and it's not portable / standard compared to other languages / runtimes. Lot of what BEAM/OTP is doing is done in other tools and it's language neutral. Not everything is good tbh, when you see the pain it is to deploy an Erlang app in 2020 ...

Regarding portability, I recently came across this project: https://github.com/spawnfest/bakeware

I haven’t gotten around to actually trying it myself, but it advertises that it can compile Elixir projects into a single binary you can copy, paste & run (on Linux & MacOS). It’s not the greatest solution, and the mentioned ~0.5s startup time doesn’t make it great for cli tools when compared to Go/Rust/C.

I’m mostly just happy to see there are people out there trying to make Elixir/Erlang easier to use, as much as I love the language, some of the tooling and deployment methods (releases) make me groan.

Re: A Brief Guide to OTP in Elixir

#57

Post by jaggirs »

taywrobel wrote: post #54
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

Then they really need to pick a new name, because OTP is widely understood in programming to be a “One-Time Pad”, and without defining what they think it means in this context this is the least coherent article I’ve read in a while.

Cryptography \neq Programming

Re: A Brief Guide to OTP in Elixir

#58

Post by dnautics »

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…

> the basic notion of the spawn -> receive -> loop cycle

I'm working on a video series about these concurrency patterns; even recorded the first one but the audio is bad so I'm going to re-record it before I publish it when some "real" audio equipment comes in (hopefully this weekend) - let me know what you think:

https://www.youtube.com/watch?v=eoEcpcLVumc

Re: A Brief Guide to OTP in Elixir

#59

Post by bcrosby95 »

jeremyjh wrote: post #2

I'd just like to point out that while knowledge of OTP is a good thing for an Elixir developer, it isn't really needed for most application development. There are excellent libraries and frameworks that leverage OTP to provide a lot of value to their users, and most of us who use Elixir in industry just use those libraries.

I'm working on a game backend (which I'm finding Elixir/Erlang pretty good for) and I don't see how I could reasonably do this without using my own GenServers.

I can see not writing my own GenServer for webapps, but when it comes to concurrency webapps tend to be dead simple. Elixir is a fine choice for these but I feel like its killer features don't shine that much over the alternatives.

Re: A Brief Guide to OTP in Elixir

#60

Post by oaferlanger »

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…

OTOH every decent erlang book or tutorial I've ready, from Armstrong's book[1] to Learn You Some Erlang[2] to Erlang and OTP in Action[3] and others all start off by introducing primitives like spawn, message sending , and receive.

They then introduce OTP and explain all the cases it handles.

I've never read a book or tutorial on OTP that just starts with OTP. In fact (a bit tangetially) whenever I encounter abstractions where I don't already understand the primitives I have a very difficult time. Maybe that's just the way my brain is wired though. I have a terrible time with OO programming for that reason. I much prefer a separation of functions and data because it's much easier for me to reason about what is happening.

Anyway, I agree that programmers should start with the primitives, but I've never seen anyone really teach OTP any other way.

Edit: also there are tools such as Erlang.mk[4] by Loïc Hoguin[5] that will handle a lot of the boilerplate for OTP projects and building releases, though it's good to do it manually at least once while learning.

[1] https://pragprog.com/titles/jaerlang2/programming-erlang-2nd...

[2] https://learnyousomeerlang.com/

[3] https://www.manning.com/books/erlang-and-otp-in-action

[4] https://erlang.mk/guide/index.html

[5] https://ninenines.eu/

Post reply on HN