Re:Python at Netflix
by mixmastamyk on Tuesday April 30, 2019 @06:57PM
(#19792849)
These are not really an issue in vfx production and other things Python is used for.
It’s a problem for lots of things Python is used for, but maybe not vfx (whatever that is).
Re:Python at Netflix
by mixmastamyk on Tuesday April 30, 2019 @07:18PM
(#19792989)
They are using it for things it’s good at, for others they use java. So this subthread is largely a waste of time.
Who is “they”? What is your point?
Re:Python at Netflix
by mixmastamyk on Wednesday May 01, 2019 @11:44AM
(#19798156)
They is Netflix, and other post-production oriented users. You know, what this article and discussion is about?
It's not at all obvious that "they" refers to "netflix and other post-production oriented users", and your argument is a tautology "Python is good at the things that Python is good at". Obviously. The rest of us are debating what those things are or are not.
Re:Python at Netflix
by mixmastamyk on Wednesday May 01, 2019 @06:52PM
(#19802474)
The subject is well-trodden, there's not much to debate. Python is not good at threading, but works well in multiprocessing situations. Netflix is using it in the later situation, and not the former. Async is unlikely to be a use case either.
> The subject is well-trodden, there's not much to debate
And yet we see the same incorrect information trotted out over and over again.
"(yet)", but then it's still a dynamic language (no typing, not dynamic as in hip). The reason for python is mainly:
- it's easy to learn - we've go numpy
If I were to pick a language to build significant infrastructure with, I wouldn't choose python.
IIRC, I've only ever seen "unawaited coroutine found" (or similar) errors; I've never seen anything that points to a specific unawaited coroutine. In either case, a bug in prod is still many times worse than compile time type error.
> you can enable debug on the event loop and have it print out every time a coroutine takes longer than a configurable amount of time
I don't run my production servers in debug mode, and even when I do manage to find the problem, I have limited options for solving it. Usually it amounts to refactoring out the offending code into a separate process or service.
An extreme counterpoint is a language like Go which
1) Is roughly 100X faster in single-threaded, CPU-bound execution anyway
2) Allows for additional optimizations that simply aren't possible in Python (mostly involving reduced allocations and improved cache coherence)
3) Has a runtime that balances CPU load across all available cores
This isn't a "shit on Python" post; only that concurrency really isn't Python's strong suit (yet).