Live data from Hacker News

Using Python helped YouTube ship features faster than Google Video

books.google.com

41–44 of 44 posts

Re: Using Python helped YouTube ship features faster than Google Video

#41
post #17

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.

I'm not sure how YouTubes current existence given the past decade or so isn't a huge antitrust violation. They've run the platform at a massive loss, subsidized by their other business ventures to make it impossible for anyone to create a competitor. I can't imagine that if you propose to a VC that you need to spend hundreds of millions of dollars on building infrastructure that you will then need to run at a loss potentially for decades before hoping to see any profit it would go well.

Re: Using Python helped YouTube ship features faster than Google Video

#42

I 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…

You say:

> 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

#43

Earlier 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.

Yet Python has never claimed to be a templating language itself, let alone "the easiest, simplest, most direct way to generate html".

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.

Post reply on HN