Live data from Hacker News

Instagram Makes a Smooth Move to Python 3

thenewstack.io

11–20 of 62 posts

Re: Instagram Makes a Smooth Move to Python 3

#11

“Yeah, Python is great in so many ways, too bad it’s not really scalable.” I'm not even sure what this means anymore. I guess I'm just not sure how any language, when used correctly, could be inherently unscalable. My guess is statements like this came from a time when monoliths were the application design of choice? Now, assuming Instagram has just 1,000 photo handling servers, each one is only responsible for 95,00…

The threading story isn't great. It's not statically typed, which can make working on a large codebase with more people more painful. It also forces you to write more unit testing code coverage to make up for the lack of a static compiler checking things for you. Raw performance is not good compared to golang or java.

When you start getting to a certain scale, developers are cheaper than your server costs in some cases. That is when something being performant is more worth it.

Re: Instagram Makes a Smooth Move to Python 3

#12

“Yeah, Python is great in so many ways, too bad it’s not really scalable.” I'm not even sure what this means anymore. I guess I'm just not sure how any language, when used correctly, could be inherently unscalable. My guess is statements like this came from a time when monoliths were the application design of choice? Now, assuming Instagram has just 1,000 photo handling servers, each one is only responsible for 95,00…

As one example, PHP 5.x as-is (without caching) isn't a language that scales well at all. It becomes a horrible bottleneck under heavy load.

Even with caching it's quite poor, especially if you are using frameworks that aren’t written to properly take into account its unique means of execution (which the vast majority do not).

Re: Instagram Makes a Smooth Move to Python 3

#13

> It made sense that, if we were going to stay on Python for the next ten years, we should invest in the latest version of the language. I don't know this stands out to me in particular, but the 10-year commitment is definitely a big decision. I suppose I've never had to make a similar decision so perhaps this is more common than I think.

Most successful application I've worked on have either already been around for 10 years, or have lived onto become 10 years old. The ones that didn't, were usually not successful.

It's a good reason to be careful to avoid the latest and greatest, but go for tech that has (some) track record of being maintained and used for a few years.

Re: Instagram Makes a Smooth Move to Python 3

#14
post #11

“Yeah, Python is great in so many ways, too bad it’s not really scalable.” I'm not even sure what this means anymore. I guess I'm just not sure how any language, when used correctly, could be inherently unscalable. My guess is statements like this came from a time when monoliths were the application design of choice? Now, assuming Instagram has just 1,000 photo handling servers, each one is only responsible for 95,00…

The threading story isn't great. It's not statically typed, which can make working on a large codebase with more people more painful. It also forces you to write more unit testing code coverage to make up for the lack of a static compiler checking things for you. Raw performance is not good compared to golang or java. When you start getting to a certain scale, developers are cheaper than your server costs in some cas…

And at that scale you can make additional microservices for the critical path where it matters.

Re: Instagram Makes a Smooth Move to Python 3

#17
post #14
post #11

Earlier quoted context omitted.

The threading story isn't great. It's not statically typed, which can make working on a large codebase with more people more painful. It also forces you to write more unit testing code coverage to make up for the lack of a static compiler checking things for you. Raw performance is not good compared to golang or java. When you start getting to a certain scale, developers are cheaper than your server costs in some cas…

And at that scale you can make additional microservices for the critical path where it matters.

Not really. You'll notice a pattern in most tech bigcos where they move from dynamic lang X to a statically typed language that can multithread properly.

A few examples: Ruby on rails to java (twitter). Java & c++ (google). Java (linked in). Python/Node -> Java/Go (uber). Or they start doing silly things like make a new VM (facebook).

Re: Instagram Makes a Smooth Move to Python 3

#18
I can't say I think this has ever been really true: "Performance speed is no longer the primary worry. Time to market speed is."

Performance has been a concern but programatic loadbalancing has been around for decades. When I worked at MSN/Linkexchange back in the late 90's we never really worried heavily about the performance of the language we used (Perl) because we could scale out servers. Perl isn't that speedy but it sure was easy to develop in. We served a billion and a half clicks per month with 8-10 machines from a single datacenter before I left, with Perl.

Re: Instagram Makes a Smooth Move to Python 3

#19
post #17
post #14

Earlier quoted context omitted.

And at that scale you can make additional microservices for the critical path where it matters.

Not really. You'll notice a pattern in most tech bigcos where they move from dynamic lang X to a statically typed language that can multithread properly. A few examples: Ruby on rails to java (twitter). Java & c++ (google). Java (linked in). Python/Node -> Java/Go (uber). Or they start doing silly things like make a new VM (facebook).

I wonder if there is some survivor bias there. I'm sure there must be cases where everything went wrong but nobody writes about it.

Re: Instagram Makes a Smooth Move to Python 3

#20

“Yeah, Python is great in so many ways, too bad it’s not really scalable.” I'm not even sure what this means anymore. I guess I'm just not sure how any language, when used correctly, could be inherently unscalable. My guess is statements like this came from a time when monoliths were the application design of choice? Now, assuming Instagram has just 1,000 photo handling servers, each one is only responsible for 95,00…

You can "brute force" scale pretty much anything just by throwing up more computing resources at the problem - but that means the language/framework/library is less scalable than something else which requires less resources. If the different in scalability is large enough, I suppose one can claim that one of the alternatives is "not really scalable".

I suppose that quote could use better wording.

Post reply on HN