4 ms·

Agreed - not sure this is a good thing, making code and actions harder to reason about. Another reason to reconsider Rust...

dbaupp 10y ago
I don't think non-lexical lifetimes will make code harder to reason about (beyond the fact that it means there are more valid Rust programs, of course), because it doesn't change behaviour: a program that currently compiles won't have different runtime results with non-lexical lifetimes. I suppose it will mean a programmer might have to think a little harder if they want to manually preempt compilation errors, but fortunately the compiler is there to catch them if they don't get it right. The example the OP points out is a situation that will likely play out like the following in most circumstances: - programmer adds new use of variable b. - compiler points out an existing use of some other value a that could invalidate b, and, importantly, highlights all the moving parts (conflicting use of a, use of b that prolongs its lifetime, etc.) in the error message. - programmer edits code to avoid the problem.
jerf 10y ago
You do this exact thing all the time in non-Rust languages. Rust notices, and then tells you about it. I don't think that makes code harder to reason about... I think that leans more in the "easier" direction. I don't think you should dock Rust for pointing out bad practices that other languages simply don't notice. I think you can dock it for complaining about code that's really OK, which just happens to be exactly what they're trying to fix here.
- geofft 10y ago
  So, I don't endorse this reasoning, but I can see it. With Rust you have to think about the possible failure cases of your code up-front and account for them. In other languages, you don't have to. For instance, I'd bet that most C or C++ apps in production that use concurrency have some concurrency bug somewhere, that's so rare that nobody has hit it yet (or the effect of the bug is minor). Those apps are running in production and serving a valuable purpose. Rust would force you to solve the edge case before deploying the app in production. Occasionally, it's the right set of engineering tradeoffs to deploy something that produces useful results 99.9% of the time and crashes .1% of the time. (But, I guess you can say, you can always use Rust's 'unsafe' keyword to acknowledge that something isn't quite right but you're deploying it anyway.)
  - steveklabnik 10y ago
    A sort of related issue: while Rust may make you solve it up front, it also helps you _a lot_ with finding the issue in the first place and pointing out what's wrong. Concurrency bugs in other languages often remain because it's hard to actually identify the problem in the first place, and so it's not worth the time to go through that massive effort for a bug that happens rarely.
  - kbenson 10y ago
    > Occasionally, it's the right set of engineering tradeoffs to deploy something that produces useful results 99.9% of the time and crashes .1% of the time. Yes, but unfortunately that doesn't describe the situation we are usually presented with. The developers most likely have not calculated that it runs fine 99.9% of the time and has specific failure cases that account for 0.1% of the time, they just don't know about the error. That is vastly different than making an engineering tradeoff, since the people engineering it don't even know there's a tradeoff being made, and thus can't make an informed decision about it. In some sense, rust actually enables the situation you are presenting, in that it requires more explicit reasoning about behavior, and if you want to wrap a chunk in unsafe after calculating that it should only negatively affect the program operation 0.1% of the time, well then you actually are making a tradeoff.

dbaupp 10y ago

I don't think non-lexical lifetimes will make code harder to reason about (beyond the fact that it means there are more valid Rust programs, of course), because it doesn't change behaviour: a program that currently compiles won't have different runtime results with non-lexical lifetimes. I suppose it will mean a programmer might have to think a little harder if they want to manually preempt compilation errors, but fortunately the compiler is there to catch them if they don't get it right. The example the OP points out is a situation that will likely play out like the following in most circumstances: - programmer adds new use of variable b. - compiler points out an existing use of some other value a that could invalidate b, and, importantly, highlights all the moving parts (conflicting use of a, use of b that prolongs its lifetime, etc.) in the error message. - programmer edits code to avoid the problem.

jerf 10y ago

You do this exact thing all the time in non-Rust languages. Rust notices, and then tells you about it. I don't think that makes code harder to reason about... I think that leans more in the "easier" direction. I don't think you should dock Rust for pointing out bad practices that other languages simply don't notice. I think you can dock it for complaining about code that's really OK, which just happens to be exactly what they're trying to fix here.

geofft 10y ago
So, I don't endorse this reasoning, but I can see it. With Rust you have to think about the possible failure cases of your code up-front and account for them. In other languages, you don't have to. For instance, I'd bet that most C or C++ apps in production that use concurrency have some concurrency bug somewhere, that's so rare that nobody has hit it yet (or the effect of the bug is minor). Those apps are running in production and serving a valuable purpose. Rust would force you to solve the edge case before deploying the app in production. Occasionally, it's the right set of engineering tradeoffs to deploy something that produces useful results 99.9% of the time and crashes .1% of the time. (But, I guess you can say, you can always use Rust's 'unsafe' keyword to acknowledge that something isn't quite right but you're deploying it anyway.)
- steveklabnik 10y ago
  A sort of related issue: while Rust may make you solve it up front, it also helps you _a lot_ with finding the issue in the first place and pointing out what's wrong. Concurrency bugs in other languages often remain because it's hard to actually identify the problem in the first place, and so it's not worth the time to go through that massive effort for a bug that happens rarely.
- kbenson 10y ago
  > Occasionally, it's the right set of engineering tradeoffs to deploy something that produces useful results 99.9% of the time and crashes .1% of the time. Yes, but unfortunately that doesn't describe the situation we are usually presented with. The developers most likely have not calculated that it runs fine 99.9% of the time and has specific failure cases that account for 0.1% of the time, they just don't know about the error. That is vastly different than making an engineering tradeoff, since the people engineering it don't even know there's a tradeoff being made, and thus can't make an informed decision about it. In some sense, rust actually enables the situation you are presenting, in that it requires more explicit reasoning about behavior, and if you want to wrap a chunk in unsafe after calculating that it should only negatively affect the program operation 0.1% of the time, well then you actually are making a tradeoff.