Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Old box, dumb code, few thousand connections, no big deal

rachelbythebay.com

Post reply on HN
Print view View original

111–120 of 288 posts

Re: Old box, dumb code, few thousand connections, no big deal

#111

Post by bsder »

anonymoushn wrote: post #92
bsder wrote: post #82

Earlier quoted context omitted.

You ... are not ... Instagram. Okay. Get over it. Python is fine. Threads are fine. Go is fine. Clojure is fine. Java is fine. PHP is ... okay I won't go that far. :) You fix the problem when the cost required to fix the problem is finally less than the opportunity cost of fixing something else.

I would prefer not to deal with "scaling up" for workloads that could run in a single process on commodity hardware. I've mainly worked at companies that would be bankrupt if they used Python the way Instagram does.

Django and Python somehow handled websites for entire newspapers on far wimpier hardware just fine--which makes me wonder if "cloud" (ie. non-deterministic memory and I/O accesses due to sharing with other tenants) isn't the problem rather than Python.

You need a market. You need paying customers. You need cashflow. You need features. You need a business plan.

You don't need scaling. Ever. To first, second and third order approximations.

Your company has a higher probability of bankruptcy than needing scaling.

Re: Old box, dumb code, few thousand connections, no big deal

#112

Post by neurostimulant »

phreack wrote: post #98
nexuist wrote: post #93

Earlier quoted context omitted.

PHP is fine too. Check out https://laravel.com/ and tell me that doesn't look like a joy to work with.

How much of the old "A fractal of bad design" post would you say still applies? That one post showcased so many footguns right at the language level that it spooked me away from it forever.

A lot of those are still applies, but these days you can ignore those bad parts and only use the new good parts just like how you would use javascript. Still, I only use php occasionally but I wish it's not as eager in treating string as number in many cases.

Re: Old box, dumb code, few thousand connections, no big deal

#113

Post by bsder »

flyinglizard wrote: post #108
bjt wrote: post #44

Whether intended or not, there's an undercurrent of "you're all so dumb for using Python" (or Ruby, or PHP, or other similarly performant language) here. I want to surface that and question it a bit. It's totally reasonable for a company to choose the Python/Gunicorn option if they already have a bunch of people who know Python and they don't need to serve tons of requests per second. Even if they do need to serve to…

The only reason to use Python for anything more than few hundreds lines worth of utility is if you're working on a codebase that's already in Python, and even then it's debatable. There simply isn't an excuse for using Python for any infrastructure. It does nothing particularly well - or even right - other than very purpose-specific scripting. It can tie things together well enough. And your codebase becomes a liabil…

> The only reason to use Python for anything more than few hundreds lines worth of utility is if you're working on a codebase that's already in Python, and even then it's debatable.

One important reason for using Python is that it almost always forces people and companies to release the source code.

I will take a shitty Python script over shitty C/Rust/Go/Java code any day for that reason ALONE.

With source code, I can fix your shitty program (and all programs are shitty--even mine). If it's compiled, that path is blocked.

Re: Old box, dumb code, few thousand connections, no big deal

#114

Post by aeyes »

rpedela wrote: post #57
ivalm wrote: post #22

What WSGI do people recommend for python? I've been using gunicorn but this made me think of alternatives. Quick google search found this benchmark [0], is it really that bjoern is much quicker? It seems all other WSGI are ~ equivalent. [0] - https://www.appdynamics.com/blog/engineering/a-performance-a...

Falcon https://github.com/falconry/falcon

That's a web framework, you need a WSGI server to run it.

Re: Old box, dumb code, few thousand connections, no big deal

#115

Post by tjalfi »

haneefmubarak wrote: post #72
trianglem wrote: post #26

Earlier quoted context omitted.

I’ll bite, is it slack?

In all honesty, there's a whole slew of platforms it could be: - Slack - Keybase - Mattermost - Discord - Microsoft Teams - Facebook Messenger (incl. Work) All of these fine folks apparently use Electron or a similar technology...

Cisco Jabber also embeds a browser engine.

I think of Electron as Gresham's law in action.

Re: Old box, dumb code, few thousand connections, no big deal

#116

Post by itwy »

flyinglizard wrote: post #108
bjt wrote: post #44

