Live data from Hacker News

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

twitter.com

241–250 of 376 posts

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

#241
post #75

Earlier quoted context omitted.

The push for the need of scaling out started with Ruby and Python's lack of performance. The reason being pushed at the time was, "developer time was more expensive than hardware." Well, that didn't count the amortization of developer time over the lifetime of the product once the product was developed.

It's mostly a fallacy that a demanded product becomes "developed". Maybe a game that gains cult status and therefore a long tail end of life. But popular web services are in constant churn and in that space it's valid to trade hardware for programmer productivity.

Backend web development doesn't change much once developed. How many ways can one do CRUD on the backend?

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

#242
post #111

Horizontal scalability carries a lot of overhead. Probably a factor of 10, easily. But the clue is in the name: eventually you'll get to a point where you have to scale. Back in 2010 I worked for a company whose system, in Java, ran on a single web server (with one identical machine for failover). We laughed at our nearest rivals, who were using Ruby, and apparently needed 60(!) machines to run their system, which ha…

Web servers are usually trivially horizontally scalable. You must have had significant in-memory shared state to encounter that problem. Right? Had you adopted a less stateful model, you'd have looked rather pretty with two Java servers.

> You must have had significant in-memory shared state to encounter that problem. Right?

"Significant" is in the eye of the beholder. The core of the system was easy to make shardable. But you'd be surprised how many implicit assumptions creep in, how easy it is for ancillary parts to end up sharing state when it's easy. Also note that just because your state's in a database doesn't mean having two instances of the thing that accesses it will work, you can easily end up with an access pattern that assumes only one reader (for example) even though on paper there's no in memory state.

> Had you adopted a less stateful model, you'd have looked rather pretty with two Java servers.

Maybe. At the point where we're running 4 or 8 servers we'd have been facing much the same ops problems that they were. Java bought us an extra year or two of not having to deal with that, but also a significant amount of migration work when it just became impossible to stick to the single process model. At the end of the day we still kept the 5x latency advantage, which is definitely not nothing. But there were also definitely features that they brought to market quicker, and I'm pretty sure Ruby played a part in that.

Tradeoffs, tradeoffs everywhere. I left before the final outcome of that fight (for all I know it's still ongoing), but I don't think either company was being dumb.

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

#243
post #227
post #210

Earlier quoted context omitted.

I'm starting to wonder if there is market to do "technology laundering", use things like PostgreSQL, SQLite, standard Unix tools, put it under some cloud marketing and charge a x10 premium. Or perhaps not only there is market, but that's more or less what everyone is already doing.

If you can set it up so it solves my problems, yes. I could manage my own server and fine tune everything, or I can throw it on snowflake. Snowflake means I've spent almost no time managing anything and it was costing less than an aws box running postgres but absolutely blew it out of the water performance wise. Depends on your workload but it's been perfect for one of my use cases. If they were just using postgres u…

I know nothing about Snowflake so can not really comment on particular case. However the generic statement that I hear often goes something like this: it is so much trouble to manage your own infrastructure and on cloud everything is done for you. Well I saw with my own eyes that having ones's infrastructure deployed on Azure keeps them quite busy anyways.

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

#244
post #238
post #155

Earlier quoted context omitted.

No doubt there are people who do it for cynical reasons. But at least some people do it sincerely thinking it’s the right choice. It’d be more interesting to talk about them, and how they came to make the wrong decision for what they thought were the right reasona.

Talked to many people lit you mentioned. Large percentage repeats these points: 1) We always wait for database, so performance of our code does not matter . This comes from places where ironically the whole database can fit into RAM. 10+ gbps connectivity - well it is almost commodity for business so the latency is not much of a bottleneck. Fast IO to store data - well imagine array of Optane drives. Not very cheap b…

> Sorry but experienced developer can implement those just as fast as in any scripting language and it will save a ton on maintenance.

