[nickjj]

> Did you try asking on the forums?

Nope, I only looked up the Elixir solution for the sake of my reply here. I haven't worked with Elixir in like 9 months.

Based on the docs it says IP.Subnet.is_in only supports IPv4. The Python and Ruby solutions transparently support both. That kind of sums up my Elixir experience (ie. something might partially exist but to really use it will require a lot of extra work). It's also impressive at how infrequently the Elixir docs come up in Google searches. It's strange considering how many words are there and it's the official source of information for the language.

[throwawaymaths]

IP.subnet.is_in is a guard, so there are different constraints. You could still use the `in` keyword.

Honestly my experience with python has been "the solution you're looking for probably exists, but using it will require a lot of effort, and heaven help you if you need to debug someone else's code", but I have mostly dealt with Django which is a nightmare of hidden code and tensorflow. Maybe it's just I've worked with shitty python devs and on the other project Google's notoriously bad engineering practices in some of their public facing OS projects (angular, tf)

[nickjj]

> IP.subnet.is_in is a guard, so there are different constraints. You could still use the `in` keyword.

Does that mean you can do something to make it transparently support IPv4 and IPv6 even though the docs mentions it only supports IPv4? Will it be more than 1 line of code?

> Honestly my experience with python has been "the solution you're looking for probably exists, but using it will require a lot of effort..."

I found it to be the opposite approach. The last time I wanted to increment a counter outside of a nested loop in Elixir it sprawled into a multi-week conversation with the author of Elixir, a git repo with 100+ programming language examples to solve the same problem[0] and a proposal on potentially altering Elixir itself to make this process a bit easier. The Python solution was about 2 minutes typing into my code editor and moving on with life.

Elixir solution: https://github.com/nickjj/nested-data-structure-traversal/bl...

Python solution: https://github.com/nickjj/nested-data-structure-traversal/bl...

I'm not saying either language is better than the other but there's certain things that can done a lot easier in Python and on the flip side I'm sure there's things you can do a lot easier in Elixir.

I found in practice for me personally when building typical web apps I kept running into roadblocks left and right with Elixir where as I never had these issues with Python or Ruby. That's why I stopped using Elixir.

> I have mostly dealt with Django which is a nightmare of hidden code

I think that'll happen with any big framework, especially if you haven't contributed a ton of code to it. The Rails code base can be intimidating too and Phoenix's code isn't any more approachable to someone who isn't already at the high end of expert with the language.

[0]: https://github.com/nickjj/nested-data-structure-traversal

[throwawaymaths]

I mean to be quite honest I remember this problem and all I could think of was "this being hard is a sign that the data structure is poorly designed. But I also remember giving you a four line code sample using the process dictionary that you could have used, because this was "clearly an exceptionally pathologic data structure".

[nickjj]

Oh yeah I remember your reply (not word for word but the approach of using it). If you search around for using process dictionary it seems to go against the grain of Elixir since it introduces mutable state which is fundamentally against what the language provides. It did lead to much easier to understand code because it brings the language more in line with how other languages work where you can update a variable outside of a specific scope. Maybe it's a good example of the idea of "sharp knives" but applied to Elixir instead of Ruby.

I don't think the data structure was that crazy or rare. It boiled down to looping over 2 lists and wanting to keep an independent count of each one.