Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

twitter.com

Post reply on HN
Print view View original

191–200 of 376 posts

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

#191

Post by otabdeveloper4 »

jacobsenscott wrote: post #170

You can choose a language that optimizes your hardware, or you can choose a language that optimizes your programmers. 99% of the time optimizing the programmers is the right call.

Yes, if by "optimizing programmers" you mean "optimizing the manager's corporate structure footprint and bonus incentives".

If the choice is between hiring one good C++ programmer or 15 really dumb Python "backend engineers" (and a team of QA's and sysadmins to support them), what do you think your pointy-hared corporate boss would chose?

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

#192

Post by useful »

PCI-e 4.0 and 5/6 enables consuming absolutely insane amounts of data. I can't think of many applications that need that.

128GB/sec? sure! and 256GB/sec is coming.

With 10Gb, 40Gb and 100Gb internet links becoming mainstream the roadblock to having cool stuff is developers to make it.

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

#193

Post by otabdeveloper4 »

coderunner wrote: post #134

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 important one for BigCorp Enterprise Inc., not development speed or cost.

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

#194

Post by pkolaczk »

Const-me wrote: post #140
lmm wrote: post #109

Earlier quoted context omitted.

The idea that GCed languages in general have Python-like performance is a dangerous myth. Languages that are managed but not interpreted (e.g. Java, OCaml, Haskell, C#, Swift) have performance characteristics that are much closer to C than to Python.

This. Modern C# in net-core 3 can even match C++ at manually vectorized numeric code: https://github.com/dotnet/coreclr/issues/27909#issuecomment-...

While I agree they can sometimes compete in numerically heavy tasks, the place where they fall behind is memory management. Systems like databases need very careful memory management and GC is not always your friend there. I'm still hoping some day we'll be allowed both GC and Rust-like manual memory management in a single language, although I'm not sure it is at all possible.

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

#195

Post by otabdeveloper4 »

mberning wrote: post #137
kyledrake wrote: post #7

The analogy here is one of the best ice climbers in the world proposing an ascent of the Matterhorn. Please use testable, easy to prototype with, memory managed languages for production servers unless you are solving a very specific problem and really know what you are doing.

Very apt. I think people are also forgetting “the bad old days” where you worked on a large-ish cpp or java app for a year, nothing worked right, schedules slipped, and then the whole thing was scrapped and teams disbanded to work on other stuff. That was very common. You can’t count on having a team of Carmacks work on your blub app.

Replace "cpp or java" with "Python or Ruby" and how is it any different today?

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

#196

Post by jacobsenscott »

otabdeveloper4 wrote: post #191
jacobsenscott wrote: post #170

You can choose a language that optimizes your hardware, or you can choose a language that optimizes your programmers. 99% of the time optimizing the programmers is the right call.

Yes, if by "optimizing programmers" you mean "optimizing the manager's corporate structure footprint and bonus incentives". If the choice is between hiring one good C++ programmer or 15 really dumb Python "backend engineers" (and a team of QA's and sysadmins to support them), what do you think your pointy-hared corporate boss would chose?

You never choose to hire dumb programmers. The choice is between 15 good cpp programmers and 4 good python programmers.

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

#197

Post by jacobsenscott »

PeCaN wrote: post #173
jacobsenscott wrote: post #170

You can choose a language that optimizes your hardware, or you can choose a language that optimizes your programmers. 99% of the time optimizing the programmers is the right call.

this is the philosophy that brought us software like atom and slack

Correct. Two very successful products.

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

#198

Post by jcelerier »

usrnm wrote: post #166
berkut wrote: post #121

Earlier quoted context omitted.

std::shared_ptr uses CAS atomics, which in heavy multithreaded code (multiple threads operating on the same pointers), can have surprising overhead in some situations.

On the other hand, not using atomics in heavy multithreaded code is just a recipe for disaster. The problem with shared_ptr is the fact that it uses atomics even in single-threaded code, which is obviously an overkill.

> The problem with shared_ptr is the fact that it uses atomics even in single-threaded code, which is obviously an overkill.

On the other hand imagine the security issues if shared_ptr was not thread-safe - you could just not reliably destroy a shared_ptr in any thread.

If you really know that you're going to get a graph of shared_ptr that do not move of a single thread, you can use boost::local_shared_ptr explicitely.

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

#199

Post by bagels »

hnews_account_1 wrote: post #132
jandrewrogers wrote: post #47

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…

Can you expand on this? I have some pretty massive compute loads that need to be scaled onto a cluster with 100+ workers for most computations. This is after I use a library called dask that graphically does its own mapreduce optimisation inside its modules. This is all for a relatively small 250GB raw data file that I keep in a csv (and need to convert to SQL at some point). Are you saying this can be optimised to f…

Not who you asked, but, it's hard to say without knowing exactly what computation is being done, or how much of the time is spent on IO. If you organize that 250GB in ram the right way (cache coherency, right container types), and spend a lot of effort doing analysis of algorithm selection, you might be surprised how much you can get done on a single (large) machine with enough cores.

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

#200

Post by shakna »

onlyrealcuzzo wrote: post #179
manigandham wrote: post #169

Earlier quoted context omitted.

Sure Reddit has more write activity but I don't see the number of replies being such a big factor. SO questions have answers, comments, tags, related questions, and many other secondary data to load. Reddit is slow due to poor architecture and a terrible frontend.

Old Reddit isn't slow. It seems to mostly be the new frontend.

Old Reddit is still slow, but not too bad. Reddit's new software stack is... Atrocious.
Post reply on HN