Whether intended or not, there's an undercurrent of "you're all so dumb for using Python" (or Ruby, or PHP, or other similarly performant language) here. I want to surface that and question it a bit. It's totally reasonable for a company to choose the Python/Gunicorn option if they already have a bunch of people who know Python and they don't need to serve tons of requests per second. Even if they do need to serve to…

The only reason to use Python for anything more than few hundreds lines worth of utility is if you're working on a codebase that's already in Python, and even then it's debatable. There simply isn't an excuse for using Python for any infrastructure. It does nothing particularly well - or even right - other than very purpose-specific scripting. It can tie things together well enough. And your codebase becomes a liabil…

Any which language do you use for web apps if I may ask? Let me guess. Rust.

Re: Old box, dumb code, few thousand connections, no big deal

#117

Post by tasogare »

turtlebits wrote: post #60
rumanator wrote: post #46

Earlier quoted context omitted.

> Even if they do need to serve tons of requests per second, it's totally reasonable for them to still choose Python/Gunicorn if the cost of the additional servers is less than the cost of having to support multiple languages. How hard is it to get up to speed on any other tech stack? ASP.NET Core is extremely fast and the learning curve is close to none, for example. If someone was able to wrap his head around backe…

I disagree. I tried to learn F# a few months ago and the experience was horrible. I followed the tutorial using the aspnet CLI tool and got nothing but errors. I Google’d for a while until I gave up.

Of course it’s gonna be hard if you are trying to learn a language plus a framework at the same time, especially given that F# is treated as a second class citizen by Microsoft. An easier path is to break that learning into more manageable tasks: on one hand getting familiar with F# (which is already some work as it has both a functional side, and a CLR one; you need more the OOP part for doing ASP.net) and in the other ASP.net, for which the golden road is C#.

Otherwise the doc is quite good for ASP.net Core, and it’s rare I get stuck on a problem for too long with it.

Re: Old box, dumb code, few thousand connections, no big deal

#118

Post by smacktoward »

phreack wrote: post #98
nexuist wrote: post #93

Earlier quoted context omitted.

PHP is fine too. Check out https://laravel.com/ and tell me that doesn't look like a joy to work with.

How much of the old "A fractal of bad design" post would you say still applies? That one post showcased so many footguns right at the language level that it spooked me away from it forever.

You can get a good sense for what "modern PHP" looks like by browsing through PHP The Right Way (https://phptherightway.com/).

PHP has grown up a lot over the last ten years.

Re: Old box, dumb code, few thousand connections, no big deal

#119

Post by augustt »

highfrequency wrote: post #90
kragen wrote: post #50

Rachel presumably wrote her server in a reasonable language like C++ (though I don't see a link to her source), but when I wrote httpdito⁰ ¹ ² I wrote it in assembly, and it can handle 2048 concurrent connections on similarly outdated hardware despite spawning an OS process per connection, more than one concurrent connection per byte of executable†. (It could handle more, but I had to set a limit somewhere.) It just…

> single-threaded nonvectorized C wastes on the order of 97% of your computer's computational power Can you elaborate on what this means exactly? For example, is there some reasonable C code that runs 33 times slower than some other ideal code? In what sense are we wasting 97% of our computer's computational power?

A good example of getting a ~3000x speedup from naive matrix multiplication in C here (slides 20 onward): https://ocw.mit.edu/courses/electrical-engineering-and-compu...

Includes a 9-level nested for loop, which is always great to see.

Re: Old box, dumb code, few thousand connections, no big deal

#120

Post by xeroalt »

stev_stev wrote: post #55
rumanator wrote: post #46

Earlier quoted context omitted.

> Even if they do need to serve tons of requests per second, it's totally reasonable for them to still choose Python/Gunicorn if the cost of the additional servers is less than the cost of having to support multiple languages. How hard is it to get up to speed on any other tech stack? ASP.NET Core is extremely fast and the learning curve is close to none, for example. If someone was able to wrap his head around backe…

This is where my head always goes as someone who does mostly Asp.Net Core. Why is it always between something like C++ or something like Python? Nowadays with middleware and endpoint routing, asp.net core can be almost as simple as flask (even if that’s not idiomatic or what the docs show you).

I’m most comfortable in .net core but I recently learned Django because I kept hearing how productive it was from HN and all the startups around me use it, but Im starting to feel like I chose to move the wrong way. I will say I like how Postgres is the default for python and the library situation is much better over there as well.
Post reply on HN