18 ms·

Our Ruby / Rails agency tried implementing a project in Elixir. After 3 weeks we stopped the experiment and re-did everything in Ruby. What stopped us was not

Our Ruby / Rails agency tried implementing a project in Elixir. After 3 weeks we stopped the experiment and re-did everything in Ruby. What stopped us was not so much the lack of libraries, but programming ergonomics. E.g. when using keyword lists for function options, callers need to pass the keywords in the exact same order. Also mocking was difficult in tests. Elixir is a great project with a friendly community, it just didn't work for us. YMMV so by all means try it out if you're interested!

dnautics 6y ago
> E.g. when using keyword lists for function options, callers need to pass the keywords in the exact same order. That's not generally true in the language. Were you trying to pattern match options in your own functions? Newbies to the language can get excited about the pattern matching feature and try to apply it in places where it's not right (well I may be projecting there). > Also mocking was difficult in tests. This is true. Were you using Mox? Mox makes things considerably easier at the cost of some boilerplate, with the added benefit that you can run concurrent mocks. You also have to not think of mocks in elixir like Ruby, they are very different. I'm sorry I wish someone more experienced with Elixir could have helped onboard you.
mapcars 6y ago
>when using keyword lists for function options Proplists should be replaced with maps pretty much everywhere. >Also mocking was difficult in tests Interesting, what exactly was difficult? You just replace one function with another.
- pavel_lishin 6y ago
  > Interesting, what exactly was difficult? You just replace one function with another. I'm not the person you're asking, but iirc, that replacement is global - so once you replace function/module X with MockX, you can't test X itself, nor anything else that relies on X.
  - dnautics 6y ago
    This is 100% correct, and a very huge pain point, and why you're supposed to use Mox, which solves that problem (arguably in a more conceptually "correct" fashion than ad-hoc Ruby Mocks). Admittedly there is a very steep learning curve, but it's worth it, because once do it you start to be able to do things you can't do in any other PL (not even erlang). It's a pity that the elixir community doesn't make this clearer, because I'm seeing "not being able to Mock" be a common complaint.
    - jeremyjh 6y ago
      It probably depends more on where they are coming from. Mox has more overheads for sure than options in Ruby or Javascript. Its more like mocking in Java or C++; where you declare an interface(behaviour), program against that, and then use dependency injection to load the mock or real code at the right time. I'd been working with Elixir for several years when I first tried using Mox and it still took awhile to get my head around it and figure out how to integrate it into our project. I would not be surprised to hear that newer teams really struggle with it.
      - dnautics 6y ago
        > I would not be surprised to hear that newer teams really struggle with it. I completely agree. Not having an expert Elixirist able to help me: It took me a full six months of fooling around with Mox (and a cryptic feature announcement in the 1.8 release) to really dig into and grok it. At this stage in my elixir experience, I have even PR'd a feature that's been integrated into Mox, so it's not completely incomprhensible, it's a super-well-written library. Honestly, It's a totally (alien/from-the-future)-technology (in both the good and bad senses) library. The bad senses could be almost trivially fixed with an in-depth, free, online video masterclass or, hell, even a conference lecture on it, and blog posts. More people that really know how it works should blog about how amazing Mox is. Unfortunately, I suspect that the people who are using Mox to its fullest extent are too busy pushing code to prod, ha.
    - mapcars 6y ago
      >and why you're supposed to use Mox, which solves that problem I never used that Mox and never had a need to. I just use `Mock` which allows `passthrough` as I stated in another comment, what other clarity is needed I don't understand. Can you give any example of the problem you can not solve instead of pitiness?
59nadir 6y ago
> E.g. when using keyword lists for function options, callers need to pass the keywords in the exact same order. This would've been fixed by creating a map from the passed in list, which would remove the order dependency but still keep the ergonomics of a keyword list, or just querying the keyword-list with `Keyword.*` functions. Not that big of an issue, to be honest, and not a showstopper. There are much bigger issues with the language, but Ruby doesn't offer any upsides in those cases either.

dnautics 6y ago

> E.g. when using keyword lists for function options, callers need to pass the keywords in the exact same order. That's not generally true in the language. Were you trying to pattern match options in your own functions? Newbies to the language can get excited about the pattern matching feature and try to apply it in places where it's not right (well I may be projecting there). > Also mocking was difficult in tests. This is true. Were you using Mox? Mox makes things considerably easier at the cost of some boilerplate, with the added benefit that you can run concurrent mocks. You also have to not think of mocks in elixir like Ruby, they are very different. I'm sorry I wish someone more experienced with Elixir could have helped onboard you.

mapcars 6y ago

>when using keyword lists for function options Proplists should be replaced with maps pretty much everywhere. >Also mocking was difficult in tests Interesting, what exactly was difficult? You just replace one function with another.

pavel_lishin 6y ago
> Interesting, what exactly was difficult? You just replace one function with another. I'm not the person you're asking, but iirc, that replacement is global - so once you replace function/module X with MockX, you can't test X itself, nor anything else that relies on X.
- dnautics 6y ago
  This is 100% correct, and a very huge pain point, and why you're supposed to use Mox, which solves that problem (arguably in a more conceptually "correct" fashion than ad-hoc Ruby Mocks). Admittedly there is a very steep learning curve, but it's worth it, because once do it you start to be able to do things you can't do in any other PL (not even erlang). It's a pity that the elixir community doesn't make this clearer, because I'm seeing "not being able to Mock" be a common complaint.
  - jeremyjh 6y ago
    It probably depends more on where they are coming from. Mox has more overheads for sure than options in Ruby or Javascript. Its more like mocking in Java or C++; where you declare an interface(behaviour), program against that, and then use dependency injection to load the mock or real code at the right time. I'd been working with Elixir for several years when I first tried using Mox and it still took awhile to get my head around it and figure out how to integrate it into our project. I would not be surprised to hear that newer teams really struggle with it.
    - dnautics 6y ago
      > I would not be surprised to hear that newer teams really struggle with it. I completely agree. Not having an expert Elixirist able to help me: It took me a full six months of fooling around with Mox (and a cryptic feature announcement in the 1.8 release) to really dig into and grok it. At this stage in my elixir experience, I have even PR'd a feature that's been integrated into Mox, so it's not completely incomprhensible, it's a super-well-written library. Honestly, It's a totally (alien/from-the-future)-technology (in both the good and bad senses) library. The bad senses could be almost trivially fixed with an in-depth, free, online video masterclass or, hell, even a conference lecture on it, and blog posts. More people that really know how it works should blog about how amazing Mox is. Unfortunately, I suspect that the people who are using Mox to its fullest extent are too busy pushing code to prod, ha.
  - mapcars 6y ago
    >and why you're supposed to use Mox, which solves that problem I never used that Mox and never had a need to. I just use `Mock` which allows `passthrough` as I stated in another comment, what other clarity is needed I don't understand. Can you give any example of the problem you can not solve instead of pitiness?

59nadir 6y ago

> E.g. when using keyword lists for function options, callers need to pass the keywords in the exact same order. This would've been fixed by creating a map from the passed in list, which would remove the order dependency but still keep the ergonomics of a keyword list, or just querying the keyword-list with `Keyword.*` functions. Not that big of an issue, to be honest, and not a showstopper. There are much bigger issues with the language, but Ruby doesn't offer any upsides in those cases either.