I think you mean Google is following the leadership of Chainer, like Facebook already does? PyTorch started as a Chainer fork. Its dynamic graph internals are all from Chainer.
It's not a bad thing. It's good for users. But give credit to the leaders in the field. If you make an iPod clone, you call it an iPod clone, not a clone of the Zume HD.
Chainer started it, was around years earlier, and it still has more users. So Google is not copying PyTorch, it's copying Chainer.
PyTorch use the same backend as torch (cutorch for GPU ...) But PyTorch use almost the same Python API than Chainer. On this point we can say PyTorch "copy" Chainer.
Based on your reasoning PyTorch is copying TensorFlow static optimizations and production capability with JIT and ONNX then? I've seen many folks requesting an imperative API.
You can't please everybody, as if they listen or not to users people still complain.
If both are making effort to improve themselves though, the community has only to benefit from this competitiveness.
I'm usually against this type of framework baiting, but being a tensorflow guy myself & having just spent the week coding with pytorch full time.... this is basically identical to pytorch
What are the strengths and weaknesses of each? I've been using keras but planning on diving into a real deal framework next. Tensorflow is appealing for the momentum it has in the community, but pytorch looks easier to learn.
Doing image classification, object localization, and homography (given an input image, which of my known template images is matches it and in what orientation).
I think Keras is a real deal framework. It provides a higher-level API than most other frameworks, but it has pretty sweet portability of models across frameworks and platforms and most research papers are implementable in Keras without too much trouble.
In my opinion, the real deal with Pytorch or Chainer, there are similar than numpy API. So the learning curve is flat. The NN construction part and gradiant part are specific but all the glue is regular python unlike Keras, tensorflow ...
(I'm author of the TF rnn api & tf.contrib.seq2seq)
There's a lot of work being done on this specific part. If you have a standard RNN architecture you want to run, you can probably use the cudnn code in tf.contrib.cudnn to get a super fast implementation.
There is some performance work that needs to be done on properly caching weights between time steps of an RNN if you use a tf.nn.RNNCell. Currently if you want to implement a custom architecture, or a seq2seq decoder, or an RL agent, this is the API you would want to use. Several of the eager benchmarks are based on this API; so that performance will only improve.
I'm hopeful that for the next major release, we'll also have support for eager in tf.contrib.seq2seq.