Live data from Hacker News

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

rachelbythebay.com

271–280 of 288 posts

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

#271
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 great talk which gets you thinking in this mindset is "Data-Oriented Design and C++" by Mike Acton https://www.youtube.com/watch?v=rX0ItVEVjHc

As an example, if you are checking a boolean flag (1 bit) on an object, and it ends up being a cache miss (and x86_64 cache line size is 64 bytes), then your computer just went through all the expense of pulling in 512 bits from RAM yet it only used 1 of them. You are achieving 0.2% of the machine's possible throughput.

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

#272
post #194

Earlier quoted context omitted.

> ASP.NET Core 2.1 was released in 2018 and will be supported until late 2021. Which is way too unstable, especially for the kind of corporate environment c# has typically been used in. Getting those places to upgrade to stable supported versions of the framework has always been a battle even when backwards compatibility was great, if they have to deal with breaking changes every few years they will never upgrade. Th…

> Which is way too unstable, ASP.NET Core 2.1 is the LTS release of ASP.NET Core 2, which was released in 2017. I fail to see how a first class framework with a LTS that was released years ago can be described with a straight face as "way too unstable". > Getting those places to upgrade to stable supported versions of the framework has always been a battle ASP.NET Core 2 is stable since at least 2 or 3 years ago, dep…

> I fail to see how a first class framework with a LTS that was released years ago can be described with a straight face as "way too unstable".

I fail to see how you can call 2 years of support an LTS with a straight face, it's taking the piss out of the term. The LTS of the OS I'm likely to run it on is supported for 8 years. 2 years isn't even enough time to finish many projects on the same LTS it started on.

At work we've got 30 year old c/c++ code bases that still run, they'll probably run for another 20 at least, we've got 20 year old python code that still runs (for now) and we've got 20 year old c# projects that still run. That last one will never get rewritten in .net core, in part because they've pissed away the stability the framework had. It would be crazy to use tools with 2 years of support for any of those projects.

> Don't confuse "why waste money maintaining working software" linesof reasoning as a sign of respect for stability.

Why should they waste money maintaining working software when there are stable options available? What does upgrading to asp.net core get them? Why should tens of thousands of companies waste money modifying working software just because someone on the core team thought the existing API was inelegant or too hard to maintain compatibility?

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

#273

Earlier quoted context omitted.

Note: these opinions are mine In terms of error-proneness, I would say the hierarchy is this: Actors In terms of "getting started" difficulty, I would put the order like this: Async In terms of first-order maintainability in large projects I would put the order like this: Actors >> CSP ~ Threads > Async Async is on its face easy to grok, and saves you a ton of problems with locking and the like, and you can run it on…

The async stack traces I've come across in Python are extremely simple to grok. I've never had something I couldn't figure out. (Using aiohttp, aoipg, asyncpg). I can't even say the same for synchronous Django. Sometimes it's just the quality of the tool you're using, not the higher-level concept it implements.

You can trivially implement async on top of actors, (like exists in Elixir's Task module), and generally most async in elixir should go through that model. But if you're in python-land you really don't know what you're missing. In elixir, my tests autopartition the state so that each test exists in it's own "universe in the multiverse", so I can run concurrent, async integration tests with stubs, database transactions, even http requests that exit the vm (through chromedriver) and come back, finding their own correct partition of the test mockset and database state, and I have a few custom extensions to the multiverse system like process registries, and global pubsub channels. We're talking hundreds of highly concurrent integration tests that run through completion in seconds.

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

#274

Earlier quoted context omitted.

Django is very good if you want your end-site to be "CMS like". It comes will a lot of accessories to help in that goal. Flask is lighter and it is more DIY but easier if you have something that is more generic.

Yeah I've heard that before, but from my (admittedly brief) time it seemed like you could just use the utilities you want and ignore the stuff that forces you into a CMS'y box. Feels like if you really wanted to you could just use a form/serializer to validate input data and to return a domain object, pass the domain object to a service layer, and then use the django orm (or honestly anything if you really want to st…

Yes you can definitely pick and choose the parts of Django you want. Sometimes they have interdependencies but you don't need to use it all. Or for example, use Jinja instead of its templating system

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

#275

Earlier quoted context omitted.

It’s not aimed at introductory programmers. It’s aimed at more experienced programmers to suggest to them that they can show new programmers what’s possible.

The author never really expresses the intent of the writing, so the reader is left to assume it is meant for them -- experienced programmer or no.

What part of "I think some of us who have been doing this a while have been doing a terrible job of showing what's possible to those folks who are somewhat newer." didn't you understand?

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

#276
post #116

Earlier quoted context omitted.

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

I primarily do all sorts of systems programming, but the few web backends I did were C# on Azure Functions and it was spectacular. I’m a very big proponent of Microsoft’s tooling and language development. The difference in productivity between C# and Python is such that they might as well have been developed by different civilizations. (I have occasionally used Python since about 2003 and C# since 2018)

[deleted]

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

#277
post #183

Earlier quoted context omitted.

A lot of developers never get proficient on one stack. Much less more than one.

You don't need to master one stack to get up to speed. For that investment to pay off you only need to be almost as good as you were with your old stack, which isn't hard if you already are not proficient.

I'd argue that time would be better spent actually learning any single stack properly.

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

#278

Earlier quoted context omitted.

In 2012 they were able to scale to 2 million tcp connections on a single box (and trust me, they actually needed that): https://archive.is/Jo6n

for how much time? you see lab result and real life results are different. Love it or hate it currently there is only one company that can deal with millions of users per seconds and that's Google. No one else does it, not Amazon, not Facebook including their whatsapp (a small math from my above calculation says the number goes from ~5k to ~50k if you say whatsapp has 4 billion daily users, which I doubt it has), not…

yeah no. a lot of people can do this. i don’t know why you think google is special but it’s not. maybe you can share so that i can understand your angle

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

#279

Earlier quoted context omitted.

The author never really expresses the intent of the writing, so the reader is left to assume it is meant for them -- experienced programmer or no.

What part of "I think some of us who have been doing this a while have been doing a terrible job of showing what's possible to those folks who are somewhat newer." didn't you understand?

Yeah, first sentence no less. No excuse for that one!

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

#280

Earlier quoted context omitted.

for how much time? you see lab result and real life results are different. Love it or hate it currently there is only one company that can deal with millions of users per seconds and that's Google. No one else does it, not Amazon, not Facebook including their whatsapp (a small math from my above calculation says the number goes from ~5k to ~50k if you say whatsapp has 4 billion daily users, which I doubt it has), not…

yeah no. a lot of people can do this. i don’t know why you think google is special but it’s not. maybe you can share so that i can understand your angle

already did. the bit about twitter and blizzard were 2 examples. you can google (pun intended) to search for more examples
Post reply on HN