[cavisne]

I guess their argument is the reason those things suck is because they are hooking in some c++ monstrosity (tensorflow) or making rpcs to an external daemon (redis, horovod).

So rather than writing another Python wrapper over c++ they are making a new performant language that can call Python.

To me it makes sense as torch is great and hard to compete with, but everything feeding into it is a mess today (Data loading, distribution logic).

[throwawaymaths]

> a new performant language that can call Python

don't forget the control layer/data layer separation principle. Performance mostly only matters at the data layer, and I don't believe that python ML really has a substantial problem with this, aside from not having a real distribution story. So "having a more performant python" doesn't really solve that much.

I'll tell you what could make the control layer better.

- no gil

- better async primitives

- immutability of passed parameters

- better testing story

- better documentation story (python is quite good at documentation, well, when python devs actually do it, which they usually don't).

- project-local dependencies with no shenanigans

[itissid]

> control layer/data layer separation principle

Could you explain or give references to what you exactly mean by this? I've heard of separation of concerns, but is this a specific realization of that principle?

[throwawaymaths]

Ugh. I misremembered terms. Look up control plane and data plane. This is well understood.