22 ms·

They are not. There is a reason why seasoned Erlangers all tell you to avoid the process dictionary. Erlang docs[0] say the following: > Note that using the Pr

They are not. There is a reason why seasoned Erlangers all tell you to avoid the process dictionary. Erlang docs[0] say the following: > Note that using the Process Dictionary: > - Destroys referencial transparency > - Makes debugging difficult > - Survives Catch/Throw > So: > - Use with care > - Do not over use - try the clean version first [0] https://www.erlang.org/course/advanced#dict https://www.erlang.org/course/advanced#dict

JohnHaugeland 6y ago
Hi, I'm a seasoned erlanger, and we do not all tell you that. The things you quoted and didn't write yourself are not real problems here. Erlang in general doesn't actually have referential transparency, and it's not clear why this author thought that it did. It's not clear why the process dictionary would "destroy referential transparency." Erlang doesn't have references, and the PD is just a storage model. Surviving catch/throw is a benefit, not a problem I'm not sure why this author is asserting that it "makes debugging difficult." That's just bullshit. What makes debugging difficult is state, and if you need to track state, switching storage methods won't make that easier. "Try the clean version first" - what do you imagine is the clean version here? You're just repeating things you don't understand, cargo cult style.
- nomacrospls 6y ago
  > Hi, I'm a seasoned erlanger, and we do not all tell you that. Seasoned Erlang developer here too (10+ years). First of all, the original post wanted to share data across requests. Given each request is typically handled in separate process, you simply cannot use the process dictionary to share this data. So your original comment completely missed the mark. Second of all, I would say most of the Erlang community actually agrees with the Erlang official documentation linked above. For example, for a long time, Cowboy had this in its README: > No parameterized module. No process dictionary. Clean Erlang code. And the reason is simple: the process dictionary is about state within a single process. This data cannot be easily shared (you can with erlang:process_info/2 but that adds a process lock). Therefore, most times people resort to the process dictionary is to pass data within a process, implicitly, and passing it functionally (the clean way) is often better. Using ets for the same purpose would also be frowned upon. The process dictionary should only be used almost exclusively for metadata. You probably won't be inclined to take my word for this, so here is a proposal: send a pull request to remove or update the linked notes above from Erlang/OTP docs and see how well it will be received.

JohnHaugeland 6y ago

Hi, I'm a seasoned erlanger, and we do not all tell you that. The things you quoted and didn't write yourself are not real problems here. Erlang in general doesn't actually have referential transparency, and it's not clear why this author thought that it did. It's not clear why the process dictionary would "destroy referential transparency." Erlang doesn't have references, and the PD is just a storage model. Surviving catch/throw is a benefit, not a problem I'm not sure why this author is asserting that it "makes debugging difficult." That's just bullshit. What makes debugging difficult is state, and if you need to track state, switching storage methods won't make that easier. "Try the clean version first" - what do you imagine is the clean version here? You're just repeating things you don't understand, cargo cult style.

nomacrospls 6y ago
> Hi, I'm a seasoned erlanger, and we do not all tell you that. Seasoned Erlang developer here too (10+ years). First of all, the original post wanted to share data across requests. Given each request is typically handled in separate process, you simply cannot use the process dictionary to share this data. So your original comment completely missed the mark. Second of all, I would say most of the Erlang community actually agrees with the Erlang official documentation linked above. For example, for a long time, Cowboy had this in its README: > No parameterized module. No process dictionary. Clean Erlang code. And the reason is simple: the process dictionary is about state within a single process. This data cannot be easily shared (you can with erlang:process_info/2 but that adds a process lock). Therefore, most times people resort to the process dictionary is to pass data within a process, implicitly, and passing it functionally (the clean way) is often better. Using ets for the same purpose would also be frowned upon. The process dictionary should only be used almost exclusively for metadata. You probably won't be inclined to take my word for this, so here is a proposal: send a pull request to remove or update the linked notes above from Erlang/OTP docs and see how well it will be received.