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

241–250 of 288 posts

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

#241

Post by andrewflnr »

epicide wrote: post #237
chris_wot wrote: post #168

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.

People don't need to explicitly audience-tag every single thing they write. I don't know if "entitled" is the right word, but it's really an annoying demand. Most times, if you can understand something, or are willing to Google the jargon, then you're part of the audience, and that's plenty of precision.

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

#242

Post by epicide »

andrewflnr wrote: post #241
epicide wrote: post #237

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.

People don't need to explicitly audience-tag every single thing they write. I don't know if "entitled" is the right word, but it's really an annoying demand. Most times, if you can understand something, or are willing to Google the jargon, then you're part of the audience, and that's plenty of precision.

I can Google medical terms until I pass out, but that doesn't make me the intended audience for a medical research paper.

Besides, I'm not suggesting (or "demanding") that all articles explicitly state their target audience. Just that this one does a poor job of indicating it.

So I think it's a poor argument when the parent comment (to which I was responding) assumes an exclusive target audience: "not introductory programmers... more experienced programmers".

You could argue that one was supposed to assume that from context. However, I didn't make that assumption whilst reading, so I especially wouldn't expect "introductory programmers" to pick up on that either.

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

#243

Post by dnautics »

theelous3 wrote: post #220
rejschaap wrote: post #208

Earlier quoted context omitted.

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

Which I read as "I have no experience whatsoever with modern python, and async is something that catches water". Async is typically less prone to error and complexity than thread code, and also typically faster/lighter for io (in python). I can't see a reason for this not to be the case in other languages too.

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 a single threaded system with the right type of dispatcher. However, small amounts of complexity rapidly devolve into towers of async calls that cannot be untangled from a spaghetti pile, and there's not really satisfying ways of figuring out how to unwind error-handling in async, except for the basic case of "I truly don't care if this async fails".

I will say though, it's spectacularly easy to write messy and garbage code in all four of these concurrency models (I certainly have). My preference for actors comes from four opinions:

- some systems (if you want to be flippant, microservices architecture) use actors to encapsulate failure domains, which is really fantasic, and truly the #1 reason to use actors

- 99.8% of the time no need to write mutexes, and good actor systems basically won't deadlock unless you really try hard. (also true for async system btw)

- gives you an organizational framework to write well-designed and well-engineered systems.

- with a small amount of discipline "not having a spaghetti ball" scales with complexity (I find it takes a lot of discipline to not have a spaghetti ball with async in the more complex cases)

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

#244

Post by yowlingcat »

Aeolun wrote: post #145
yowlingcat wrote: post #58

``` First of all, it does not take "that much machine" to serve a fair number of clients. 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. ``` Another day, another questionable premise for a blog post. No, @rachelbythebay, the question is not "if n…

> If you have a language you're proficient in and with an ecosystem that supports you developing something rapidly, it's borderline malpractice not to start there. I think the point of this post is that most new programmers do not know things can be faster than their monstrous JS blob. The solution to slow requests is more servers instead of fixing the code.

It's fascinating that you see the misguided impulse being prematurely adding more servers rather than fixing the code. I would agree with that, but I would also see the premise of this blog post as a similar misguided impulse -- rather than fixing the code, writing a completely new part of infrastructure from scratch in a new language because the old one wasn't good enough. Unless you've exhausted reasonable attempts to optimize existing code inside the language the original code was written in, I believe that following this impulse would be (as I alluded to in my original comment) borderline malpractice.

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

#245

Post by yowlingcat »

Doxin wrote: post #185
Aeolun wrote: post #145

Earlier quoted context omitted.

> If you have a language you're proficient in and with an ecosystem that supports you developing something rapidly, it's borderline malpractice not to start there. I think the point of this post is that most new programmers do not know things can be faster than their monstrous JS blob. The solution to slow requests is more servers instead of fixing the code.

> I think the point of this post is that most new programmers do not know things can be faster Related to this: programmers who know an ORM or two but never learn SQL proper. At my job I refactored a giant, slow, memory hungry reporting task into a single sql query. It used to take 10s of minutes to collate 1000s of datapoints. Now it takes 10s of miliseconds to collate a factor 10 more data. Never mind after I added…

