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.
A lot of complex “scalable” systems can be done with a simple, single C++ server
241–250 of 376 posts
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#242Horizontal 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.
"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
#243Earlier 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…
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#244Earlier 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…
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
#245Earlier 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.
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#246Carmack 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
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#247Yes, 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…
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#248A 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)
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#249What 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…
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#250Earlier 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 (…
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.