Is this code idiomatic Elixir/functional?

What exactly does that mean? It’s not technically a function, no, because it has a side-effect. The reality of Erlang & Elixir is that there can be side-effects in procedures anywhere. Pure functions in these languages are an ideal; something to strive for, not law.

It’s also not law in Haskell, for example, but is clearly marked as happening, at least. I would suggest not fretting about using side-effects in Elixir. Instead, pay attention to where you can do without them by passing data. Don’t do this to blindly follow ideals, but to get code that can be used in any context and with predictable results.

You won’t really get pure functions that do operations on databse, files, environment variables etc. etc.

the reason is that they interface with impure external environment. So I do not think there is anything wrong from that point of view in your code.

So my code is ok?

Can you show me please an example?

The essential quality of a “pure” function is that it always has the same output for the same inputs.

You could make your function pure by passing in the state of the database and returning the state of the database, However, that’s not really practical. But you should strive to have anything you operate on in the function passed in as an input, rather that magically appearing from the ether.

def delete(DB, values )  do
     Kernal.apply(DB, :delete_all, values )
end 

This makes the code much easier to test and also limits the side effects to as small a surface area as possible. There is obviously a trade-off between adding needless complexity and applying this principle. To misquote Terry Pratchett

That’s why there are rules, so you’ll think a bit before you break them.

Hey there. Your function is generally fine, but has a couple of style issues. First, it’d be clearer to use Enum.any? instead of lenght(values) > 0. Not only is this more readable, we don’t actually care what the length is, so long as there’s at least one item. No point in counting them all.

Secondly, you should just return :ok instead of {:ok}. There’s no point in wrapping it in a tuple.

With these changes in mind, your best bet is something like:

def delete_db(values) when is_list(values) do
  if Enum.any?(values) do
    Repo.delete_all(values)
  else
    :ok
  end
end

Well, with refactoring in mind it might be better to simply do this:

def delete_db([]) do
  :ok
end

def delete_db([_h | _t] = values) do
    Repo.delete_all(values)
end

It’s short, splits the procedure up into cases neatly and asserts structure at the same time.

As a final tweak, you can have the second clause just be def delete_db(values) because the only way it gets there is if it isn’t an empty list. You could add when is_list(values) if you really wanted to as well

Think of it this way:

If something needs updating, let’s say a map of some keys and values, you could conceivably have a process that guards that state and the way you interact with it is to send messages to that process in order to modify the data.

When you use this model you run the risk of having the process crash on you, possibly losing state while doing so, and also having the data modified at any point because other processes can also change the state. What you’ve effectively created is something like a reference to the state you want to work with. Sure, when you have it in your hand you can trust that it’s the same state you got from the KV process, but you can never trust that you have the “correct” data in the sense that it’s the updated one.

The BEAM is great in that your particular piece of memory that holds the data you have can’t be changed by anything else, so that’s great, but putting too many things in processes and calling stateful functions with them will still invite harder debugging.

If you had a function that modified the map and then passed that map to the function as an argument everything that that function relies on is inside that function. It doesn’t make any assumptions about the world; for example that a KV store is running somewhere.

It’s trivial to emulate stateful constructs in Elixir, but we generally never set out to do so unless it’s really needed. The point is to make the least amount of assumptions possible about what exists when you run something. The ideal is for everything that a function touches to be something it’s given up-front.

The possible issue is that you’re not necessarily asserting that it should be a list if you ended up using only values, yeah. I prefer code to be as assertive as possible about structure and constants if possible. If something in the function itself makes the assumption that lists are passed in, we should try to make things that don’t follow that crash horribly, IMO.

On a related note: I vastly prefer the structural form to is_list().