# Is it a good time for a PyTorch developer to move to Julia? If so, Flux? Knet?

**URL:** <https://discourse.julialang.org/t/is-it-a-good-time-for-a-pytorch-developer-to-move-to-julia-if-so-flux-knet/38453>\
**Category:** Machine Learning\
**Created:** [April 29, 2020, 10:07pm UTC](https://discourse.julialang.org/t/is-it-a-good-time-for-a-pytorch-developer-to-move-to-julia-if-so-flux-knet/38453 "2020-04-29T22:07:26Z")\
**Posts on this page:** 1\
**Showing post:** 47

<div class="post-metadata">

**Author:** ![ToucheSir](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/touchesir/32/14411_2.png) [@ToucheSir](https://discourse.julialang.org/u/ToucheSir)\
**Post date:** [January 10, 2021, 6:56pm UTC](https://discourse.julialang.org/t/is-it-a-good-time-for-a-pytorch-developer-to-move-to-julia-if-so-flux-knet/38453/47 "2021-01-10T18:56:37Z")

</div>

> [@anon92994695](#):
>
> Then when i go to train, I am pidgeon-holed into a single “train” idiom which is antithetical to this.

I’m of the somewhat extreme opinion that `train!` should be removed outright and Flux should only expose `gradient`/`pullback`. The one-function API looks nice on the surface, but it is horribly inflexible and obscures a lot of common errors that crop up in training loops. PyTorch seems to do just fine without one too, so it’s not like removing it will cause an unmitigated UX disaster.

---

_[View the full topic](https://discourse.julialang.org/t/is-it-a-good-time-for-a-pytorch-developer-to-move-to-julia-if-so-flux-knet/38453)._