PyTorch Landscape

5/19/2026 at 7:19:57 AM

I work on differentiable geometric optics with PyTorch. Seeing a list like this is really illustrative of the power that PyTorch provides when you start considering it like a general purpose GPU-enabled state of the art numerical optimization framework.

One thing I wonder is why no one has made a fork of PyTorch yet that removes all the API surface that doesn't produce GPU friendly code. Make dtype and device arg mandatory without defaults, remove in place operations that trigger a CPU sync, etc. This would increase confidence that written code will run on the GPU and pass torch.export() on the first try.

by fouronnes3

5/19/2026 at 9:51:51 AM

Rather than forking PyTorch (which has issues like continually needing updates), could you create a set of linter rules instead?

by jamessb

5/19/2026 at 8:12:53 AM

It's useful to be able to run models/code on the CPU or split between CPU and GPU, especially for models that cannot fit into the GPU's VRAM, if you are running multiple models, or if you have training data that you need to move between CPU and GPU.

by rhdunn

5/19/2026 at 10:42:17 AM

All of that would be possible with the changes parent poster proposes. See the gotchas section in JAX, which is exactly these limitations:

https://docs.jax.dev/en/latest/notebooks/Common_Gotchas_in_J...

by earthnail

5/19/2026 at 5:56:11 PM

> One thing I wonder is why no one has made a fork of PyTorch yet that […]

Try and compile the stack from source and you'll find out why nobody is making forks with small divergences.

by WhyNotHugo

5/19/2026 at 2:37:46 PM

Seems like you could write a simple source code checker program to check all of that. Making an extra library just for some (user hostile) tweaks seems like overkill.

by DonsDiscountGas

5/19/2026 at 2:50:28 PM

Hi!

I'm curious to hear about your work geometric optics with PyTorch. May I ask you to share some examples of something you are working on right now?

by northzen

5/19/2026 at 9:17:40 AM

What is sad is that: - many projects are arrived. - It is unclear who is responsible for the updates.

I work on one of the projects in the list, need to update a link to the project, as old one is not actual anymore. And unclear how to do it => at least with respect to my project Albumentations, the landscape is outdated :(

--- Also, added the project to the Pytorch Ecosystem many years back, but if you ask me about practical value of being the part of the Ecosystem, I would not be able to tell you anything useful.

by ternaus

5/19/2026 at 1:16:31 PM

We do try to check the pulse of projects there with a checklist, but I guess it started in a more uncoordinated way.

If you file an issue here, I think it would work to update things:

https://github.com/pytorch-fdn/ecosystem

by t-vi

5/19/2026 at 5:46:34 PM

It is already there.

Submitted 3 weeks ago: https://github.com/pytorch-fdn/ecosystem/issues/67

by ternaus

5/19/2026 at 8:36:39 AM

I work on one of the projects featured in the PyTorch Ecosystem [1] and I really recommend it to anyone working on a PyTorch library. Their team is really responsive and they even offer promotion on their blog & social media.

[1] https://github.com/deepinv/deepinv

by jeremyscanvic

5/19/2026 at 10:46:13 AM

Interesting to see that PyTorch has become the de-facto standard after it seemed for a while that the dust had settled on Tensorflow.

I also thought that Jax would in turn take over after PyTorch but it never seemed to quite take off (still in use though from what I can tell).

by lvncelot

5/19/2026 at 1:21:04 PM

I'm a computational mathematician, and I've been a big proponent of JAX to all the research groups I've worked with. So far, I've converted all of them =). In particular for math, I've found JAX's design and feature set to be far more suitable. Patrick Kidger's suite of libraries also carries a lot of weight in that regard. Equinox is the center is basically everything I write in JAX.

But there are absolutely pain points. In particular, especially for weaker programmers (common in academia), it's quite easy to write bad JAX. The functional programming and stateless paradigms require a little more thinking ahead. This is particularly tough when you're doing research and you're, in real time, finding out what's ahead!

by trostaft

5/19/2026 at 11:39:27 AM

JAX is brilliant for research but the debugging story is still rough compared to PyTorch. eager mode + native Python exceptions win for most people.

by cold_harbor

5/19/2026 at 11:42:59 AM

> after it seemed for a while that the dust had settled on Tensorflow.

Did it ever? PyTorch always seemed more popular to me, unless you were around Google people, then obviously everything was Tensorflow. But like many Google projects, I never got the impression it was as ubiquitous as PyTorch out in the community outside of Google. Maybe around 2018-2019 it felt like Tensorflow would become more popular than PyTorch eventually, but it never seemed to actually happen.

by embedding-shape

5/19/2026 at 2:35:22 PM

I never worked at Google, and that (tensorflow dominant) was my impression from 2016-2022 or so. I'm pretty sure if you teach Google trends for awhile it's the same picture; tensorflow was way more popular than pytorch but as DL grew, pytorch grew faster (in terms of users).

by DonsDiscountGas

5/19/2026 at 5:01:04 PM

[dead]

by crisp-snakey

5/19/2026 at 5:02:07 PM

TF had first mover's advantage, so they felt like the incumbent for a long time, with PyTorch being the scrappy challenger.

by jszymborski

5/19/2026 at 11:34:16 AM

The compiler based approach, with jax.cond, purity expectations, difficulty of making stateful abstractions, etc makes sense for large scale deployment, especially to purpose built accelerators like the systolic array ones (tpu, trainium) but not for being the primary framework used in the field. Imperative always wins. Side effects and state are necessary.

by porridgeraisin

5/20/2026 at 3:03:36 AM

why did tensorflow not gain traction? out of the loop here

by vivzkestrel

5/19/2026 at 1:17:19 PM

Not sure about the link, the official landscape URL seems to be this (same data probably):

https://landscape.pytorch.org/

by t-vi

5/19/2026 at 9:05:47 AM

Pyro is really cool if you're into probabilistic programming languages, but the Numpyro is significantly faster iirc.

by ViscountPenguin

5/19/2026 at 11:57:29 AM

Pytorch3D is flagged as archived even though it isn't on GitHub.

by kombine

5/20/2026 at 8:16:45 PM

That’s expected. Any inactive projects are archived.

by electroshock

5/19/2026 at 7:23:19 AM

Interesting to see clearml but not its bigger counterpart mlflow

by d3m0t3p

5/19/2026 at 7:29:21 AM

Great stuff, thanks for posting.

by yurimo

5/19/2026 at 9:30:32 AM

[dead]

by reserve