YouTube was also burning money for bandwidth like nobody's business. I suspect that Google Video tracked and limited bandwidth. If Google hadn't bought them, YouTube were headed straight for bankruptcy. People forget that the YouTube deal was a big time boardroom back scratch between Google and the VC's. The worst part is that Google subsidizing YouTube has set back a real monetization of video on the web.
Using Python helped YouTube ship features faster than Google Video
41–44 of 44 posts
Re: Using Python helped YouTube ship features faster than Google Video
#42I worked at Google during that period. It's not quite as simple as "Python > C++" although yes, for sure, you're going to produce new UI features at a far faster rate working in a high level language like Python than working with C++. Absolutely that was a factor. I don't think Google Video had hundreds of developers vs 20 though. That doesn't sound right to me. The real reasons YouTube won were strategic, not purely…
> Social features are a great use case for Python
And then say:
> On the other hand around the time YouTube were acquired they struggling tremendously with the scaling aspects of their operation and large chunks of the site had to be quickly switched to C++.
I fail to see how python failed youtube here.
You use the right tools for the job. And the tools that got you 10e1 views per day may not be the tools that get you to 10e10 views per day.
I once worked at a place that supposedly "engineered" their backend to handle 1,000,000 connections at once. Only everything fell over at 10,000 connections in production, and they struggled for two years to get to 100,000 connections.
The point is, you don't know what you don't know, and you won't know the pain points are until you hit them. And the more groundbreaking your service (in this case internet video distribution), the chance of your architecture being 100% correct from the start is zero.
Re: Using Python helped YouTube ship features faster than Google Video
#43Earlier quoted context omitted.
For a so-called templating language, PHP sure falls short, and thus has a plethora of ad-hoc, informally-specified, bug-ridden, slow implementations of half of many other templating languages implemented in it. https://www.smarty.net/ https://en.wikipedia.org/wiki/Wikipedia:Templates https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
Smarty is something from 15 years ago. Nowadays people use Twig which is inspired by Python's Jinja template engine and has similar syntax.
My point is that PHP pretends to be a templating language, then falls flat on its face, so people end up implementing much worse (Smarty, MediaWiki) or sometimes even better (Twig) templating languages on top of it.
In other words, it's simply not true that PHP's "declarative "templating" is the easiest, simplest, most direct way to generate html", or there wouldn't be a need for Smarty, the MediaWiki abomination (which is 17 years old but still widely used on 29 million pages), or Twig.
I'd say "to hack together something half-assed that barely works, but does provide the feature" perfectly describes the PHP development process itself.