Live data from Hacker News

A lot of complex “scalable” systems can be done with a simple, single C++ server

twitter.com

81–90 of 376 posts

Re: A lot of complex “scalable” systems can be done with a simple, single C++ server

#81
post #54

A site for proof. It keeps amusing me on what hardware/software Stack Overflow/Stack Exchange is running on: https://stackexchange.com/performance This is way less in HW than most people in the trade (from web devs to devops) seem to think when asked about it. SO ranks #36 in Alexa right now: https://www.alexa.com/siteinfo/stackoverflow.com

Note that they use C# and ASP.Net... (SO and DailyWTF are very much into Microsofts ecosystem)

AFAIK they're using ASP.NET Core

There's significant difference between ASP.NET and ASP.NET Core

https://meta.stackexchange.com/questions/316278/the-road-to-...

Re: A lot of complex “scalable” systems can be done with a simple, single C++ server

#82

Many developers severely underestimate how much workload can be served by a single modern server and high-quality C++ systems code. I've scaled distributed workloads 10x by moving them to a single server and a different software architecture more suited for scale-up, dramatically reducing system complexity as a bonus. The number of compute workloads I see that actually need scale-out is vanishingly small even in indu…

Two. The number is two. You always need a backup server :)

Three. So you can do maintenance on one while still having HA.

Re: A lot of complex “scalable” systems can be done with a simple, single C++ server

#83
people will bike to work to "save the environment" but won't use C direct on metal to reduce the carbon footprint of their code.

For a guy like Carmack, it may be quite frustrating working with the constraints of pytorch etc. He ll probably end up making his own pytorh frontend in C, which as a bonus people will use to deploy models.

Re: A lot of complex “scalable” systems can be done with a simple, single C++ server

#84
post #2

I've been programming C++ and assembly for 23 years. Few years ago I became a huge fan of Python. In my opinion Python is amazingly well suited for rapid first revision and can then be swapped out for C++ / asm.

This is fine as long as you can convince management to spend the money to rewrite your software. That's usually a hard sell though. In my experience this plan usually ends up with a python monstrosity that everyone hates but is forced to deal with forever.

Re: A lot of complex “scalable” systems can be done with a simple, single C++ server

#86
post #83

people will bike to work to "save the environment" but won't use C direct on metal to reduce the carbon footprint of their code. For a guy like Carmack, it may be quite frustrating working with the constraints of pytorch etc. He ll probably end up making his own pytorh frontend in C, which as a bonus people will use to deploy models.

I don’t think it’s that big of an language issue. Java isn’t that much slower (logarithmically speaking). But design choices have arbitrarily incorporated huge amount of bloat and inefficiency.

Re: A lot of complex “scalable” systems can be done with a simple, single C++ server

#87
post #54

A site for proof. It keeps amusing me on what hardware/software Stack Overflow/Stack Exchange is running on: https://stackexchange.com/performance This is way less in HW than most people in the trade (from web devs to devops) seem to think when asked about it. SO ranks #36 in Alexa right now: https://www.alexa.com/siteinfo/stackoverflow.com

At the risk of exposing my ignorance - look at all those "Peak 5%-20%" labels. Doesn't that mean they have a lot more than they need?

[deleted]

Re: A lot of complex “scalable” systems can be done with a simple, single C++ server

#88
post #54

A site for proof. It keeps amusing me on what hardware/software Stack Overflow/Stack Exchange is running on: https://stackexchange.com/performance This is way less in HW than most people in the trade (from web devs to devops) seem to think when asked about it. SO ranks #36 in Alexa right now: https://www.alexa.com/siteinfo/stackoverflow.com

At the risk of exposing my ignorance - look at all those "Peak 5%-20%" labels. Doesn't that mean they have a lot more than they need?

Nick Craver went into that a bit here. https://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-...

Re: A lot of complex “scalable” systems can be done with a simple, single C++ server

#89
post #83

people will bike to work to "save the environment" but won't use C direct on metal to reduce the carbon footprint of their code. For a guy like Carmack, it may be quite frustrating working with the constraints of pytorch etc. He ll probably end up making his own pytorh frontend in C, which as a bonus people will use to deploy models.

I don’t think it’s that big of an language issue. Java isn’t that much slower (logarithmically speaking). But design choices have arbitrarily incorporated huge amount of bloat and inefficiency.

yep, logarithmic. Well, the question is what's the motive about those design choices? Today's e.g. web app choices seem to be basically aesthetic with an eye for extreme novelty, and total disregard for how many times a buffer is being copied back and forth before reaching the user.

Re: A lot of complex “scalable” systems can be done with a simple, single C++ server

#90
post #53

Earlier quoted context omitted.

Good question, not sure why you were voted down. And I’m not even a Rust fan.

I was curious mainly because I remember some long comments he made about the relative value of linting and static analysis tools, specifically going into Coverity's analysis of the Doom 3 code (I think), fixing everything it flagged for some subset of the code, and then asking himself whether it was really better or more of a hindrance that obfuscated code. IIRC, his conclusion was mixed: a lot of it was obviously be…

Right. He’s got some kind of notorious programming style with who knows what kinds of object graphs. It would be quite a data point to know if he thinks that he can comfortably map it to Rust.
Post reply on HN