Another lesson about the dangers of relying on a separate team to maintain core part of your software. Not that using dependencies is a bad thing, but one should still be aware of what tradeoff they are making.

In terms of a new backend, there's uber's pyro [1] that's based on pytorch, and then there's Edward [2] that's based on tensorflow (and I think recently got integrated into tensorflow repo). Would be interesting to see pyMC adopt MXNet as its backend. I'm sure Amazon will become a heavy user and might sponsor the development. Or at least the authors will be able to get jobs there without a whiteboarding interview phase.

[1] https://github.com/uber/pyro [2] http://edwardlib.org/

It's probably not as easy a swap as tensorflow, but stan would be a natural fit for bayesian inference, and its NUTS sampler should be very performant.

http://mc-stan.org

Our team migrated from Theano to Tensorflow more than a year ago and the transition was pretty natural as both frameworks share very similar design philosophies. I never used PyMC myself, but Tensorflow seems like the natural replacement in this case.

That's unfortunate. I used theano for some voter analysis projects, that some friends needed.

I liked it quite a bit.

For experimenting, I think the imperative paradigm (define the graph by running it) makes for much faster experimentation and requires a lot less boilerplate code.

All big DL frameworks (TF, PyTorch, MXNet, Chainer) are now either imperative or have an imperative API in the works.