Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Instead of a bunch of hacks that are obviously going to blow up in someone's face one day why not just use a more suitable platform?

Forking threads for web pages is so old school...And Python is a terrible choice for something at their scale.

Just redo the hosting bit in Java or golang and call it a day. If their UI code is sufficiently isolated from the back end it's not a huge deal.

Instagram is a pretty small application feature-wise, a few devs could probably do it in a couple months



Instagram is a living example for when you have big scaling problems you just scale. You are probably right with your arguments... the question is: Is it worth to choose a good scaling architecture when it slows your initial development down? Instagram is python, many Youtube parts are python, FB is even worse and is PHP at many parts.

So what? Sure they would scale better when using Erlang, Java or Go... but sometimes it is wiser to finish building something than making the best ultrascalable system. If you are really successful you will find ways to scale.


I've heard this so many times but I always wonder how the unicorn effect skew this. Do a majority of companies with such scaling issues fail? I've seen products go down in flames firsthand because performance was so bad. Never at a start-up but I assume it happens there too.

Facebook is a good example because of all the money they've thrown at a problem they shouldn't have. First was a custom PHP interpretor then a compiler and now hack. If they didn't have nearly unlimited money to throw at it would things have ended differently?

Language choice is one of the easiest choices to make. Pick a fast one out of the box if you plan to get big. It's not like the faster languages take orders of magnitude longer to write code in, the effect is minimal at best.


> Forking threads for web pages is so old school

I don't think you understand how uWSGI works.

> And Python is a terrible choice for something at their scale.

Maybe they could use whatever youtube uses for their frontend instead?


> I don't think you understand how uWSGI works.

...or gunicorn. Or twisted / hendrix. Or any WSGI container with process consciousness in the past 5+ years.


So you suggest a couple months of work instead of a two line hack which caused huge improvement for them, because it is more "correct"?


Why should they rewrite everything if it works for them?


because it doesn't. What they're doing is borderline crazy. Similar to turning off the GC in the JVM... once you reach that point why not just use a more suitable language?

Java/Golang/Rust/C++/C# are all about 100X faster than Python. Wouldn't it be more reasonable to use one of those than mess with the runtome to squeeze out 20% more performance?


> Similar to turning off the GC in the JVM

It's absolutely not the same. The JVM uses GC for all object collection. Python uses reference counting and only relies on GC to clean up cycles.


It does. They're profitable even with fairly small engineering team considering size of their user base.


> turning off the GC in the JVM

very common in the HFT world




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: