4 ms·

It’s true that it’s not a guarantee. But I feel like this is one of those cases where it could be an issue in theory, but pretty much never is in practice.

Andys 5y ago
If "in practice" is OK, then Go looks pretty good again.
- ben0x539 5y ago
  "in practice", I forget to close things a lot more often in Go than in Rust.
  - Andys 5y ago
    In practice, many Go developers use a linter to generate warnings for things you forgot.
    - dodobirdlord 5y 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 5y ago
        Yet, clippy does exist.
        tialaramex 5y 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 5y 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 5y 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 5y 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.)
woodruffw 5y ago
Certainly. Rust has a well-thought-out standard library, and sticking to it will (generally) guarantee that the connection between resource acquisition and memory safety is maintained. That being said: it can be a problem in practice, particularly in sandboxed or otherwise constrained environments. Leaking a file descriptor isn’t a problem when you have tens of thousands, but it can be one when you’ve constrained the process to just a dozen.
- tialaramex 5y ago
  I mean, it's called Box::leak(). It says what it does on the tin. Why was my file descriptor leaked? Oh, I specifically leaked it. As to third party libraries, well, it's a quality of implementation issue. The third party library might forget to flush caches, muddle up file formats, or just crash. This use of clear naming is one of the things I value in the Rust standard library. Both Rust and C++ provide both a stable sort, and also an unstable sort which may be faster if you know that's suitable. But Rust calls its unstable sort unstable_sort() and so if you don't even know what the difference is you're going to pick "sort" and get no surprises. In C++ "sort" is the unstable sort and if you didn't already know about sort stability then I guess you'll find out the hard way, sucks to be you.
  - woodruffw 5y ago
    You'll find absolutely no argument from me about these things -- when Rust can't guarantee a particular thing (and there are many, many things it reasonably can't and won't guarantee!), it does an excellent job of its APIs descriptive. The sole point was one of formal guarantees: this post is about bugs the compiler catches, and the first example is one that Rust will not catch. It won't catch it because, in many cases, it's not a bug at all!
amelius 5y ago
The difference between theory and practice is exactly where security exploits shine.
- xedrac 5y ago
  Sure, but just because Rust isn't perfect doesn't mean it isn't a huge improvement over the status quo.
- toolz 5y ago
  Are you suggesting if rust removed "safe in practice" features (only keeping theoretically safe features) it would lead to less exploitable software? If so I strongly disagree with you. Every language is rife with features that can be used in unsafe way but in practice increases security.
  - woodruffw 5y ago
    I read this more as a “let’s be precise about what’s actually guaranteed” and not an exhortation to avoid Rust. Rust is my favorite compiled language, and that’s why I’d like conversations about Rust to be grounded in formal guarantees and not in incidental properties.
deleted 5y ago
[deleted]
saghm 5y ago
I've definitely run into accidentally reference cycles with `Arc` in concurrent Rust code in production before (due to weak references essentially baton-passing the singular strong reference count to each other before getting dropped. This is a bit of a different kind of memory leak, and even having run into it I'd strongly prefer to write any concurrent code in Rust over any other language I've tried given the choice, but I'd be hesitant to say that Rust guarantees that nothing will leak if only to keep people from getting complacent.

Andys 5y ago

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

ben0x539 5y ago
"in practice", I forget to close things a lot more often in Go than in Rust.
- Andys 5y ago
  In practice, many Go developers use a linter to generate warnings for things you forgot.
  - dodobirdlord 5y 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 5y ago
      Yet, clippy does exist.
      - tialaramex 5y 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 5y 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 5y 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 5y 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.)

woodruffw 5y ago

Certainly. Rust has a well-thought-out standard library, and sticking to it will (generally) guarantee that the connection between resource acquisition and memory safety is maintained. That being said: it can be a problem in practice, particularly in sandboxed or otherwise constrained environments. Leaking a file descriptor isn’t a problem when you have tens of thousands, but it can be one when you’ve constrained the process to just a dozen.

tialaramex 5y ago
I mean, it's called Box::leak(). It says what it does on the tin. Why was my file descriptor leaked? Oh, I specifically leaked it. As to third party libraries, well, it's a quality of implementation issue. The third party library might forget to flush caches, muddle up file formats, or just crash. This use of clear naming is one of the things I value in the Rust standard library. Both Rust and C++ provide both a stable sort, and also an unstable sort which may be faster if you know that's suitable. But Rust calls its unstable sort unstable_sort() and so if you don't even know what the difference is you're going to pick "sort" and get no surprises. In C++ "sort" is the unstable sort and if you didn't already know about sort stability then I guess you'll find out the hard way, sucks to be you.
- woodruffw 5y ago
  You'll find absolutely no argument from me about these things -- when Rust can't guarantee a particular thing (and there are many, many things it reasonably can't and won't guarantee!), it does an excellent job of its APIs descriptive. The sole point was one of formal guarantees: this post is about bugs the compiler catches, and the first example is one that Rust will not catch. It won't catch it because, in many cases, it's not a bug at all!

amelius 5y ago

The difference between theory and practice is exactly where security exploits shine.

xedrac 5y ago
Sure, but just because Rust isn't perfect doesn't mean it isn't a huge improvement over the status quo.
toolz 5y ago
Are you suggesting if rust removed "safe in practice" features (only keeping theoretically safe features) it would lead to less exploitable software? If so I strongly disagree with you. Every language is rife with features that can be used in unsafe way but in practice increases security.
- woodruffw 5y ago
  I read this more as a “let’s be precise about what’s actually guaranteed” and not an exhortation to avoid Rust. Rust is my favorite compiled language, and that’s why I’d like conversations about Rust to be grounded in formal guarantees and not in incidental properties.

deleted 5y ago

[deleted]

saghm 5y ago

I've definitely run into accidentally reference cycles with `Arc` in concurrent Rust code in production before (due to weak references essentially baton-passing the singular strong reference count to each other before getting dropped. This is a bit of a different kind of memory leak, and even having run into it I'd strongly prefer to write any concurrent code in Rust over any other language I've tried given the choice, but I'd be hesitant to say that Rust guarantees that nothing will leak if only to keep people from getting complacent.