For better readability I would pick #dig instead of the #[].

Like,

request.path.match(/\A\/(?<slug>(?!admin|assets)\w+)/)&.dig(:slug)

instead of

request.path.match(/\A\/(?<slug>(?!admin|assets)\w+)/)&.[](:slug)

It's ruby syntax, & calls to_proc on the object and passes the result as a block to the method.

An explanation from the pickaxe book, programming Ruby 1.9 and 2.0

Blocks Can Be Objects

Blocks are like anonymous methods, but there’s more to them than that. You can also convert a block into an object, store it in variables, pass it around, and then invoke its code later. Remember we said that you can think of blocks as being like an implicit parameter that’s passed to a method? Well, you can also make that parameter explicit. If the last parameter in a method definition is prefixed with an ampersand (such as &action ), Ruby looks for a code block whenever that method is called. That code block is converted to an object of class Proc and assigned to the parameter. You can then treat the parameter as any other variable. Here’s an example where we create a Proc object in one instance method and store it in an instance variable. We then invoke the proc from a second instance method.

class ProcExample

  def pass_in_block(&action)
    @stored_proc = action
  end

  def use_proc(parameter)
    @stored_proc.call(parameter)
  end
end

Use it like so

eg = ProcExample.new
eg.pass_in_block { |param| puts "The parameter is #{param}" }
eg.use_proc(99)

produces:

The parameter is 99

Expression Parsed But Not Executed

The argument to logger&.log isn't evaluated when logger.is_a?(NilClass) == true. Every Ruby expression that's evaluated should have an impact, so consider:

test = 1
nil&.log(test+=1); test
#=> 1

If the argument were evaluated by the interpreter, test would equal two. So, while the parser certainly parses the expression in your argument, it doesn't execute the inner expression.

You can verify what the parser sees with Ripper#sexp:

require 'ripper'

test = 1
pp Ripper.sexp "nil&.log(test+=1)"; test

[:program,
 [[:method_add_arg,
   [:call,
    [:var_ref, [:@kw, "nil", [1, 0]]],
    [:@op, "&.", [1, 3]],
    [:@ident, "log", [1, 5]]],
   [:arg_paren,
    [:args_add_block,
     [[:opassign,
       [:var_field, [:@ident, "test", [1, 9]]],
       [:@op, "+=", [1, 13]],
       [:@int, "1", [1, 15]]]],
     false]]]]]
#=> 1

This clearly shows that the parser sees the incremented assignment in the symbolic expression tree. However, the assignment is never actually executed.

I am arriving to the party a bit late here, the other answers have covered how it works, but I wanted to add something that the other answers have not covered.

Your question asks What is the difference between try and &. in Ruby. Ruby being the key word here.

The biggest difference is that try doesn't exist in Ruby, it is a method provided by Rails. you can see this or yourself if you do something like this in the rails console:

Copy[1, 2, 3].try(:join, '-')
#=> "1-2-3" 

However if you do the same thing in the irb console, you will get:

Copy[1, 2, 3].try(:join, '-')
NoMethodError: undefined method `try' for [1, 2, 3]:Array

The &. is part of the Ruby standard library, and is therefore available in any Ruby project, not just Rails.

This is because nil&.nil? is shorthand for nil && nil.nil?. This would evaluate to nil && true, which is then nil.

(nil && x).nil? always evaluates to true, for any value of x.

While the syntax has power, this specific case has some potential to become a 'gotcha' for a developer:

(stuff&.things).nil? => This produces true if stuff doesn't exist, or stuff.things returns nil.

vs. the below case:

stuff&.things&.nil? => This produces nil in every case except the case where stuff.things returns something other than nil, in which case it would return false.

Because of the difficulty in normal boolean logic of differentiating between false and nil, it is unlikely that this would make sense in normal logic.