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

Elixir GenServer Explained

papercups.io

Post reply on HN
Print view View original

61–70 of 91 posts

Re: Elixir GenServer Explained

#61

Post by Quekid5 »

JohnCurran wrote: post #34

This line in the opening paragraph really rubs me the wrong way: > “I'm ashamed to say most of my Elixir education has been through trial and error, figuring things out as I go along“ This attitude is so prevalent in software as if we are all supposed to be divined with programming knowledge the moment our IDE spins up. In every other industry that’s exactly how you learn: Get your hands dirty, make mistakes, and fix…

> There’s a lot of things wrong with software engineering - harboring this attitude that self-taught learning is bad or shameful makes it unnecessarily worse

This is an interesting question.

There's nothing wrong with being an autodidact, per se, but in my experience in hiring people and working with autodidacts: Autodidacts are not very good at recognizing their own limitations[0] and they usually do not have a lot of breadth of knowledge outside their area of interest. This can even go so far as not knowing that there is such a thing as "Entire Field of Study Foo". (Let's say Foo is Discrete Mathematics.)

Will they be bad hires? It depends on what you need -- and they can absolutely perform as well or better than any "more educated" person. It very much depends on the actual person... as almost all work does.

[0] This explicitly ties into the second point about breadth of knowledge. It's about knowing what you don't know and are willing to research further. The problem with autodidacts is often that there's such an insane leap from "oh, i know this" to a seemingly totally unrelated field which has deep connections to what you're doing. That's what a "broad" education in CS is there to teach you. Are you going to use all of that? Hell no! But just maybe that 5% you do end up using makes up for the 95% you don't.

Re: Elixir GenServer Explained

#62

Post by xutopia »

GenServer is just one of the numerous things in the Elixir ecosystem that just bring joy. Once you I got the concepts behind Ecto and GenServers everything just felt easy to model in my mind. I find it so nice.

Re: Elixir GenServer Explained

#63

Post by silly-silly »

edisonywh wrote: post #32
jimbokun wrote: post #5

Since these insert events are being buffered, what happens if the process dies? Are all of those inserts lost? I feel like Erlang/Elixir is designed to handle cases like this robustly, but it's not clear to me how this code avoids losing data when a process crashes, potentially up to 5s worth of updates!

The article touched on it briefly, but perhaps it wasn't clear. If the process dies, the Supervisor invokes the `terminate/2` callback so you're still able to process events. Here are the relevant lines: https://github.com/plausible/analytics/blob/b724def948d51a0f... Keep in mind you need to trap exit signal to tell the supervisor to invoke the callback, as done so here: https://github.com/plausible/analytics/blob/b7…

I use this callback to capture the 'data' that caused the crash, so that it can be used to recover later or better understand why the crash happened.

If I have as significantly long transaction, I can restart the transaction from transaction_id + 1 forward and then handle the actual transaction out of band by hand if its something very odd.

I usually insert a logger in these code paths too, but the crash handler is usually after the logger, which makes it easier to reason what has happened if you are dealing with mutable state.

Re: Elixir GenServer Explained

#64

Post by silly-silly »

therein wrote: post #16
jimbokun wrote: post #5

Since these insert events are being buffered, what happens if the process dies? Are all of those inserts lost? I feel like Erlang/Elixir is designed to handle cases like this robustly, but it's not clear to me how this code avoids losing data when a process crashes, potentially up to 5s worth of updates!

Furthermore I have heard it is actually possible for casts to be dropped under load. I am having a hard time confirming this, and had a hard time confirming it back then too. And even worse, I realize most of the time we code as if the casts will be reliably delivered. Can someone chime in on this?

Erlang casts are always delivered, or the sender crashes before that point.

Re: Elixir GenServer Explained

#65

Post by argvargc »

intergalplan wrote: post #3

Maybe a dumb complaint, but I hate the name. I have a really hard time not reading it as the active name "Generate Server". Like, I'd expect it to be a function that generates servers (whatever that means, since what it's dealing with isn't something I'd normally call "a server" either). It bugs the hell out of me every time I read Elixir code. One of those things I have to keep reminding myself: "OK, it's not what i…

