6 ms·

Yeah, elixir provides Registry which is what I use for simple state management or directly use ets. See below (jswny) for more clarification.

laser 6y ago
Unfortunately had a bug I found today in which an event_notifier genserver was calling a method that checked against the database for the the state of an Event, to decide whether to send a notification and then update the event to record that notifications were sent and upon successful update send the notifications. But in the query to construct the list of users that should be notified, the User module was not imported at the top of the file and the notifications were failing to send. Of course, if the path had ever been run, it would have obviously failed and been the simplest type of error to rectify. This is why it's generally not an issue and is actually nice as it gives you direct visibility into dependencies. But, on rare exception, when you don't test the path because it's dependent on time-dependent state and are overly confident in the suitability of the untested code you're deploying to production, you get bit by the compiler that quietly warns and lack of static analysis (oh nice writing this comment just made me discover https://github.com/rrrene/credo https://github.com/rrrene/credo)
- deallocator 6y ago
  You might also be interested in https://github.com/jeremyjh/dialyxir https://github.com/jeremyjh/dialyxir I use both dialyxir and Credo in my projects
- depr 6y ago
  You can run the compiler with --warnings-as-errors
jswny 6y ago
Can you explain what you mean about module naming? I’ve done a good amount of Elixir, and I’m puzzled because I don’t know what you are referring to at all. Most libraries and frameworks I’ve used enforce things on your modules via behaviors which have nothing to do with naming. Perhaps you are talking about naming functions for behaviors? Because I think it’s the same in most languages that “overridden” or “implementations” of functions for modules/classes that use some kind of interface must be named the same as the interface definition.
- searchableguy 6y ago
  > Perhaps you are talking about naming functions for behaviors? Because I think it’s the same in most languages that “overridden” or “implementations” of functions for modules/classes that use some kind of interface must be named the same as the interface definition. Yes. In typescript, you can have abstract classes or interfaces to implement which gives you more information (intellisense, visible errors, type information) and make the contract more explicit. I was trying out phoenix and I didn't get any hints about the methods to implement in the module. I was relying on documentation for that. If there was a way to say use @some_spec and get information about it in the editor. It would have helped out.
  - shadowfacts 6y ago
    The compiler will warn you about things like unimplemented functions that are required by behaviors, and there are plugins for various editors to display errors/warnings inline. There's also Dialyzer (and various IDE integrations) for some level of static type-checking.
    - JohnHaugeland 6y ago
      there are language features directly for this. no need to rely on compiler hints or dialyzer. elixir people really should learn erlang. if you ever saw a coffeescript person struggling to do things that are straightforward in js, because they didn't bother to learn js? that's what you're doing now
      - pjmlp 6y ago
        This is the main reason why I learn programming languages to broaden my knowledge, but when it comes to production code, only platform languages matter.
        JohnHaugeland 6y ago
        Well no, it's just that Elixir is built on Erlang, so everything Erlang has is in Elixir If you learn the base language, you get more powerful in the descendant language as well
JohnHaugeland 6y ago
If you learned Erlang, you'd realize these were both terrible choices, and that you ought to be in the process dictionary
- searchableguy 6y ago
  Can you explain more? I am looking at the answers from this stackoverflow question: https://stackoverflow.com/questions/1483550/in-erlang-what-are-the-benefits-of-using-ets-instead-of-process-dictionary-with/9819524 https://stackoverflow.com/questions/1483550/in-erlang-what-a... and the Erlang docs. I don't get the impression that they are comparable.
  - emerongi 6y ago
    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.

laser 6y ago

Unfortunately had a bug I found today in which an event_notifier genserver was calling a method that checked against the database for the the state of an Event, to decide whether to send a notification and then update the event to record that notifications were sent and upon successful update send the notifications. But in the query to construct the list of users that should be notified, the User module was not imported at the top of the file and the notifications were failing to send. Of course, if the path had ever been run, it would have obviously failed and been the simplest type of error to rectify. This is why it's generally not an issue and is actually nice as it gives you direct visibility into dependencies. But, on rare exception, when you don't test the path because it's dependent on time-dependent state and are overly confident in the suitability of the untested code you're deploying to production, you get bit by the compiler that quietly warns and lack of static analysis (oh nice writing this comment just made me discover https://github.com/rrrene/credo https://github.com/rrrene/credo)

deallocator 6y ago
You might also be interested in https://github.com/jeremyjh/dialyxir https://github.com/jeremyjh/dialyxir I use both dialyxir and Credo in my projects
depr 6y ago
You can run the compiler with --warnings-as-errors

jswny 6y ago

Can you explain what you mean about module naming? I’ve done a good amount of Elixir, and I’m puzzled because I don’t know what you are referring to at all. Most libraries and frameworks I’ve used enforce things on your modules via behaviors which have nothing to do with naming. Perhaps you are talking about naming functions for behaviors? Because I think it’s the same in most languages that “overridden” or “implementations” of functions for modules/classes that use some kind of interface must be named the same as the interface definition.

searchableguy 6y ago
> Perhaps you are talking about naming functions for behaviors? Because I think it’s the same in most languages that “overridden” or “implementations” of functions for modules/classes that use some kind of interface must be named the same as the interface definition. Yes. In typescript, you can have abstract classes or interfaces to implement which gives you more information (intellisense, visible errors, type information) and make the contract more explicit. I was trying out phoenix and I didn't get any hints about the methods to implement in the module. I was relying on documentation for that. If there was a way to say use @some_spec and get information about it in the editor. It would have helped out.
- shadowfacts 6y ago
  The compiler will warn you about things like unimplemented functions that are required by behaviors, and there are plugins for various editors to display errors/warnings inline. There's also Dialyzer (and various IDE integrations) for some level of static type-checking.
  - JohnHaugeland 6y ago
    there are language features directly for this. no need to rely on compiler hints or dialyzer. elixir people really should learn erlang. if you ever saw a coffeescript person struggling to do things that are straightforward in js, because they didn't bother to learn js? that's what you're doing now
    - pjmlp 6y ago
      This is the main reason why I learn programming languages to broaden my knowledge, but when it comes to production code, only platform languages matter.
      - JohnHaugeland 6y ago
        Well no, it's just that Elixir is built on Erlang, so everything Erlang has is in Elixir If you learn the base language, you get more powerful in the descendant language as well

JohnHaugeland 6y ago

If you learned Erlang, you'd realize these were both terrible choices, and that you ought to be in the process dictionary

searchableguy 6y ago
Can you explain more? I am looking at the answers from this stackoverflow question: https://stackoverflow.com/questions/1483550/in-erlang-what-are-the-benefits-of-using-ets-instead-of-process-dictionary-with/9819524 https://stackoverflow.com/questions/1483550/in-erlang-what-a... and the Erlang docs. I don't get the impression that they are comparable.
- emerongi 6y ago
  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.