Python at Netflix

Post by driverdan » Tue, Apr 30, 2019, 8:34 PM UTC

rifung wrote: post #184

jimmaswell wrote: post #41

Earlier quoted context omitted.

As someone who has worked on fully remote game dev volunteer projects for nearly 10 years, it's unbelievable how much the cultural inertia of physical presence has prevented companies from making the rational move of eliminating all possible office space in favor of remote work and skype meetings. So much money wasted on rent, security, and upkeep and so much time (and even lives) lost to commuting when there isn't a…

Even though I would absolutely prefer to work remotely, I have to disagree with you. I find that there are significant benefits to working in the same physical location. It's just way easier to go to someone's desk and ask them something than to have to set up a video chat. Human interaction is just naturally an in person thing. So much is lost if you can only video chat. Sure it may not affect the work directly but…

Post by driverdan » Tue, Apr 30, 2019, 8:39 PM UTC

pletnes wrote: post #120

butterpeanut wrote: post #76

Id like to contribute to the netflix code base by offering what is obviously a missing but much needed piece of code: def enableAutoPlay( flag ): annoyingAutoPlay = flag return

Afaik you can disable autoplay in the options?

Post by badpun » Tue, Apr 30, 2019, 9:04 PM UTC

markbnj wrote: post #165

gvd wrote: post #111

I fail to understand the use of python in a distributed environment while the language has such poor concurrency support (on top of the lack of a type system). You can make your application HA, but they are obviously not trying to squeeze out every CPU cycle.

> I fail to understand the use of python in a distributed environment while the language has such poor concurrency support (on top of the lack of a type system). You can make your application HA, but they are obviously not trying to squeeze out every CPU cycle. You're conflating several things that are orthogonal imo. A system can be distributed without concurrency. A concurrent system need not be distributed. Either…

Post by jnwatson » Tue, Apr 30, 2019, 9:10 PM UTC

y3sh wrote: post #204

weberc2 wrote: post #167

Earlier quoted context omitted.

Even if your app is IO bound, Python's concurrency is painful. Because it's not statically typed, it's too easy to forget an `await` (causing your program to get a Promise[Foo] when you meant to get a Foo) or to overburden your event loop and such things are difficult to debug (we've had several production outages because of these class of bugs). Never mind the papercuts that come about from dealing with the sync/asy…

And that even with async you're still bound by the GIL

Post by jnwatson » Tue, Apr 30, 2019, 9:14 PM UTC

weberc2 wrote: post #167

gshulegaard wrote: post #126

Earlier quoted context omitted.

> I fail to understand the use of python in a distributed environment while the language has such poor concurrency support Because it's a distributed environment probably is exactly why. Python has (arguably) great concurrency support apart from Multi-threading. https://www.youtube.com/watch?v=MCs5OvhV9S4 So if you need concurrency in the context of a single thread, then Python's GIL is a non-starter. But a distribut…

Even if your app is IO bound, Python's concurrency is painful. Because it's not statically typed, it's too easy to forget an `await` (causing your program to get a Promise[Foo] when you meant to get a Foo) or to overburden your event loop and such things are difficult to debug (we've had several production outages because of these class of bugs). Never mind the papercuts that come about from dealing with the sync/asy…