Hacker News Reader

Comment by yyyfb | Hacker News Reader

Boggles my mind that after more than 60 years of computer science, we still design tools (programming languages) where the simplest tasks are full of gotchas and footguns. This is a great example.

View on HN

> the simplest tasks

The tasks seem simple from 30,000 feet up in the air. Once you get down into the dirt you realize there's absolutely nothing simple about what you're proposing.

A filesystem is a giant shared data structure with several contractual requirements and zero guarantees. That people think a programming language could "solve" this is what is boggling to me.

It's hardly a footgun. Close may be able to report some additional errors with getting the data on persistent storage but it won't report all of them anyway. For most applications, ignoring the return of close is perfectly fine in practice.

Agreed. Just log it and move on. The code _probably_ wrote what it needed to even if it didn't close. If truly cared that you got everything out correctly, you'd need to do more work than a blind `defer Close()` anyway and you'd never have written the code like this.

the close() manpage says that it shouldn't be retried anyway, because one might end up closing a file that meanwhile had been opened with the same handle by a different thread.

The problem is that the filesystem primitives are garbage, so it is impossible to make something safe and reasonably performant. This is not a case of "speed at all costs" where huge footguns are added for marginal performance, this is avoiding 10x and up slowdowns that would be required to be safe due to the anemic primitives. If the filesystem had better primitives/APIs, like barriers and proper asynchronous completion, it would be trivial to design tools that are safe and performant. But, without them it is like trying to build a skyscraper out of mud and toothpicks.

To be honest, you sound like someone who has no experience with designing a filesystem and thinks he can do better because doesn't understand the problems at all.

I think this post overhypes the issue. So many writes we do just aren’t that important (e.g. logs, cli config, blah), Close fails rarely, and it’s pretty standard for casually developed application software to misbehave once the disk is full or breaking.

This is a classic safety / performance trade off that was properly selected in favor of performance.

The defer Close() is still quite useful as a way to avoid fd leaks.

Funny thing is that there is a near footgun with this go: if you defer and set a non named return in a defer, like cErr, that won’t actually set that variable. Not sure what actually happens in that case but godbolt would tell you. In that case, the error would get swallowed

Gotta keep the profession interesting somehow.

Windows doesn't have this gotcha, FWIW.

Reply on news.ycombinator.com