It's pretty strange to think that OOP cannot be implemented using a functional language. Various Lisps had several OO systems, and there's OCaml, where the "O" stands for "objective".
Objects are merely collections of partially-applied functions (or often procedures): methods are bound to `this` aka `self`, the instance. When you have a language where partial function application (currying) is a norm, you have little trouble implementing this approach.
What made OOP popular, things like good modularity and hiding of implementation details, has little to do with the "inheritance + encapsulation + polymorphism" trio proper. They can be and often are achieved without these.
What makes FP powerful is higher-order functions / function composition, immutable data / pure functions / referential transparency, and isolation of effects. Technically, all of these are easily available in most popular OO languages, and you can reap many benefits of FP writing in C#, Python, or even Java 8. But the standard libraries of most of them actively resist such usage, and the translators do not rely on the functional features heavily for optimization.
Where pure FP has trouble is e.g. large mutable structures with constant small mutations, like editing a bitmap in a paint program. Real-time stuff can also be harder, because the shape of the machine code is much less obvious than when using a lowest-possible-level language like C.
Since the real world is inherently effectful, there will always be a mix of approaches. Pick the right tool for the job; a job of any serious complexity will likely require multiple different tools.