Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Python Programming Entertainment

Netflix Says Python Programming Language is Behind Every Film You Stream (zdnet.com) 202

The next time you're streaming on Netflix, you can thank popular programming language Python and the developers who use it for much of the experience. From a report: According to Python developers at Netflix, the language is used through the "full content lifecycle", from security tools, to its recommendation algorithms, and its proprietary content distribution network (CDN) Open Connect, which ensures that content is streamed from network devices that are as close as possible to end users. Ahead of the Python Software Foundation's PyCon conference next week in Cleveland, the streaming giant has been detailing how it uses the open-source language.
This discussion has been archived. No new comments can be posted.

Netflix Says Python Programming Language is Behind Every Film You Stream

Comments Filter:
  • by Anonymous Coward on Thursday May 02, 2019 @04:08AM (#58525770)

    Python is a childs language... all non compiled languages are for children.

    • by Freischutz ( 4776131 ) on Thursday May 02, 2019 @04:21AM (#58525804)

      Python is a childs language... all non compiled languages are for children.

      More precisely, Pythos is a (relatively) user friendly language that provides bindings into a whole slew of code that was written in compiled languages. In that sense it stands on the shoulders of that (mostly compiled C/C++) code and the people who wrote it. It always cracks me up when people talk about something like: "the Python implementation of OpenCV". OpenCV is written in C/C++, Python just provided bindings for you to use OpenCV libraries written in a compiled language. Real code that is performance critical is written in compiled languages.

      • Re: (Score:3, Interesting)

        by h33t l4x0r ( 4107715 )
        Right. Python is always the right tool for people who don't know any other langage.

        Which is 99% of all Python programmers.
        • Python is the a pretty good tool for gluing actual code together.

          • Python is the a pretty good tool for gluing actual code together.

            Right, that's how I think of Python, as glue. I don't hate it or anything, I use Python a lot and prefer it to Bash scripting for example where I spend too much time figuring out how to get simple stuff done due to the syntax of BASH scripts which is nothing like anything else I regularly use. Python is just faster for that sort of stuff. However, I'm not going to write something like OpenCV in pure python.

            • I use bash and I wish I didn't.

              If someone would invent Python with { and } or begin and end or, well, something I'd be all over it. But I can't be arsed to count things I can't see.

              C with a sprinkling of popen() is looking rather tempting.

              • If the indentation is what annoys you about it, then that's good because indentation is one of the least important things. If you've got an editor that randomly interchanges hard tabs with spaces then either reconfigure that editor or get a better one. If you stick to all spaces or all tabs then you don't need to count anything. If you really need the braces for a deep seated need then try Ruby.

                • If the indentation is what annoys you about it, then that's good because indentation is one of the least important things.

                  Huh? It's the main thing, and it's shite. Indentation is for communicating with humans. Actual visible things are for communicating with the compiler. By making one thing do two jobs is does at least one of them poorly.
                  By the way, there isn't universal agreement among humans about how to indent, so making it a syntactic feature is already pissing people off who prefer the other way.

                  I

                  • Any indentation works in python, just be consistent. One space, 8 spaces, tabs, etc. It doesn't tell you how to indent, just that you need to indent. The original design was that this would look like pseudo-code, as written by hand on a white board perhaps. It's not even the first language that did this. If a programmer is already using consistent indentation in other languages then the transition ot python is straight foward (you can even cheat by using #{ and #} but you still need to indent correctly)

                    • It doesn't tell you how to indent,

                      If I want an if statement, then I have to indent everything governed by it by the same amount. Then for the first line not governed by it, go back to the same indentation as before.

                      In C-likes I can put the opening brace of the body on the same line. I can put it on the next line. I can put the whole statement on one line if I want. I probably wouldn't, usually, but in bash I sometimes do this for debug code because it's easy to comment/uncomment it.

                      It doesn't tell

              • It's called Perl.

            • Exactly. There's a lot I like about Python as a scripting or "glue" language, although I find that its use of white space for flow control is a common source of bugs. My C++ code gets carefully formatted, but even when you try and carefully format your Python code it's pretty easy to make an error that interprets, but executes in a way you didn't intend.

          • If you're scripting in a server or desktop environment (not counting weird web stuff like javascript), then you have only a few practical choices that have reasonable maturity or portability. Perl, python, and ruby. Perl is nice but difficult to read and has an atypical syntax with lots of shortcuts. Python and ruby remain as solid programming languages with mostly similar characteristics. If you know one you can learn the other in short order. (Bash is almost in the list but it really requires external u

      • How many C Developers are going to rewrite OpenCV or OpenCL.... They are going to use the already made library as well, and bind to them.

        The real critical code is done in Assembly and then linked to machine code, especially when you need to access particular parts of the hardware, or need to do a calculation with minimum amount of waste. Now you are confusing C/C++ which is a lower level language with other compiled languages. We had BASIC compilers, Pascal Compilers, FORTRAN compilers... Where the langua

    • by DeBaas ( 470886 ) on Thursday May 02, 2019 @04:29AM (#58525824) Homepage

      meanwhile, Blockbuster is almost done with compiling their streaming service. Can't wait, must be so awesome when that runs on compiled code! Finally a streaming service for adults!!
      ehm wait, that came out wrong....

    • by Anonymous Coward on Thursday May 02, 2019 @04:39AM (#58525846)

      Master Foo once said to a visiting programmer: “There is more Unix-nature in one line of shell script than there is in ten thousand lines of C.”

      The programmer, who was very proud of his mastery of C, said: “How can this be? C is the language in which the very kernel of Unix is implemented!”

      Master Foo replied: “That is so. Nevertheless, there is more Unix-nature in one line of shell script than there is in ten thousand lines of C.”

      The programmer grew distressed. “But through the C language we experience the enlightenment of the Patriarch Ritchie! We become as one with the operating system and the machine, reaping matchless performance!”

      Master Foo replied: “All that you say is true. But there is still more Unix-nature in one line of shell script than there is in ten thousand lines of C.”

      The programmer scoffed at Master Foo and rose to depart. But Master Foo nodded to his student Nubi, who wrote a line of shell script on a nearby whiteboard, and said: “Master programmer, consider this pipeline. Implemented in pure C, would it not span ten thousand lines?”

      The programmer muttered through his beard, contemplating what Nubi had written. Finally he agreed that it was so.

      “And how many hours would you require to implement and debug that C program?” asked Nubi.

      “Many,” admitted the visiting programmer. “But only a fool would spend the time to do that when so many more worthy tasks await him.”

      “And who better understands the Unix-nature?” Master Foo asked. “Is it he who writes the ten thousand lines, or he who, perceiving the emptiness of the task, gains merit by not coding?”

      Upon hearing this, the programmer was enlightened.

      • by Anonymous Coward

        Whoever wrote that crap isn't a programmer.

      • Isn't the finality of every language is to ultimately produce assembly instructions?
        I mean, if they were all created to provide a layer of abstraction to programmer, python -and shell code- do it better than C. And that's certainly the reason why python, and shell scripts, are mostly use to orchestrate the usage of other programs written in other languages.
        It's all about the right tool in the right context. That's the only wisdom there is.
        • by Anonymous Coward

          SQL, Prolog, functional languages, graphs, are descriptive instead of imperative, meaning the code being an end itself as well as a blueprint for processing and I/O.
          Imperative languages are mostly glorified machine code / ASM translators, interpreters and VMs, though may also act as a platform like Smalltalk and Java JVM, so could implement higher-order concepts and designs.

          Higher-order design and generalizations are less used practically, as you get removed from physical model and implementation, meaning s

      • by Jody Bruchon ( 3404363 ) on Thursday May 02, 2019 @08:28AM (#58526408)
        That's a pretty fun little story. I am reminded of my Linux-based "driver drop" script (and its companion database builder script) which scans the hardware in the computer and creates a Windows driver folder on the hard drive. I had two bottlenecks: one was reading and minimally parsing INF files to get the hardware and OS support info to stuff into the device driver database; the other was filtering the device database to find each hardware ID's matching driver(s).

        For the INF problem I ultimately wrote a short and simple C program called "read_inf_section" that would output individual INF sections, greatly decreasing what got sent to grep. For the database scanning problem (it's just a pile of colon-separated fields, one unique per-INF device entry per line) I planned out a C program that would fetch and parse the appropriate lines without requiring a bunch of text processing pipelines since most of the script was slowed by orders of magnitude due to hundreds of thousands of forks to run stuff like grep. However, I quickly stopped bothering as I recalled that Bash has a built-in regex engine and Bash was already a hard requirement for the script due to heavy Bash array usage. I looked up the info on Bash regex usage and while it took some time to get used to its peculiarities (couldn't just swap in my grep regexes) I managed to replace the extremely "hot" text processing pipelines that were killing performance with a no-fork solution that worked within the shell script. The C program was going to take a lot more time to write then the regex conversions took and the speed benefit relative to Bash regex would probably not have justified the effort.

        Upon doing this, I was enlightened.
        • Using a vHLL like python doesn't mean firing/forking 1000s of small scripts connected with I/O pipes (each blocking on read leading to context switch for the producer to fill the pipe). You use one or a few scripts doing all the work keeping forks/context-switches/data-flow-in-io-pipes minimal. With your using of bash you pretty much did this - avoiding huge overheads leading to performance within requirement.
    • by jma05 ( 897351 ) on Thursday May 02, 2019 @07:19AM (#58526162)

      "It is a toy language if it does not create a native code executable like C", is the most passionate argument I hear from children in programming, typically self-taught teens who have never coded in the real world or those who never learnt a decent high-level language.

      Paid, professional programmers worry about getting the assigned job done, in a cost-effective way - that generally involves choosing the most high-level tool you can get away with, so that you don't end up solving problems you don't need to; not optimizing needlessly early with native code.

      Remember: most code is bottle necked by construction time, not machine time.

      • Re: (Score:2, Interesting)

        by Anonymous Coward

        So this is why Enterprice code is so shitty: Huge footprint, slow startup, no warmup, high latencies and requiring new hardware purchases every few years for less functionality? Java's excellent exception handling and traceability being an excuse for not doing proper error handling, pushing fragile components to production?

        The best tell is where no viable alternatives are being used. Give someone a hammer and all that.. Don't get me started on JS! ;)

      • Re: (Score:2, Insightful)

        To me that same argument that high level programming languages are "smarter because you save time" means you should never code anything, you should just wait for someone else to code it.

        The reality is, the best programs and computer functions are as fast as possible, given the relative speed needs. Fast is not just good, fast is a measure of how good something is. If you could write a program that beat all humans at chess all the time, only it took 1 year to make each move, it would be a terrible program.

        Wh

        • by jythie ( 914043 )
          In a lot of commercial software though, there is no 'wait two years', the whole 'big design up front' thing has been going out of style for decades, it is all about iterative development now. That is where these high level languages really shine, they are more efficient in terms of developer time when you are constantly getting feedback and adjusting the functionality based off of it. Customers tend to not care if you shave a few milliseconds off some benchmark they will never run, but they DO care about
        • by jma05 ( 897351 )

          > means you should never code anything

          It does not. It simply means - Don't keep reinventing the wheel. Else, your final solution will be slower for it, even if you use a much faster tool.
          It is perfectly possible for a C program developed in x hours to be slower than a Python program in the same x hours. High-level code makes it easier to identify low hanging optimizations since you are less wrapped up with unnecessary lower level concerns.

          > you should just wait for someone else to code it.

          No, but do t

        • I'd rather wait another 2 years for a program that is great than get it immediately and shave off a year of my life due to inefficiencies; gratuitous exaggeration intended.

          Unfortunately solutions are often needed ASAP ... because you lose more money by not having the solution versus having a slow solution.

          I once replaced a bunch of interacting Excel Sheets based on Access that partly were only front ends for Oracle with a Java Application. Before optimization the Java program (that was around 2003, Java 1.4

      • Comment removed based on user account deletion
      • As a professional programmer, I am starting to see the fine edge of using a language with static typing versus dynamic typing.
        Using Assembly vs C++ vs Python is less relevant as long as there is good tooling

        Static typing does allow for much easier analysis and refactoring which is critical for building large complex software system.
        Unit tests help but the tooling for them is inconsistent. (Code coverage metrics are important but not there yet...)
        If Python does gain a form of static typing like TypeScript, t

      • It must be nice to work in an industry where performance is unimportant. For many of us in the business, run time is money.

        In a cloud environment, more efficient code means smaller, fewer, and cheaper instances. On big data, more efficient code is the difference between a feasible solution and an infeasible solution. On mobile and embedded devices, more efficient code means better battery life and a more responsive user experience. And on anything to be deployed on machines you don't own, more efficient co

        • by jma05 ( 897351 )

          Sure. Whenever there is an explicit case with clear cost, by all means, you pick something more appropriate.
          Python is rare on mobile devices. Go is perhaps popular for micro-services. Whatever works.

          My point was about *pre-mature* optimization, not to avoid optimization in every case.
          I would have preferred a language like Scala or Nim, if it wasn't so darn easy to find a library (often libraries that are high-performant) for everything in Python.
          Purely as languages, either is even more high-level than Pytho

    • by jellomizer ( 103300 ) on Thursday May 02, 2019 @09:59AM (#58526804)

      It is called an Interpreted Language.

      When I was younger I use to do everything in compiled languages, the lower level the better. But as my career continued. I rarely made software designed to be put in a Box and shipped to someone to install on their PC where we need the easy to click .EXE file to run the program, but software that is running on a server, with a complex set of configurations and security rules, in an environment where the software will always need to be changed, and tweaked, also many components will run fine for much longer then my time at the company, or source code retention and versioning policies stay in place. They were many times where I needed to reprogram a perfectly functioning program someone made 2 decades ago, just because they hard coded the File path locations, and the file locations have changed servers, because it was compiled into an executable. and the source code was long gone. Across multiple CTO who change policies from a lot of development to none then to when appropriate. Having the software as interpreted means the source code is always available, and makes those fixes on forgotten software possible. (Ok once I fixed an exe with a Hex editor, but I was lucky enough the change took the same amount of bytes.)

      NASA used LISP for many of their satellites and space probes, because it allows the code to be changed while the program is still running.

      Then you finally get to cross platform development, It is easier to port your interpreter to a different platform, then converting and recompiling all your programs.
      In the 1980's Mainframes (Unix, VMS, PrimeOS... ) were the big thing, 1990's The rise of the Desktop Personal PC's (MS DOS/MS Windows), 2000's PC Based Servers (Windows Server/Linux), 2010's Cloud services (who really knows anymore, usually Linux) There is a lot of code that you don't need to rewrite, if you can get it ported to the new environment. That python program I made in 1999 to run on a Solaris Unix box will still run in 2019 on a Windows Server Box. The program of that level of complexity would have a 50/50 chance of recompiling in C, do to the differences in system architecture between Solaris for Ultra Sparc, and Windows for x86.

  • C is found in the Linux kernel, most of userspace, high-performance network code, the Python implementation itself.
  • Thanks? (Score:5, Insightful)

    by Anonymous Coward on Thursday May 02, 2019 @04:32AM (#58525834)

    you can thank popular programming language Python

    Why? Do we think if python hadn't been around or not up ti the job, netflix would have shrugged and said can't be done then?

  • More importantly (Score:4, Interesting)

    by EnsilZah ( 575600 ) <.moc.liamG. .ta. .haZlisnE.> on Thursday May 02, 2019 @04:59AM (#58525880)

    It's also probably behind the actual content creation process.
    Most of the VFX/Animation industry software uses python as the scripting language as a standard (Except for Adobe which has its own shitty outdated implementation of Javascript) and by extension the internally developed production pipelines also generally use Python.

  • I’m getting in early on the prediction comments this year. So lets look at what last year’s predictions were helix jump [helixjump2.com]
  • by mentil ( 1748130 ) on Thursday May 02, 2019 @05:15AM (#58525912)

    So one could say that Python is helping to strangle romance? [slashdot.org]

  • by Ashthon ( 5513156 ) on Thursday May 02, 2019 @06:40AM (#58526056)

    What he describes is a few minor, light-weight tasks like the "recommendation algorithms" and "Open Connect, which ensures that content is streamed from network devices that are as close as possible." All the actual work is being done in C/C++, so while the trivial code to determine the closest network element might be written in Python, all the code that does the streaming, from the firmware on the network equipment to the software on the servers, will be written in C/C++. While the trivial recommendation algorithm might be written in Python, all the code involved in encoding and decoding the video will be written in C/C++.

    To say Python is "behind every film you stream" is nonsense. C/C++ is behind everting and Python is only being used for minor tasks on the side.

    • by Skinkie ( 815924 ) on Thursday May 02, 2019 @09:22AM (#58526634) Homepage
      I agree and this article [medium.com] explains it as well.
    • by tk77 ( 1774336 )

      All the actual work is being done in C/C++

      Actually, I believe a lot of it is in Java.

      https://go.java/netflix.html [go.java]
      https://netflix.github.io/ [github.io]

      I spot checked a bunch of their OSS projects on the github.io page above and they were all written in Java (or had large Java based components).

    • by Njovich ( 553857 ) on Thursday May 02, 2019 @10:03AM (#58526820)

      While what you say isn't false, the amount of code that gets written in these kind of companies is quite vast, and most of it isn't very performance sensitive (ie. they'll just spin up an extra thousand boxes to cover the amount of requests, but the actual request doesn't have to be finished in a couple of ms). It makes sense from a productivity and security point of view to write these in python instead of C - especially as they include lots of network requests and string processing.

      The point is, for any given user, you are probably touching vastly more Python code than C code, even if by your definition the C code is doing more important stuff.

      About importance, from the Netflix point of view, the business logic and websites that are implemented in Python aren't quite as unimportant as you think they are though.

  • Maybe turnover also requires the use of relatively fast to learn languages?? In my job when it is not a quick&dirty thing but requires performances and reliability I use Erlang+OTP. Learning curve was really steep; probably took me more than a month to get the first socket based client to work (socket, connect, send, recv ). Much harder than CL. Last 15 years I've been with the same company so the ROI of learning Erlang is >0
  • You don't have to - they'll tell you.

  • by Anonymous Coward

    Quick! If Netflix are doing it, so should we. Start porting all that Java to Python right away!

  • by Anonymous Coward

    ...somebody writes a major piece of software (operating system, file system, database, etc.) in Python and it isn't half as fast as the competition.

  • I've been considering closing my netflix account because it's buggy and slow so this probably isn't a glowing recommendation for python.

  • Explains why a lot is slow and buggy, and why a lot doesn't work userfriendly in regard to lists etc..
  • Comment removed based on user account deletion
  • Comment removed based on user account deletion
  • If you're wanting to compare CDN language use, the Apache Traffic Server [github.com] is primarily C++ and the companion project Apache Traffic Control [github.com] is primarily a mix of Golang, Java, and Perl.

On the eighth day, God created FORTRAN.

Working...