Live data from Hacker News

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

rachelbythebay.com

201–210 of 288 posts

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

#201

Earlier quoted context omitted.

> is there a better stack Apparently, it's C, or ...assembly? According to the comment above yours. Because developer time is apparently cheaper than CPU cycles. Weird.

As we've seen in the cloud costs thread, going from python on AWS to Rust on dedicated hardware can push your bills from 30'000$/month down to 300$/month, which more than pays for the dev salaries (especially if you're not paying the excessive and unnecessary salaries of the bay area)

How many hours would you expect that rewrite to take when done by Python developers learning Rust as they do it?

And what's the opportunity cost of the new features they can't create because they're rewriting existing apps?

If you're arguing that Python has more runtime overhead than Rust, I don't disagree.

But there's a reason people invented higher level languages than C. Rust is a far nicer systems language than C, but is it faster to develop in than Python or Kotlin? It really depends.

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

#202
post #93
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.

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

I just got roped into a project with the promise of Django, but the project lead ended up deciding to go with Laravel, so I've been looking into it for a few days.

It's a resounding no from me. If you're stuck with PHP, sure, this beats the WordPress style of...well...I can't really find words to describe how bad it is..., but it's still miles behind anything else. It full of strings and other things that you just have to memorize with IDE integration even with specialised extensions still worse than other languages with standard IDEs.

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

#203

> Ever since I wrote about the whole Python/Gunicorn/Gevent mess a couple of months back, people have been asking me "if not that, then what". It got me thinking about alternatives, and finally I just started writing code. I actually want to know: then what? As a web developer who usually reaches for Django or Flask with Gunicorn because I just don't know any better, is there a better stack that doesn't face these pr…

> is there a better stack Apparently, it's C, or ...assembly? According to the comment above yours. Because developer time is apparently cheaper than CPU cycles. Weird.

Every time I read one her posts, I think, wow she must either work for literally dirt cheap or her code is expected to run on several thousand machines. Most projects just don't reach the scale or steadystate where developer time is cheaper than machine time. It's fun trying to squeeze the last drop of blood from stone, but it rarely makes economical sense.

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

#204

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

In my experience the Discord client has been pretty smooth in general.

Slack on the other hand can be very slow at times.

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

#205
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...

I've been using uWSGI behind NGINX (using uwsgi_pass) for years. It might not be the absolute fastest option around but it's faster than a lot of the other options, rock solid and extremely configurable.

Some fun extra features that uWSGI provides:

- Daemon management: It can manage other daemons, for example Celery, for you, so you can put your whole environment into a single uWSGI.conf.

- A cron-like interface for generating events on a schedule.

- Emperor - hosting of multiple apps. This is extremely configurable, you can have the server look at the filesystem for config files for the simplest setup but it also supports AQMP, a Postgres database, MongoDB, a shell command or a bunch of other things. It has a bunch of interesting isolation options, like running each app in its own Linux namespace. It also has (optional) socket activation, so apps won't be started until the first request.

- Auto-scaling

- Soon, multiple event-loop/IO subsystems to choose from, including asyncio

I've been meaning to have a look at nginx-unit though.

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

#206
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...

Do you have a performance issue that you have tracked back to gunicorn? If not, then continue using gunicorn. There are almost certainly more valuable things to spend your time on than replacing something that is already working.

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

#207

Earlier quoted context omitted.

Doesn't WhatsApp story contradict to what you're saying? They handled millions of users per second, weren't part of FAANG and this helped them get acquired by FAANG and a high valuation for being a very nimble team and architecture.

how that contradicted me? I see this as exactly opposite, as in they became part of FAANG exactly because they managed to handle those users. And let's be real, they handled millions users/second after becoming Facebook. Like it or not FB is no.1 social network.

They got aquired in 2014. They hit 400M users in 2013. By then it was already THE messaging app for several European countries.

I know amount of users doesn't equal users/second. But we shouldn't pretend like they weren't able to handle high traffic before Facebook aquired them.

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

#208
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…

I don't really get what the point of this post is. Is it really a dig at python? Python can handle thousands of connections in a single thread no problem with basic enough stuff. Is what the author did supposed to be impressive? Is it supposed to make python look bad? I don't get it. Seems like run of the mill stuff. Python might struggle at the same level of concurrency (was it like 15k?) but you can still do 10k co…

I read it more like: "what if we just use threads instead of avoiding them at all cost and complicate things to get concurrency"

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

#209

Earlier quoted context omitted.

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…

So you always get downvoted to hell whenever you post this and you've decided everyone else is the problem? Can you even understand how you sound? I cringed with sympathetic embarrassment just from from reading this. Seriously, rethink your life choices man. This coming from someone who has literally never written a line of python in his life.

Trading internet points for potentially helping someone make a better engineering decision is a fair enough deal.

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

#210

I know pcwalton has been banging the "just use threads" drum for a while now. Rust used to use a green thread approach, but if I recall correctly, they ripped all that out for just native threads with the idea that in most cases it's fast and efficient enough. I remember when C10K was the big challenge, but even the naive approach of spawning a thread per connection now can handle that.

I've written a "just use threads" approach to a web server in Rust, and if you're just juggling IO and not doing any real work like most CRUD webapps, just about every other async-capable language scaled more gracefully and used less resources.
Post reply on HN