3 ms·
That's a good introductory article in that it starts from a very basic idea of just an assignment and ends up with a gen_server. This explicit state management
by rdtsc 7y ago
That's a good introductory article in that it starts from a very basic idea of just an assignment and ends up with a gen_server.
This explicit state management and immutability is very nice in large applications. You can see what is happening in a piece of code just by looking at the local context (a function or a module) since you'd have the initial state, the update operation, and the new state. If something goes wrong, tracing just that function can often reveal the error. Contrast that to an implicit "this" object with multiple levels of class inheritance, then things become a lot more complicated.
Further, when it comes to state management, process heap isolation is invaluable. If something goes wrong, you can safely restart just some parts of the application without leaving others in an unknown state. Operating systems have figured this out many decades ago, and going back to concurrency units that share a single heap feels like we are back in the Windows 3.1 world, where your calculator crashing also took down your editor.
- yomly 7y ago>You can see what is happening in a piece of code just by looking at the local context ^ This. A thousand times this. When I read this article, all I could think was _this_ is what object oriented code is meant to be about, aka message passing. I have been working on a Rails codebase and it's an absolute nightmare - without knowing everything all at once you can come to a tiny class that has a bunch of identifiers set via inheritance or somehow used via inflection. It's completely mad. Not meaning to start a flame-war but it confuses me how OO went from a simple idea of encapsulated "objects" having well defined interfaces to this crazy spaghetti mess of inheritance etc. That said, bad code is bad code and you can ship a ball of mud in anything...