All systems are OOP (i.e. mutable-state state machines, mutated through message-passing according to rules that are an opaque part of their own state) at some level.
Systems that don't describe themselves as OOP just have one "object": the OS process. This object is still there, and still has to pass messages through IPC, sockets, disk IO, etc.
(Or, if you drop the OS altogether and write a unikernel, your "objects" are [real or virtual] machines.)
This isn't an argument in favor of OOP as a be-all end-all paradigm for writing all your code in, mind you; it's just an argument against thinking you can have a language that has no OOP aspects whatsoever. Maybe you can, if that language only models pure, side-effect-free computations! (eBPF could theoretically be non-OOP, I guess?)
Systems that don't describe themselves as OOP just have one "object": the OS process. This object is still there, and still has to pass messages through IPC, sockets, disk IO, etc.
(Or, if you drop the OS altogether and write a unikernel, your "objects" are [real or virtual] machines.)
This isn't an argument in favor of OOP as a be-all end-all paradigm for writing all your code in, mind you; it's just an argument against thinking you can have a language that has no OOP aspects whatsoever. Maybe you can, if that language only models pure, side-effect-free computations! (eBPF could theoretically be non-OOP, I guess?)