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

71–80 of 100 posts

Re: A Brief Guide to OTP in Elixir

#71

Post by IggleSniggle »

dnautics wrote: post #45
rectang wrote: post #41

Earlier quoted context omitted.

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.

Importantly, all of those have a discernible pronunciation that is not simply stating the letters in order.

Re: A Brief Guide to OTP in Elixir

#72

Post by dnautics »

IggleSniggle wrote: post #71
dnautics wrote: post #45

Earlier quoted context omitted.

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

Importantly, all of those have a discernible pronunciation that is not simply stating the letters in order.

a very good point. That goes for GNU, too.

Re: A Brief Guide to OTP in Elixir

#73

Post by AlchemistCamp »

oaferlanger wrote: post #60
tlack wrote: post #29

Earlier quoted context omitted.

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 abstract…

> every decent erlang book or tutorial I've ready, from Armstrong's book[1] to Learn You Some Erlang...

What a coincidence! I just tweeted about how you can get it and 12 other various programming books for just $8 now: https://twitter.com/AlchemistCamp/status/1311796404830892032

Re: A Brief Guide to OTP in Elixir

#74

Post by arusahni »

probotect0r wrote: post #46
tlack wrote: post #29

Earlier quoted context omitted.

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.

Would you recommend the book?

Re: A Brief Guide to OTP in Elixir

#75

Post by toast0 »

simscitizen wrote: post #68
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.

At WhatsApp we had a bunch of mnesia-backed services. I can't say that it was the best experience. Pretty much anything non-trivial, such as healing a cluster after a partition, or expanding a cluster, or cross-DC replication was a complete PITA to do properly. There's also very few people that have operational experience with it and very little documentation about it compared to pretty much any other storage engine.…

I think we would have found any database to be a PITA at write volumes and data volumes we were using, with our expectations of availability. I don't think we would have been able to get that performance out of MySQL, or Postgres; and anyway, we didn't have a dedicated team for database management to make sure nobody wrote bad queries if we did. Sync, status and reg ran on MySQL and php when I started, and it was a lot easier to run them and scale them on Erlang, IMHO. Repartitioning MySQL like we repartitioned mnesia would be a lot harder, I think.

I'm not too worried about a lack of experts and documentation. If you operate at the limits, you'll just need to become an expert, and the source code will be your documentation; mnesia is all written in Erlang, and not too hard to follow; most people won't hit the limits of ets, I'd think. If you don't operate at the limits, you might not need an expert, and if you keep up with OTP releases and hardware releases, the limits get bigger every year.

Looking back, I think we should have spent more time earlier on using the hooks mnesia provides to make healing clusters take less effort; and maybe some automation on cluster expansion. Of course, WA never shied away from manual work by server engineers. :)

(Hmmm, now I'm trying to figure out you are, send me an email if you will :)

Re: A Brief Guide to OTP in Elixir

#76

Post by taywrobel »

carlmr wrote: post #64
taywrobel wrote: post #54

Earlier quoted context omitted.

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.

I never heard of your OTP, and I immediately knew which OTP they were talking about due to the Elixir keyword.

Do you program in elixir often?

Re: A Brief Guide to OTP in Elixir

#77

Post by bostonvaulter2 »

arusahni wrote: post #74
probotect0r wrote: post #46

Earlier quoted context omitted.

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.

Would you recommend the book?

Not the OP, but it is a great book, I'd highly recommend it.

Re: A Brief Guide to OTP in Elixir

#78

Post by lpgauth »

derefr wrote: post #61
tlack wrote: post #29

Earlier quoted context omitted.

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 agree. The reason we stick with OTP, is that OTP behaviors like gen_server handle two system-level concerns that "raw" Erlang code doesn't: 1. OTP behaviors integrate with the OTP supervisor lifecycle management system (i.e. the OTP framework offers the supervisors standardized hooks to start up and shut down your process, guaranteeing that the errors generated during such steps will be in a format the supervisor c…

Well, the sys behavior is easy to implement.

I also am not a fan of the complexity and overhead of gen_server so instead I use metal (http://github.com/lpgauth/metal). It's a simple receive loop with an optional init and terminate callback. It implement sys and can be supervised.

Re: A Brief Guide to OTP in Elixir

#79

Post by dnautics »

yetihehe wrote: post #6
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

> I wonder why other runtimes haven't adopted these features? Probably mainly due to shared memory. When you know your data can be modified only in one place, changing data structure is easier. Try changing a struct when some other code is using it. It would require a lock for every object in memory.

the fact that looping through a process is a tail call which by its very nature creates well-defined boundaries (both in "code segment" and in "data segment") also helps a gazillion. Try doing hot loading in the middle of a while loop... Not saying it's impossible, but you're not gonna have a good time.

Re: A Brief Guide to OTP in Elixir

#80

Post by tlack »

dnautics wrote: post #58
tlack wrote: post #29

Earlier quoted context omitted.

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

Pretty good!

I knew most of that stuff already so I can't speak to the pure education value, but it made sense, and I think you hit the key points.

I bet some visuals would help it make sense for total nooberz.

AND! I didn't know that about "v" - thanks! :)

Post reply on HN