mikejm

Is an Elixir GenServer so different from an Object of a Class?

I am just learning Elixir. The purpose is to build a server API to interact between clients and a separate database server. I am coming from C#/C++.

I have now been reading a variety of tutorials on GenServer, as that seems to be the best point to start. It has been the first thing I’ve read about that truly makes sense in that it explains how to do truly practical tasks.

If I am understanding correctly, something that says use GenServer becomes not much different once started than an object of a class. The main differences I see is are:

All internal variables must be stored within state, typically as %{} so you can store numerous data points as key-value.
Thus the only mutable variable inside the GenServer is state (but this is really not any big difference as you can store as many variables of any type as you like within that).
Every time one of the major functions of a GenServer type process is called (start_link, cast, call), this just triggers the callback to reference state again and allow you to mutate it or run other functions.
GenServer as a Behavior basically acts as a standard basic Elixir version of a Class you can derive from to accomplish things needing internal state maintained.

Am I wrong? It seems once you start understanding it, it’s just a different way of accomplishing the same thing.

I guess this design of storing all functions inside state and just having very few simple functions to start a process helps keep it more generic or maybe contributes to things being better able to regenerate itself? Plus the Supervisor system to let each run more autonomously?

It also seems like pid is the same as having an object reference. As I understand it every process (ie. object) gets a pid by which it can be referenced and that is how the system tracks these things. You can also give them names which have to be unique, again like objects.

Am I correct that these things are not that different and analogous in the ways I described?

If I am not wrong, I think Elixir would be well served by having an explanation of how concepts and roles are analogous to in object oriented programming. For example, I found this tutorial:

https://medium.com/@roydejong/elixir-a-primer-for-object-oriented-programmers-fd5ef0206943

Although he explains some things well, I think he makes it overall even more confusing. For example, he states that modules are “stateless”. At no point then does he explain how it is possible for anything in the language to maintain any type of state (which is obviously necessary for anything to get realistic done - how can an application or server or process or object do anything without storing its state?).

It would be much better in my opinion to say that the primary differences in these regards are that in Elixir:

“All functions take arguments as values not references.”
“Elixir at its simplest uses what are essentially derivations of GenServer to handle states in the same way you usually would with an object of a class. All variables of the process/object should be lumped inside state inside there.”

Something like that (if remotely true) makes a lot more sense than just saying it is “stateless” or has nothing analogous to “references” which obviously makes no sense. It obviously must hold/transform variables/state in some way and we must have some way of referring to all our processes (objects) in some way.

Am I understanding the basic analogies? Any thoughts?

26 comments

#variable #beginner #object-oriented #state

124 2696 26

2023-12-12 20:06:44 UTC

Most Liked

jhogberg

Erlang Core Team

One thing I don’t see mentioned in this thread is agency: a GenServer (or rather its process) is not a passive entity that is acted upon like in “traditional” OO languages, but an active one that can act entirely on its own.

This is very useful when working in domains where you have lots of objects that act independently of each other. Trying to manually juggle tons of different passive objects to simulate them being active is not an easy task.

Post #8

rvirding

Creator of Erlang

sodapopcan:

The key thing is to let go of the idea that modules and processes are in any way related. While they do work together, modules are indeed just stateless bags of functions, and processes are used to run those functions and store state. While an object has its state encapsulated within its instance and only the methods defined on its class can operate directly on that state, processes can call functions from any module and have its state altered by any of them. So a process is like an instance, yes, but there isn’t a single module that controls its state. The gen server pattern does indeed associate a single module with a process, but there is nothing forcing that—you could put functions in that same module that are called by unrelated processes. All use GenServer does is metaprogram some functions into your module that are called by a process.

I think that this is something that must definitely be stressed. There is no way that processes and modules are related or have some inherent connection. Any process can use any module and any module can be used by any process. So as someone later pointed out I can have functions in mu GenServer module which can be called by other modules or used by other GenServers or processes. This is not something you should be very careful if you do it but there is nothing stopping from doing it.

And remember GenServers are just normal processes, there is nothing special about them. It is the same with modules.

Actually Erlang/Elixir is a very egalitarian system, all processes are created equal and all modules are equal.

EDIT: I can for example kill any process in the system I want. The fail safe and unstoppable way of always crashing the system is:

iex(1)> init = Process.whereis(:init)
pid<0.0.0>
iex(2)> Process.exit(init, :kill)
System process <0.0.0> terminated: killed

Crash dump is being written to: erl_crash.dump…done

And no, there is no way of prohibiting this!

Post #24

kokolegorille

Erlang might be the only object oriented language because the 3 tenets of object oriented programming are that it’s based on message passing, that you have isolation between objects and have polymorphism.

Joe Armstrong, creator of Erlang