I dont know the answer to your question but just a small note, this is not the lambda syntax.

The lambda syntax would be fn a, b -> a + b end

What you mention is the capture operator which is similar to method reference in java/kotlin

Ruby lambda syntax is lambda { |a, b| a + b } which is far from pretty IMHO. You probably meant block syntax, but that is slightly different from lambdas, as you can have only one block, with that fancy pants syntax, per function call. So it is not fully apples to apples.

Not to bikeshed (except that I’m gonna) but I do agree the &elem(&1, 2) is a little jarring even though I do use it sometimes It’s a bit of a tough example for me to judge because I find elem/2 jarring

I do this kind of thing with abandon:

Enum.find(users, &(&1.name == "Bob"))
Enum.map(users, & &1.id)

I see users so &1 must be a user because even though naming is hard, it’s not that hard

Also, the odd time I need an identity function (almost always as a parameter default) I like & &1 as a nice little concise option, as in:

def foo(thing, mapper \\ & &1)

fn x -> x end just looks like someone made a mistake to me. Of course, the best option is likely &Function.indentity/1. You’re still using a capture there, but it’s the nice capture syntax and clear as day.

I do also do stuff like this:

update(socket, :users, &[user | &1])

I can’t explain it but that looks totally fine to me, again, so long as there is clear naming. It also certainly makes a difference if it’s used in a common pattern or not.

I work solo, though. I wouldn’t fight anyone too hard on any of this stuff in a team situation.

One thing I never use (anymore) is &2. &2 can heck off!

Would the ruby syntax support multiple function heads? I wouldn‘t expect there‘s a clear way on how that would be handled.

Ruby now has collection.map { _1 } so clearly they were a little jealous of Elixir

But ya, highly subjective.

I actually prefer Elixir’s since you don’t have to invent a variable name, even if just one letter. It makes refactoring that much more smooth.