Hacker News Reader

Comment by wpietri | Hacker News Reader

Just from the title, I would have expected the opposite approach: not treating RAM as a disk cache, but using RAM only and ignoring the disk. One of the biggest differences between now and then is that we've gone from RAM deficit to RAM surplus. (The VMs that contain so much of today's software can be seen as a way of cutting too-big physical RAM back down to slices that match problems.)

This means that batch orientation makes sense for a much smaller slice of problems. Compilers, for example, come from a world of scarce RAM. When my dad started coding, one iteration of change-the-code-and-watch-it-run took days. Now that loop can be seconds: if I pause typing, my IDE starts running my unit tests automatically. It seems to me that things like compilers and runtimes should by default keep everything hot, incrementally updating as fast as possible.

View on HN

> Now that loop can be seconds: if I pause typing, my IDE starts running my unit tests automatically. It seems to me that things like compilers and runtimes should by default keep everything hot, incrementally updating as fast as possible.

Is it only me that finds this incredibly distracting?

When I write code I pause often. It might be in the middle of a sentence, or a function definition, the most recent example I can think of is because I realised I needed another function, and this function's state is dependent on it, or I needed to look something up. Getting my mindstate trashed every time I pause because it's found a dozen irrelevant errors sounds horrifying.

Agreed, I hate that. I don't want to hear about test failures, syntax errors, compile errors, or anything like that until I ask for it.

It's a matter of UX. If the errors are displayed in a subtle way it's not an issue.

Because there's latency. It wouldn't be distracting if there's no latency at all because it feels natural even if the code is in stale shapes.

I use Wallaby[0] to run JavaScript tests, and it shows the result on the fly just near every line of test code. The latency is very small so it's hard to notice it.

After I was used to this approach the idea of press the test button, and waiting for 1s to compile, another 3s to run tests is simply tormenting. It breaks the flow because I have to repeatedly wait for the computer to catch my thought.

[0]: https://wallabyjs.com/

I think one could make the same argument for a zillion things a modern IDE does, from syntax highlighting forward. It's more of a problem in theory and on early use than it is for sustained use.

For unit tests in specific, if the interface is designed well and one is used to TDD anyhow, I think the distraction goes away pretty quickly. When I'm used to TDD, I always have a bit of my mind on what the test impact is, so if the errors showing are the ones I expected anyhow, then it's not disruptive at all. Indeed, it's welcome confirmation that I'm not off track.

That's how syntax highlighting and feedback feels for me too. I may pause at a point with unparseable code, so some things will be the wrong colors and may be marked with issues. It's fine, because that matches my mental syntax parser. And when it doesn't, I'm glad to learn as early as possible that I have an issue somewhere.

We have come a long way since 2006 in terms of both storage and RAM. There are a lot of Varnish servers out there running straight out of RAM, and some of them have a /lot/ of RAM.

But the most important question is your data set and your traffic pattern, and whatever that is, Varnish can deal with it, given suitable hardware.

The viewpoint of phk, the squid disk cache is the only thing that matters and ram is simply there to accelerate the hottest data.

Multipass compilers were originally engineered that way because there simply wasn't available memory to keep all the intermediate data in memory.

Now the nature of compilers has gone from batch to incremental to handle the feedback the IDE needs to give to the programmer.

As a general rule, I would suggest people refrain from trying to express what my viewpoint is, because, quite frankly, N-1 person on this planet suck at it :-)

There still is a cost differential between 1TB RAM and 1TB disk, and that matters in the real world.

Varnish lets you decide where you want to spend your money, if you want to run straight out of RAM, it can do that, if you want to have a bigger cheaper and slightly slower cache on disk or ssd, you can do that too.

I didn't put enough caveats, I should have said, "the viewpoint that I think phk is trying to express _in this article_ ..." :)

You have written enough publicly that we could probably cook up a GPT2 level simulacrum with your posts. Useful for code reviews, discussions, etc.

Aren't we saying the same thing? The RAM is there to support the disk and the disk holds the data (the asset), so your article is disk centric. If disk was fast enough, there would be no ram. The ram is just a tool to support a latency target.

Remember 2006 ? You know, back when Twitter was a new thing :-)

Back then you couldn't buy machines with 1TB of RAM, most systems were 32bit and limited to about 3GB usable RAM.

Varnish was written with 64bit in mind from the start, but it also had to work on 32 bit systems, so we had to be able to use disk-backed VM to get past a couple of GB.

Reply on news.ycombinator.com