Hacker News Reader

Comment by dmalvarado | Hacker News Reader

“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,000 photos a day.

Of course, that's not to say that Instagram doesn't have CAP issues. It does, especially in the "C" area, but again, not a problem inherent in the language.

View on HN

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.

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.

Wouldn't survivor bias explain who BigCo X can be found using whatever questionable choice they originally made, but not explain why lots of BigCos have changed their practices.

This might explain Facebook and PHP, but it doesn't explain the stuff mentioned in the previous comment.

I heard through the grapevine that Go was only chosen at Uber to help with hiring.

That seems silly. There are far more Java devs out there than Go devs.

Also, I would assume Uber probably has hiring problems in general at this point.

> That seems silly. There are far more Java devs out there than Go devs.

I wouldn't underestimate the level of hype-driven development that exists in this area. "Chasing the new shiny" seems like it could be a line item in a resume, these days, sometimes.

There are more good Go devs. A lot of Java programmers are enterprise.

I would imagine that node would draw more enthusiasm than Go

There is RoR for Jruby which has native threads, plus you can call Java methods from Ruby.

Plus Facebook has a lot of C++ and some Java services as well, in addition to the Hack/HHVM stuff.

Don't be obtuse, it's not because of multithreading.

They move to static typed because their team is 100+ developers none of which knows the entire code base - and static typing helps lower the bugs possible.

Google uses plenty of Python, no?

I don't think threading is a relevant factor for many of those decisions. Perf and static typing, sure.

Not a googler, but I have heard that most of the python at google is under Youtube, which Google got in an acquisition.

Linkedin was mostly scala and then they did some stuff with node.js >___>

Walmart also moved to node.js.

Hype was real.

From python to go and back again https://news.ycombinator.com/item?id=10402307 (mozilla)

All of these are decades-old talking points which have been largely shown to be factually incorrect. Why are you repeating them without justification?

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

I never missed static typing on large code bases but I had numerous bugs caused by python's implicit type conversions - string to iterable of characters ["h", "e", "l", "l", "o"], None to False, string "no" to True, 0 to False, "" to False, etc.

A lot of this mirrors C's infuriating implicit type conversions.

For what it is worth string to iterable char bugs happen to me plenty in scala. Hard problem to fix. Array of strings or string of chars?

I don't think it is that hard. Simply stop making strings implicitly iterable and make chars a different type.

See issues like https://engineering.instagram.com/dismissing-python-garbage-...

If you have to turn off a crucial language feature to increase performance, I'm not sure whether a language is considered "scalable".

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.

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

It's old but still useful: https://www.techempower.com/benchmarks/

Almost every language can handle typical performance requirements. But when people say slow or unscalable it's almost always in relation to other languages.

Reply on news.ycombinator.com