This is just a no true Scotsman argument. For 10 years I’ve watched python/ruby shops drastically outpace projects in C++/Java shops. What you’re failing to realize is how trivial most apps are and how fast fully functional back ends can be created with frameworks in those languages (django/rails).

Your bit about maintenance is also bullshit. I’ve spent entire days peeling apart complex C++ code bases to make a small change to some core abstraction. Ability to maintain code is entirely up to how well organized and documented it is. It has nothing to do with “scripting”.

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

#245
post #149
post #58

Earlier quoted context omitted.

Isn't D dead practically? https://news.ycombinator.com/item?id=21902953

I have watched the ocaml community go through a renaissance when for a while it looked like it was moribund, and the D community looks like it is developing the same undercurrent of momentum. given that D is a great language and the implementation looks solid, I don't think it is in danger of dying.

Ocaml always enjoined institutional support such as from Inria.

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

#246

Carmack is moving to AI and inevitably has to deal with a lot of Python, which still bottlenecks process here an there despite all the effort to move computation to C extensions. I have a really high hope that he detours a bit and creates very-very good non-python tooling for ML.

Maybe he could make Python fast once and for all :p

Python has some fundamental language semantics that make it really hard, if not impossible, to create an implementation that can match Java. Pypy is probably the best you can do to optimize python, and it shines in tight numerical loops, but it gets less effective as code gets more complex.

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

#247
post #60
post #41

Yes, I’m always shocked by just how much performance overhead most languages have compared to C and similar lower level languages. It is a price worth paying for better language ergonomics, but I do wonder whether Rust might be able to give us the best of both worlds here.

I semi-seriously think the entire modern shape of the cloud is a result of Ruby being really slow. Back when people were writing their backend business apps in C++, COBOL, Java, etc, if there was ever a performance problem, you could usually just get a slightly bigger machine and grow your thread pools a bit. But once the web took off and Ruby exploded onto it, you couldn't do that, because it's an order of magnitude…

Your points are all valid, but I don't think it's the "unquestioned" way. It simply happens to be great way to scale, and also to isolate complexity etc. You can scale to monster loads this way, they way that in-process caches don't.

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

#248
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)

Anything wrong about that?

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

#249

What about in the context of trying to get to an MVP? Is the dev time speedup of using a dynamic programming language and stack significant over using a c++ backed? You wouldn't care much about performance when you're trying to figure out if you'll get traction.

No, it's not significant. Dev time depends on programmer skill, not the toolset. A good C++ programmer will develop your MVP many times faster than an average Python programmer. Python programmers are much easier to hire, though - you already need a good C++ programmer on the team to hire another one, because HR and corporate management can't into proper hiring process. This last factor is the overarching most import…

The same argument can be made for Python (or for most non-trivial jobs, for that matter). You always need a good technical person to hire another one.

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

#250
post #238

Earlier quoted context omitted.

Talked to many people lit you mentioned. Large percentage repeats these points: 1) We always wait for database, so performance of our code does not matter . This comes from places where ironically the whole database can fit into RAM. 10+ gbps connectivity - well it is almost commodity for business so the latency is not much of a bottleneck. Fast IO to store data - well imagine array of Optane drives. Not very cheap b…

> Sorry but experienced developer can implement those just as fast as in any scripting language and it will save a ton on maintenance. This is just a no true Scotsman argument. For 10 years I’ve watched python/ruby shops drastically outpace projects in C++/Java shops. What you’re failing to realize is how trivial most apps are and how fast fully functional back ends can be created with frameworks in those languages (…

> What you’re failing to realize is how trivial most apps are and how fast fully functional back ends can be created with frameworks in those languages

A vast majority of web dev is incredibly simple. People tend to easily convince themselves that their app is very special and requires a lot of complex solutions to make it work. There’s a lot of incentives that lead people to that conclusion, but most of the time following the golden path laid out for you by an existing framework is going to produce a better product with much less effort.

Post reply on HN