[Silhouette]

Which is kind of horrifying, if you stop and think about it. You're wondering whether you need another 32G of RAM to run a basic working environment, a glorified text editor, and some communications software. I used a BBC that could do that in 32K of RAM in the 1980s! Obviously I'm not really suggesting the functionality today is equivalent, but the idea that ultimately you're meeting the same basic needs yet it now takes a million times as much space is... unsettling.

[MrBuddyCasino]

Its certainly amazing how much memory consumption has grown. I like to think of it in terms of economics, we could never write today's software using 80s methods. Slack in assembler? Impossible. Kubernetes in C++? Maybe, but there will be security holes, and Go is just more productive. Developers are expensive, very expensive.

[Silhouette]

Developers are expensive, very expensive.

Such is the accepted wisdom in much of the industry, but I'm a bit of a sceptic on this score. Of course developer time is expensive, particularly if you're in somewhere like the Bay Area where salaries are an extra 0 compared to most of the world. But we live in an era of virtualisation and outsourcing (sorry, "cloud computing") when businesses will knowingly pay many times the cost of just buying a set of servers and sticking them in a rack in order to have someone else buy a much bigger server, subdivide it into virtual servers, and lease them at a huge mark-up. All kinds of justifications have been given for this, many of which I suspect don't stand up to scrutiny anywhere other than boardrooms and maybe golf courses.

There's a nice write-up somewhere, though regrettably I can't immediately find it, of the economics of cloud-hosting an application built using modern trends. IIRC, it pitched typical auto-scaling architectures consisting of many ephemeral VMs running microservices and some sort of orchestration to manage everything against just buying a small number of highly specified machines and getting on with the job using a more traditional set of skills and tools. Put another way, it was the modern trend for making everything extremely horizontally scalable using more hardware and virtualisation against a more traditional vertical scaling approach using more efficient software to keep within the capacity of a small number of big machines. The conclusion was astonishingly bad for the modern/trendy case, to the point where doing it was looking borderline insane unless your application drops into a goldilocks zone in terms of capacity and resources required that relatively few applications will ever get near, and those that do may then move beyond it on the other side. And yet that horizontal scaling strategy is viewed almost as the default today for many new software businesses, because hiring people who are good enough to write the more efficient software is assumed to be too expensive.

[asdff]

We live in a world where any 1 man startup thinks and their investors hope they will have 10k employees by year end. Therefore, if you are going to be burning money anyway, what's another line item on the monthly outflow if it means you don't have to spend 3 months hiring someone to toil in the server room and a couple months ordering and assembling your farm that might crash the day your startup gets linked on hacker news.

There are technical reasons for this, being able to handle sudden load, but mostly it's for ideological reasons. We aren't building companies, we are building stock pumps guised as the utopian future. If you are wondering what a blue chip company looks like in tech, they are the ones that own their own infrastructure.

Maybe there is a middle road for cash poor companies, where you keep latent demand in house for the sake of cost and sense, but have some sort of insurance policy with a cloud service to step in if demand surges.

[henrikeh]

I’m not well-versed at all in Go and Kubernetes? Isn’t the large RAM usage from the usage of containers? Is Go a memory-hog?

[MrBuddyCasino]

Its a GC language, so yes it needs more than C++, but less than Java. I believe that is because often structs can live on the stack.

[ecnahc515]

We don't have the same basic needs. People are running VMs on their laptops so they can test things in an environment similar to production without having to run extra servers for every developer/sysadmin to test with. Back in the 80s you're QA and Production environment were very likely the same!

I'll admit that modern text editors and communication software have grown resource hungry, but a lot of that comes from being able to deliver a strong, cross platform experience. I remember desktop Java doing much of the same with just as bad resource usage. Same with applets.

[Silhouette]

People are running VMs on their laptops so they can test things in an environment similar to production without having to run extra servers for every developer/sysadmin to test with.

Sure, but that immediately raises the next question of why those VMs are so big...

[wahern]

Yeah, the fixed cost of a VM context is on the order of kilobytes in the host kernel, megabytes in the guest kernel. And with VM balloon paging a guest VM acts much like a regular process in terms of memory usage. It's not VM usage that hogs memory, it's the applications, regardless of VMs.

[vbezhenar]

Why does it matter when you can afford that RAM? Just buy and forget about it, it's cheap enough. We used to land to the moon with CPU less performant than Apple's HDMI adapter cable, it's fun comparison but not very useful, that's just the way things are and it's not going to change anytime soon.

[Silhouette]

I realise it's how things are today and not going to change any time soon, but it still feels like we as an industry have moved all too easily in a very wasteful direction. Sure, with RAM you can just buy more, but it's symptomatic of a wider malaise. Other capacities, particularly CPU core speeds, have long since stopped increasing on a nice exponential-looking curve to compensate for writing ever more layers of ever more bloated software in the name of (presumed) greater programmer efficiency. It just feels like we've lost the kind of clever, efficient culture that we used to have, and I'm not sure we weren't sold a bill of goods in return.

[vbezhenar]

I'm not sure whether curve is still exponential or not, but it's there. Single-thread performance is increasing every year a little bit and core count is increasing like never before. 16 cores consumer CPU is not a dream anymore.

RAM size slowly increases as well. 4 GB was enough 10 years ago. 8 GB was enough few years ago. Today I would suggest 16 GB as a bare future-proof minimum and one can buy 64 GB for a reasonable price.

We still have room for more layers. And it's not only about efficiency, it's also about security. Desktops are still not properly sandboxed, my calc.exe still can access my private ssh key.

Once performance growth will really stop, we will start to optimize. Transistor density will double every few years until at least 2030 and AFAIK there are plans beyond that, so probably not soon.

[saagarjha]

> Why does it matter when you can afford that RAM?

Why should everyone have to afford that RAM?