Hacker News Reader

Comment by blitzar | Hacker News Reader

Yet here it is ... powering a global scale app.

Too weak for someones hobby project, strong enough for global scale.

But this is what FB/Meta are known for. They managed to scale PHP for years. They did fork it into Hack. They do have their own extensions. But they've put a ton of time and engineering effort into it. They didn't do it because they thought PHP was a great language. It was because they already had a massive infrastructure and tons of engineers that were already productive. Doing the math they realized it'd be cheaper to keep using PHP.

The same is true here. They spent so much money getting Instagram to scale. They created Cinder to try and fold their hacks/tweaks back into Python. Spinning up some Rust/Java/Nim/Zig/Pony/Whatever stack sounds like it'd be fun... but spinning up a stack with which you're already VERY familiar, sounds like a money-maker.

I'm totally agreeing btw, I realize this came off like it might be a counterpoint.

Off-topic: it is not yet [global scale] because it is only available in US. Here in EU, I still get “not available in your country”.

it is not yet [global scale] because it is only available in US. Here in EU, I still get “not available in your country”.

It's not only available in the U.S. It's available in 100 countries. There's more to "global" than the E.U.

Anything that is available in over 100 countries is global to me.

It is only unavailable in the EU.

Something, something privacy regulations.

Throw a trillion cores at anything and it can be global scale.

My few years of personal experience of using Python with even small-ish scale professional projects have been... underwhelming so far. I wonder how Meta (and Google, and all the others who write serious Python code) manage to keep things running – and I'm not talking (only) of performance, but largely of bugs.

My personal suspicion is that the secret sauce is simply to have a sufficient budget to hire an army of code quality engineers. I could be wrong, though.

In short: static analysis, unit tests, staging environments, effective log aggregation.

The first one is a big productivity booster as it shows you bugs before you commit them.

Here's a post about this, not exactly new but still describing the general principles very well: https://instagram-engineering.com/static-analysis-at-scale-a...

Thanks. For context, I happen to have a PhD in static analysis, so I'm not entirely stranger to the general idea :)

Sadly, all the attempts I've had with static analysis in Python screamed that while the language and tools make a valiant effort at supporting a reasonable set of annotations, 8-9 years after PEP 484, the libraries are simply not yet ready for it (not even, in many cases, the standard library).

Unit tests, staging environment, effective log aggregation are all important tools, of course.

I would say that those things don't really contribute to the actual runtime scalability of the application. Those things ensure that the code is at least correct for what it's supposed to do, not necessarily whether it's performant. Even the most perfectly-written Python code will still be dog-slow and require an enormous budget to actually run at scale. It's obviously fine to do that and there are many success stories, but all of them required massive infrastructure investment.

> Even the most perfectly-written Python code will still be dog-slow and require an enormous budget to actually run at scale.

Nah, asyncio on uvloop is plenty fast.

For context, I was asking about scaling code complexity, not scaling performance.

That being said, my personal experience suggests that both are really hard in Python, and not independent.

Tests is likely a large part of it. There are some great tools for code formatting, quality, and type checking. It’s a very flexible language…

When people are hyper critical of Python I feel it’s typically they haven’t seen real professional Python before and just throw scripts around… if you work with some hardened Python pros you pick up the tricks really quickly and it’s very enlightening.

I’ve always struggled to find all of those tricks in one online resource personally.

Every language will have its gurus and its own peculiar with-the-grain approach, but the python language has a ton of non-essential complexity baked into its very design/core (especially for a language that people seem to think is "simple"-- it's not, not at all; it's a language full of "pragmatic compromises", apparently by intentional philosophy), which places fundamental limits on how safe your application can be.

The secret sauce is Intellij and some community knowledge. There's a library for everything and a great IDE makes it pretty painless and fun. Not sure I'd always jump for it thanks to the GIL but I wouldn't mind a job where it's my primary instead of my secondary or third language.

The biggest pain with it is of course refactoring. It's tedious, but I think still comes out ahead in terms of productivity for high level stuff.

You can write crap code in any language. To avoid it you need to enforce some decent set of best practices for that specific language. That also means not using best practices from language X in language Y and then complaining that language Y is crap.

Yes. And one way to rephrase my question is: which best practices work for these Python mega-projects?

>My few years of personal experience of using Python with even small-ish scale professional projects have been... underwhelming so far

You have years of experience but couldn't point to anything in particular?

Heck, I like python and I can complain about dynamic typing issues in for loops, or that they are adding features like generators/decorators that make code more difficult to understand, which goes against the zen of python.

(But I still think python is great)

> or that they are adding features like generators/decorators that make code more difficult to understand, which goes against the zen of python.

Those features are 20ish years old which made the word "adding" seem a little weird. Interestingly the Zen of Python itself is not much older than generators.

Why would I need to point to anything in particular? I think that all Python developers know them already.

I cannot find any substance in your comment. At minimum it should provide some rough examples instead of simply "underwhelming".

Well, I wasn't planning to spend time criticizing Python. I think that we all know roughly its pros and cons, no need to add fire.

My questions remain, though.

So Google and Dropbox, who switched to Golang, are hobby projects.

Choice of language is not what makes things succeed or fail in production.

Team best practices, enforcement of coding style and technique, good project management, infrastructure, and team cohesion etc.

And weeding out bad engineers who think that "switching to a new [language|framework|religion]" will solve all problems.

10+ years ago Facebook itself did a remarkable job of scaling up, with hardly any outages, a PHP LAMP stack thingy to one of the hugest traffic websites in the world. Meanwhile back then Twitter mucked around with every novel technology they could find or invent, and had constant outages.

Also Google didn't "switch to Golang." There's plenty of C++, Java, Python there. I worked there for 10 years and encountered only a handful of Go projects. Lots of cloud services in C++.

Would I personally choose Python for a project? No, I don't like it, and I work in Rust full time because I prefer it. But if I worked at Meta / Instagram and had a team of Python engineers and existing libraries & infrastructure, this would be the right approach.

Also, what's really different from Instagram? You change the picture for a short text and many other features already existed - comments, likes, subscriptions, recommendations, personal messages...

I think this is just an Instagram skin with some feature flags.

Reply on news.ycombinator.com