Hacker News Reader

Comment by romwell | Hacker News Reader

Original observation: programs do a lot of things you didn't ask for.

This response: well, actually™ you really want all these things you didn't ask for. And don't worry about that bloat, the memory is cheap and the CPUs are fast.

So, the points of the original article still stand (this "response" does not address them in any way).

The claim about 100ms latency being imperceptible is the cherry on the top. Try delaying a drum track by 100ms and listening to it without pain (or try singing karaoke into a mic with that much latency).

But that's beside the point, which is that all these programs are doing a lot of things you didn't ask for and take megabytes to do that.

View on HN

I don't think this is a fair summary of what I said.

These were my points:

1. Performance improvements of interactive programs below a certain threshold are imperceptible and therefore of negligible value.

2. A minimalistic program does not always lead to better performance.

3. Compilation involves trade-offs and binary size and the number of syscalls executed are not the only things that matter.

4. The syscalls emitted by these programming languages are there for a reason and provide significant value to developers and users.

I nowhere stated that memory was cheap, but I agree that CPUs are fast.

As for latency, quibble with the numbers, but I don't think a user will ever notice the few hundred microseconds difference between the Go version and the ASM version.

> But that's beside the point, which is that all these programs are doing a lot of things you didn't ask for and take megabytes to do that.

Yes. And it both doesn't matter and optimizing them away has drawbacks.

Theoretically the points in the original article could matter - writing a very simple tool with Electron for example. But the example given wasn't anything like that.

> As for latency, quibble with the numbers, but I don't think a user will ever notice the few hundred microseconds difference between the Go version and the ASM version.

You do realize there's a huge difference between a few hundred microseconds and the 100 milliseconds you were talking about?

If 100 ms is bloat, what is 8-10 seconds of J2EE application startup?

His points were that much of the tradeoffs may lead to higher productivity and even performance.

The point wasn't about startup time. The point s/he was making was that complexity can be a good thing in certain cases.

No one would ever expect or claim that a JEE application would have a fast startup time. That's not the level of complexity JEE is trying to optimize for.

do you agree that there are tradeoffs is system design?

A plane could weigh a lot less if we removed all the computers and sensors that it carries. However, as logical beings we make the trade off because speed isn’t as important as safety.

Great example! An airplane only carries the stuff that it actually needs.

Aerobus A380 carries 300 miles of wires in its body.

You can be absolutely sure that a Cessna 152 does not.

Putting all of A380's wires in a Cessna 152 is not a trade-off, it's insanity.

> However, as logical beings we make the trade off because speed isn’t as important as safety.

umm, isn't it more like we make the trade off because we currently can't do better? who knows what amazing progress we will make?

we do really want both speed and safety. bringing the subject back home, golang on their homepage picked 3: simple, reliable & efficient.

the original article is right for talking about it at all. i, for example, had no clue. and now will keep all that in mind. the response is great for providing an explanation. and OP's comment here is right on spot.

If you're running an environment with a garbage collection and goroutines and whatnot, then you've "asked" to have those things, no?

That's it's not strictly needed in a contrived "Hello world" is rather meaningless IMHO, since very few real-world programs are like that.

It's a fixed cost. The percentage of the resulting program that is "bloat" appears to be crazy high when you're writing a trivial "hello world" program... but for an actual, real-world program the percentage of this fixed cost compared to the total size of the program will be negligible.

Reply on news.ycombinator.com