This piece is kinda stupid written from a not-so-good understanding of what really goes on. Something a career blogger or grifter would write. Or maybe its wri

This piece is kinda stupid written from a not-so-good understanding of what really goes on. Something a career blogger or grifter would write. Or maybe its written by ChatGPT, who knows! This piece lacks insight and depth of understanding. For example, SO volume should not be taken into account at all as the primary place for PyTorch discussions is the PyTorch forums. Another thing TF users and even founders like to gloat on is pip install numbers. PyTorch suggests conda and that's the default on their site. For TF, it's pip. For any reasonably complicated workflow, TF would still be the way to go, and same is the case from edge AI deployments. The biggest pro for TF is not the API, or the ease, or any inherent good-ness, it's its ecosystem. Google payrolls a lot of people to float and maintain the ecosystem. I know a bunch of them. The biggest pro of PyTorch is its inherent goodness, and it is by far the better thing to use for your deep learning experiments or prototype. I have written PyTorch production code before, and it keeps getting easier. And worked flawlessly on simple enough systems, out of the box, even 2.5/3 years ago. If you are a researcher, or anyhow, an experiementer in any way, PyTorch is no-brainer. For TF, the use case is in end-user facing applications. Even new research from Google AI/Brain/DeepMind doesn't use TF in almost any projects, they use JAX or something written on top of it, like Haiku, Flax, etc. Personal note: the early libraries got real sweet "hacker" feeling to them. The core engineers always respond to your problems, they ship features based on requests, and spinning something up based on JAX feels real easy and nice. It’s a PyTorch and/or JAX future now. Julia gets a lot of love on HN, but very little amount of people even think about it Deep Learning academia/industry.