They both look ugly to me. Furthermore, there is a cognitive burden. There is nothing to think about in

  users.map{|u| u.name}

I even use to write it more explicitly as

  users.map{|user| user.name}

The short forms

  users.map{&:name}
  users.map{@1.name}

are like "oh wow, what does that mean?" and I've been using Ruby since 2005. And the ugliness...

It's not

  users.map{&:name}

but

  users.map(&:name)

The &something syntax to pass on a block is very old syntax to allow passing on a block that is reified as a Proc, it mirrors the syntax used to receive a block (if you don't want to use, or can't use yield, for example because you need to pass on the block to another method).

e.g.

   def apply_to_all(&callback)
     @all.each(&callback)
   end

or

   def initialize(a, b, c, &block)
     @a = a
     super(b, c, &block)
   end

The only thing that &:symbol adds is that it defines to_proc on Symbols to create a Proc object that sends the symbol to it's first parameter, you could define it yourself if Ruby didn't already, and in fact it was first defined by users of Ruby before it became part of Ruby core.

Definition:

   class Symbol
     def to_proc
        return Proc.new {|receiver| receiver.send(self)}
     end
   end

This definition allows `["1", "2", 3].map(&:to_i)` to work in Ruby 1.8.6, which otherwise doesn't support it.

Thanks. As you see I dislike that syntax so much that I never learned how to write it. It's not something I'll actively use.

I don't actually mind the syntax that much, `&` on a symbol just gives you a proc for calling `send` on the first argument. What bothers me is the limitations. If you're going to have special case syntax to avoid having a useless first argument why not go all the way?

Something like this would have made a lot more sense imo:

    users.map { .name.uppercase + '3' }
    numbers.map { * 3 }

The last one looks a lot like Haskell:

  map (* 3) numbers

The reason for the limitation is that it was existing syntax, with a different purpose (see the sibling post to yours).

The cognitive burden argument is completely subjective. If you’re used to point-free programming, the first short form probably requires less cognitive burden. To me, it makes way more sense to think about “map the users list over the function that returns name” rather than “map the users list over a brand new anaonymous function that takes a user and calls the name method on it.”

Another way to look at it is that cross-pollination is a good measure of the merit of a language feature. If one language invents it another a dozen other popular languages adopt it, it's probably a good idea, and its proliferation is good for everyone.