6 ms·

If "in practice" is OK, then Go looks pretty good again.

• ben0x539 4y ago
  "in practice", I forget to close things a lot more often in Go than in Rust.
  • Andys 4y ago
    In practice, many Go developers use a linter to generate warnings for things you forgot.
    • dodobirdlord 4y ago
      It’s nice when you don’t have to worry about what linter you should be using because everyone uses the same static analysis to check for this sort of thing and it lives in the compiler.
      • pjmlp 4y ago
        Yet, clippy does exist.
        • tialaramex 4y ago
          And, as we saw in several previous threads: I don't think Clippy lints are an adequate substitute for correctness checks in the Rust compiler itself, plenty of people with more actual impact on Rust agree with me about that. In practice Clippy lints do get "promoted" in this way, though not always as quickly as I'd like. However, Clippy has lots of style lints which I'm sure some people would be very annoyed to see in the compiler itself. Do you want a Clippy lint telling you that you should do X, and not Y, just because it's considered stylistically better and even though it has literally no impact on the compiled result? So it makes sense to me that Clippy exists as a linter the problem is the abuse of linters for "Actually programs in this language are dumpster fires unless you obey these lints" and so far Rust is avoiding that.
          • pjmlp 4y ago
            Then I suggest removing such tests out of clippy and integrate them into Rust, I am sure there are a couple that fail your goals. People can't even agree what unsafe is suposed to be used for, as certain groups misuse it for dependent types programing.
            • tialaramex 4y ago
              Sure, I'd like the _ = lock() lint to be an error for example, since you almost certainly didn't mean that, and if you did that's the least useful way to express it. But time is limited, perhaps I'll get to it at the weekend if nobody else has already done so.
    • oconnor663 4y ago
      It's been a while since I wrote Go, but my worry used to be that linters wouldn't be able to follow cases that were just slightly more complicated than average. Like if I open one file, yes, the linter will be able to tell if I don't close it. But if I put a bunch of files in a long-lived map, the linter isn't going to know that any function calling delete() on that map needs to be closing the files too. But in Rust or C++, this case is handled smoothly by destructors. (With maybe a little caveat about whether it would be better to catch any errors that might arise when closing the file.)