What's telling here is that you refactored the individual task into a single query, and nothing outside of that. That's fantastic! You scoped your work into a small unit and derived a significant impact. You maximized your impact to effort ratio.

Notably, you did NOT decide to write your own dialect of SQL to "scratch an itch". Knowing the layer below the abstraction you're working at can be useful at times, but only in relation to understanding the context of how all the layers fit together and making effective, pragmatic decisions. Pointless rewrites are anything but. Good on you for avoiding that impulse and doing the right thing.

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

#246

Post by luhn »

robrtsql wrote: post #135

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

As a fellow Python user, honestly I think you're fine. Rachel's issue with gunicorn stems from the gevent stuff, which you probably don't need and I would avoid unless you do.

I'm a bit mystified by Rachel's use case—A green thread hogging the process for so long that another request times out on the client? That means that requests are doing large amounts of processing and latency requirements are super tight, which sounds like a very specialized use case.

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

#247

Post by rumanator »

tetha wrote: post #222
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…

Writing code is one thing though. Now you have to figure out how to run a CI on a build server. Deployment on your production systems, be it containers or even not. Monitoring, alerting, profiling, tuning under load. You have to support a new database connection library with new shenanigans. In general, you need to integrate the new language into the existing ecosystem. The latter may even be impossible depending on…

> Now you have to figure out how to run a CI on a build server. Deployment on your production systems, be it containers or even not. Monitoring, alerting, profiling, tuning under load. You have to support a new database connection library with new shenanigans.

Most if not all of those items are either trivial or non-issues.

In fact, I would argue that deploying a Python app is a far more convoluted process than getting an ASP.NET Core app up and running.

With Docker, the problem simply disappears.

Getting it to build and test on a CICD pipeline is as hard as typing $ dotnet build, or $ dotnet test.

> All of that is possible, sure.

Not only it is possible, it's laughably easy.

We are supposed to avoid our problems, not perpetuate and aggravate them as eternum because we are too lazy to look for ways to make our life easier.

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

#248

Post by rumanator »

vidarh wrote: post #183
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…

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.

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

#249

Post by rumanator »

flukus wrote: post #194
rumanator wrote: post #171

Earlier quoted context omitted.

> 1) .NET APIs change very frequently. ASP.NET Core 2.1 was released in 2018 and will be supported until late 2021. ASP.NET Core 3.1 was released a few months ago and there is no end of support in sight. Moreover, the changes between 2.1 and 3.1 were not that many. I've migrated a whole ASP.NET Core 2.1 web service to 3.1 in less than 1 hour. > 2) C# is a very verbose language, that requires a lot of typing. Nonsense…

> 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, depending on how you decide to count.

> This is why so many companies stick with their ancient COBOL systems, most modern alternatives don't offer the stability they need.

This assertion is simply wrong at so many levels. Don't confuse "why waste money maintaining working software" linesof reasoning as a sign of respect for stability.

More importantly, it's disingenuous to even think of the technical debt that keeps cobol on the map as relevant to the world of web services.

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

#250

Post by kragen »

epicide wrote: post #242
andrewflnr wrote: post #241

Earlier quoted context omitted.

People don't need to explicitly audience-tag every single thing they write. I don't know if "entitled" is the right word, but it's really an annoying demand. Most times, if you can understand something, or are willing to Google the jargon, then you're part of the audience, and that's plenty of precision.

I can Google medical terms until I pass out, but that doesn't make me the intended audience for a medical research paper. Besides, I'm not suggesting (or "demanding") that all articles explicitly state their target audience. Just that this one does a poor job of indicating it. So I think it's a poor argument when the parent comment (to which I was responding) assumes an exclusive target audience: "not introductory pr…

You can probably understand most medical research papers after reading a few dozen medical Wikipedia articles and taking an introductory stats class. Math and physics research is a little more difficult.
Post reply on HN