‹ BackHN Continuity

Thread

Saving another 100TB of RAM

488 points · 123 comments · f311a

  1. zer0x4d · · focus · HN ↗
    Incredibly happy to see this series of CF articles. I was always so proud of devs back in the days where RAM and processing were scarce and who had to get creative to fit even the most basic stuff in the budget. It seemed to me that after RAM and processing became abundant, most gave up on optimization and focused on shipping instead which meant now that even with several cores, a basic notepad or music player failed to work. In a way, RAM becoming more expensive has ushered in a new era of forced optimizations, which I'm really happy for
    1. jfengel · · focus · HN ↗
      I don't remember those days with a ton of fondness. Yes, the challenge was fun, but I really wanted to ship it and get my product in the hands of customers. Now I can spend more time thinking about what they want and less time about what the computer wants.
      1. switchbak · · focus · HN ↗
        Yes, I remember those too. The costs of manual memory management were real and were not low.

        But costs on the cloud are real too, especially now. I’ve been living in JVM land for a very long time, but now it’s especially clear how important lean services are. Especially now that the bar for writing lean code is so much lower: let the borrow checker figure it out, etc.

        I just spent a couple days wringing out more performance/memory efficiency for our services. Nice gains to be sure, but it’s still so immensely wasteful compared to something well written running native. If it was my money, I’d be going native for sure.

        1. locknitpicker · · focus · HN ↗
          > But costs on the cloud are real too, especially now. I’ve been living in JVM land for a very long time, but now it’s especially clear how important lean services are. Especially now that the bar for writing lean code is so much lower: let the borrow checker figure it out, etc.

          I don't think even Cloudflare bothers with this waste of time. If they did, they would certainly not have built their global infrastructure on JavaScript running on V8. They'd have done what Google and old-time Facebook did and built their whole infrastructure on low-level system languages, and hiring the world's leading minds on the subject to milk the last drop of performance from their hardware.

          Even Google stopped to look at the problem and came up with Go. Not V8.

          1. switchbak · · focus · HN ↗
            All those things happened before the era of decent AI.

            Also, it really does matter what you're building. Yet another CRUD app? Don't waste time on (super) lean languages - use Go or something else you like and move on.

            Building a Kafka replacement? Making something that processes gobs of data quickly? Perhaps think about using something lean and efficient, as the economics have changed. "waste of time" (or memory) also applies to the cloud and your (or your company's) bill. And if you haven't noticed, you're being ripped off on the cloud, running something 10-50x less efficient has real bottom line impact.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.