nomacrospls
Joined 6 years ago
Karma
4
Submissions
4
Member since
Aug 9
Recent submissions
Comment · 6 years ago
Comment · 6 years ago
Can we also submit it via HN? If so, my understanding is that Pagerduty is running and long-term invested in Elixir (https://www.pagerduty.com/blog/elixir-at-pagerduty/) and Podium has migrated from Ruby to Elixir as the main stack (https://medium.com/podium-engineering/two-years-of-elixir-at...). Thanks!
Edit: oops, I see now it is the initial language. Indeed PagerDuty started using Elixir only later on. Although one could argue Elixir was part of Podium in its initial growth.
Comment · 6 years ago
Sure, my comment was specific to functional languages, and Python isn’t one.
Comment · 6 years ago
Macros are not really necessary and you don’t have to know the inner workings of everything for doing well with strings in Elixir.
The secret for working with strings in functional languages (or in languages with immutable strings) is to realize most operations, such as concatenation, end up copying the strings. So instead of saying “string1 concat string2 concat ...”, it is better to collect a list of strings and build one final string only at the end. Here is an Elixir specific article that goes more in-depth into this: https://www.bignerdranch.com/blog/elixir-and-io-lists-part-1...
Other languages may provide specific data-structures for this purpose, such as ropes, but in a nutshell that’s all there is to it.
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.