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

171–180 of 288 posts

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

#171

Post by rumanator »

29athrowaway wrote: post #125
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…

1) .NET APIs change very frequently. 2) C# is a very verbose language, that requires a lot of typing. 3) F#, the best language in .NET, is largely ignored by the .NET community.

> 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. The only added verbosity to C# when compared with Python are the type declarations, which arguably are a problem plaguing Python. The first class support for events and async programming and properties in C# more than make up for it.

> 3) F#, the best language in .NET, is largely ignored by the .NET community.

I fail to see what point you were trying to make.

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

#172

Post by 29athrowaway »

rumanator wrote: post #171
29athrowaway wrote: post #125

Earlier quoted context omitted.

1) .NET APIs change very frequently. 2) C# is a very verbose language, that requires a lot of typing. 3) F#, the best language in .NET, is largely ignored by the .NET community.

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

Compare C# with Kotlin or Scala and you'll find that involves a lot of redundant, boilerplate code.

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

#173

Post by Doxin »

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…

Not to mention that python is plenty fast compared to the time it takes to write stuff to the network. Of course heavyweight frameworks like django don't help the equation, but writing fast network code in python isn't exactly hard either.

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

#174

Post by rbinv »

Aeolun wrote: post #139
sytringy05 wrote: post #124

Compare this to the Enterprise platform I am dealing with on a current project, which has 4 x ec2 nodes with 8 CPUs and 32 Gb RAM. I can DoS it with a single java client running 50 threads. If I use 100 the p95 shoots up to 30 - 40 seconds. But the kicker is that no one (other than me) really cares. 50 concurrent threads is probably around the peak load it will get in prod, and various people involved think why bothe…

Oh man, don’t remind me. We have a bunch of GraphQL proxies in ECS that somehow cannot handle more than 5 connections each, so naturally the solution is to just spin up 19 more of them to get to 100 concurrent connections... All of them sit at 1% cpu as well.

That actually made me laugh. The time savings can't possibly be worth it.

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

#175

Post by thdrdt »

xeroalt wrote: post #120
stev_stev wrote: post #55

Earlier quoted context omitted.

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.

I am a little confused by your post. Moving to Django is the wrong way?

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

#177

Post by closeparen »

jefurii wrote: post #149
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…

> I feel like with modern technologies like ... we ought to be able to do a lot of things that we couldn't even imagine doing in 2005... As a self-taught programmer I would say that what all these less efficient bit easier to learn technologies have done is enable people like me who evidently are not geniuses like yourself to write software. Should programming always be an ivory tower thing?

It does take geniuses to design and operate the incredibly complex cloud-native distributed systems we all insist on doing now.

It’s fair to point out how far you can get just programming one computer using traditional and well understood concepts like sockets and threads. And how weird it is that we live in a world where Kubernetes is mainstream and fun but threads are esoteric.

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

#178

Post by pdonis »

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…

> It's totally reasonable for a company to choose the Python/Gunicorn option

Yes, if done properly. The issues with the particular Python/Gunicorn setup the author described in an earlier article (linked to in this one) were not so much Python/Gunicorn issues as "not understanding how to properly use Python/Gunicorn" issues, or more generally "not understanding how the tool you are trying to use actually works" issues. (I actually shudder to think what such a group would have done trying to program the same application in C.)

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

#179

Post by kccqzy »

Doxin wrote: post #173
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…

Not to mention that python is plenty fast compared to the time it takes to write stuff to the network. Of course heavyweight frameworks like django don't help the equation, but writing fast network code in python isn't exactly hard either.

> python is plenty fast compared to the time it takes to write stuff to the network

With the proliferation of microservices, I find this increasingly not true. Sure, python definitely is plenty fast when you need to send something to a user many miles away. But with microservices, writing to the network might mean writing to a machine in the same data center, or even the same host in a different container. That's as fast as a few memory copies and a few context switches.

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

#180

Post by pdonis »

xeroalt wrote: post #120
stev_stev wrote: post #55

Earlier quoted context omitted.

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.

I've tried working with Django and it's always seemed much too heavyweight to me. Flask is my preferred web framework for Python; much easier for me to use and feels like it's helping me where needed and getting out of my way where needed, not weighing me down.
Post reply on HN