It's a terrible name, anything starting with the abbreviated prefix "Gen" is hopelessly ambiguous. Is it "Generate"? "General"? "Generic"? "Genetic"? "Genesis"? While some would certainly be less frequently encountered, all can easily be found in programming context. When seeing "GenXxxxx" I could well understand someone feeling immediate brain-fog.

That said, this is one of very few criticisms I can level at Elixir, and it's a tiny part of the eco-system - literally, one single name. I wonder would it be easy to alias?

Re: Elixir GenServer Explained

#66

Post by lostcolony »

sbrother wrote: post #57
lostcolony wrote: post #42

Earlier quoted context omitted.

100% I consider the couple years I built systems in Erlang to be fundamental for me. It's affected, for better and worse, my entire approach to system design, at every level. It's meant the stuff I or (now that I'm in management) my teams tend to write is incredibly resilient (compared with the other teams in the department), but also meant that I have a really hard time with any Silicon Valley interview.

I 100% agree with this, but would add that actually in my case I feel like it has helped with Silicon Valley style interviews. Architecting a single BEAM application involves a lot of the same thought processes that go into designing any resilient distributed system so I have felt well prepared for any design questions. Additionally, being forced to write algorithms with immutable data structures, recursion and expli…

Specific design questions, yes. The "45 minute to design a system" ones, not so much. The hard part of those is not getting too bogged down in details, and this just means I have one more, extremely important, likely unappreciated by the interviewer, detail I can get bogged down in: what happens when things fail.

Re: Elixir GenServer Explained

#67

Post by ammanley »

Thank you so much for sharing this. I've not yet finished a decade in the industry, nor ever laid an eye on Elixir before, and this made sense pretty quickly. Great job explaining it all!

On a side note, its pretty amazing to see the impact on readability and understanding that native language features have on something like async. I've worked with similar systems to the example in the past in JS/Go/etc, and while you can definitely do the same stuff presented here, it tends to be a far messier callback-hell ime. For lack of better explanation, this Elixir code just "flows" better to my eye, which I know is a completely subjective and non-helpful unsolicited piece of info. Thanks again.

Re: Elixir GenServer Explained

#68

Post by dnautics »

ammanley wrote: post #67

Thank you so much for sharing this. I've not yet finished a decade in the industry, nor ever laid an eye on Elixir before, and this made sense pretty quickly. Great job explaining it all! On a side note, its pretty amazing to see the impact on readability and understanding that native language features have on something like async. I've worked with similar systems to the example in the past in JS/Go/etc, and while yo…

Oh that's so funny, because I'm an elixir user and we all claim that genserver (internal) organization is terrible.

But yes, it is way better than callback hell... It just could be better still.

Re: Elixir GenServer Explained

#69

Post by dnautics »

dasil003 wrote: post #59
hinkley wrote: post #21

Earlier quoted context omitted.

I'm talking about the name GenServer, not brobinson's response. There is the corollary: If we have not seen farther, it is because giants were standing on our toes. There's a huge degree of cognitive dissonance on these issues. Just because something had a reason in the past doesn't mean we have to keep doing it forever. Also "nobody understands" why people keep re-inventing wheels. It's not all hubris, at least not…

I am not very deep on Elixir, but I have heard of some substantive complaints about GenServer as a specific implementation and the cultural effects of the community say "just use GenServer" which shuts down discourse around why it might not be appropriate or at least optimal for all the cases it's recommended. We should absolutely have those discussions. I'm just not sure how many problems are solved by picking a bet…

I think the community typically says "don't use genserver" more than "just use genserver"

Re: Elixir GenServer Explained

#70

Post by Osiris »

lostcolony wrote: post #66
sbrother wrote: post #57

Earlier quoted context omitted.

I 100% agree with this, but would add that actually in my case I feel like it has helped with Silicon Valley style interviews. Architecting a single BEAM application involves a lot of the same thought processes that go into designing any resilient distributed system so I have felt well prepared for any design questions. Additionally, being forced to write algorithms with immutable data structures, recursion and expli…

Specific design questions, yes. The "45 minute to design a system" ones, not so much. The hard part of those is not getting too bogged down in details, and this just means I have one more, extremely important, likely unappreciated by the interviewer, detail I can get bogged down in: what happens when things fail.

What happens when things fail is an absolutely critical part of design / architecture. It's disappointing that interviewers works consider that an unimportant detail.
Post reply on HN