5 ms·

Straight Erlang is not hard to debug. Functional language, little shared state, and much behavior in apps (for the Erlang geeks: pun intended) is based on messa

Straight Erlang is not hard to debug. Functional language, little shared state, and much behavior in apps (for the Erlang geeks: pun intended) is based on message passing between processes, which is very well defined. That said, it gets much more complicated if you are using ETS or Mnesia (which builds on ETS), because now you have shared state, and that state has a rich API with lots of things that could be happening.

toast0 9y ago
ETS interactions can be modeled as sending calls to a database server (but faster), you can use the debugging hooks to list all the calls to ets too. My recommendation is to not do database reads and writes willy nilly all over the place, but to actually send sensible messages to a real server process, that does the interfacing with the database. Sometimes, it's useful to cheat and read ets directly, but it's really nice for writes to go through a server process, because the server process's mailbox provides an ordering for your writes, and you get to skip all the complexity of overlapping writes. In an mnesia system, that means writes should go to only one of the peers. (If you can divy up the writes to different servers based on the keys or something, then you can also divy up the servers onto different nodes). All that said, distributed systems give rise to emergent behavior, but that's true if you program them in erlang, c, or assembly; it's just a little easier to get to crazy big systems in erlang. :)
- Communitivity 9y ago
  Agreed, on all points, and that's basically what I do usually. I typically have a gen_server with a behavior defined data access and update message API, then that gen_server is the only process that can access a Mnesia table. I've seen a lot of code that doesn't do that though, and you still need to debug the gen_server if something goes wrong. If you use the gen_server approach though it is much easier to debug.

toast0 9y ago

ETS interactions can be modeled as sending calls to a database server (but faster), you can use the debugging hooks to list all the calls to ets too. My recommendation is to not do database reads and writes willy nilly all over the place, but to actually send sensible messages to a real server process, that does the interfacing with the database. Sometimes, it's useful to cheat and read ets directly, but it's really nice for writes to go through a server process, because the server process's mailbox provides an ordering for your writes, and you get to skip all the complexity of overlapping writes. In an mnesia system, that means writes should go to only one of the peers. (If you can divy up the writes to different servers based on the keys or something, then you can also divy up the servers onto different nodes). All that said, distributed systems give rise to emergent behavior, but that's true if you program them in erlang, c, or assembly; it's just a little easier to get to crazy big systems in erlang. :)

Communitivity 9y ago
Agreed, on all points, and that's basically what I do usually. I typically have a gen_server with a behavior defined data access and update message API, then that gen_server is the only process that can access a Mnesia table. I've seen a lot of code that doesn't do that though, and you still need to debug the gen_server if something goes wrong. If you use the gen_server approach though it is much easier to debug.