3 ms·

> A piece of code looks error-free, then you fix an error somewhere else, reach the next compiler phase, and an error pops up where you just were. Isn't this t

> A piece of code looks error-free, then you fix an error somewhere else, reach the next compiler phase, and an error pops up where you just were. Isn't this the case with all compilers? The most basic example being (for example) I have a syntax error on line 10, and that's the only reported problem, but then I fix the syntax error and now I have an error on line 200. I agree it is a problem, the world would be better if all languages could avoid it, but I don't expect it ever to go away. Do you believe this problem is better or worse in Rust compared to other languages?

edflsafoiewq 7y ago
> Do you believe this problem is better or worse in Rust compared to other languages? Unlike other languages, Rust still has borrow checking to go after all the type errors are gone.
- pjmlp 7y ago
  An idea currently being added to Swift, C++ (via static analysis, core guidelines lifetime profile), Ada/SPARK, D, OCaml and Haskell, originally developed in Cyclone, further explored in ATS. So that "Unlike other languages" isn't quite true. What Rust has done, was to prove it is viable to push such ideas into mainstream computing.
  - pcwalton 7y ago
    This is incorrect. Neither Cyclone nor ATS had borrow checking. In fact the ATS author at one point dismissed borrow checking as too inflexible. The borrow checker is actually original, though based on known techniques. Specifically, the original part is that it allows the per-use-site choice of aliasing vs. mutability instead of making the decision globally.
    - pjmlp 7y ago
      I might be wrong on the origins, but I am certainly right that everyone else is now adopting similar algorithms. So while it is great that Rust is making these concepts mainstream, in about 5 years time, the other languages will have their New Jersey style implementations mature and available for their communities.
      - pcwalton 7y ago
        Borrow checking cannot be soundly added to C++, or most other languages, for systematic reasons. Soundness isn't a theoretical property here: C++ has constantly been adding things that make it safer as opposed to making it safe, and memory safety problems are still a huge issue. See "Safe C++ Subset is Vaporware" by Robert O'Callahan: https://robert.ocallahan.org/2016/06/safe-c-subset-is-vapourware.html https://robert.ocallahan.org/2016/06/safe-c-subset-is-vapour...
        pjmlp 7y ago
        Why do you think I mentioned New Jersey style implementation? Google and Microsoft are the ones driving that effort, in what concerns C++. That vapourware is quite welcomed when using DriverKit, Unreal, COM/UWP, Project Treble drivers,..
_bxg1 7y ago
In other languages I'm familiar with as long as the syntax can actually be parsed, errors are mostly localized. Of course if you change the type of something that can cause errors elsewhere. But this is different. The new errors have nothing at all to do with the one that was fixed except that they come from an earlier stage of the compilation process.
the8472 7y ago
Eclipse's ECJ will keep compiling a class even when a specific method is invalid. And even inside a method it'll try to massage the AST into a somewhat valid state while you're typing so it can keep analyzing the code and show errors/make suggestions. A missing bracket on line 15 won't prevent it from soldiering on to spot a misspelled method call in line 40 even though the nesting is totally messed up and if taken at face value line 40 would be syntactically invalid since it's outside the class body.
- _bxg1 7y ago
  I could even understand not trying to handle the brackets scenario. In RLS, a type error on a local variable can hide a borrow-checker problem in a completely different file.
- usrusr 7y ago
  And it doesn't just march on to identify errors elsewhere, it can often continue all the way to runnable bytecode. The invalid parts will just be replaced by exceptions that parrot the compiler error. Meanwhile other code paths can already be exercised which can be very handy at times.
  - gmueckl 7y ago
    On the flipside, I have managed to actually run non-compiling Java classes because of that a couple of times, only to stare at the debugger with wide eyes when I realized what was going on.
Matthias247 7y ago
It’s more pronounced than in other languages. You could have an entire file with zero errors. No red squiggles, nothing. Then after you fix your errors in different files suddenly errors show up (eg for borrow checking, thread safety analysis, etc).
- dx87 7y ago
  That always gets me. I'll be writing some code and think I finally got really proficient with Rust because I'm not getting any errors or warnings, then I try to compile and find out an error in another file was preventing the compiler from showing me everything wrong in my current file.
- mxcrossb 7y ago
  Yes I think what rust fans should argue is not that it’s just like compile time errors in other languages, but more like run time errors.
onei 7y ago
It depends on the compiler. A naïve parser might reach a syntax error and error out. A more advanced parser will look for a synchronidation point that it can move to and carry on. If the compiler is in a statement, that might be a semicolon, for a function it could be a closing brace. From there it can reset to some degree and carry on parsing the file.

edflsafoiewq 7y ago

> Do you believe this problem is better or worse in Rust compared to other languages? Unlike other languages, Rust still has borrow checking to go after all the type errors are gone.

pjmlp 7y ago
An idea currently being added to Swift, C++ (via static analysis, core guidelines lifetime profile), Ada/SPARK, D, OCaml and Haskell, originally developed in Cyclone, further explored in ATS. So that "Unlike other languages" isn't quite true. What Rust has done, was to prove it is viable to push such ideas into mainstream computing.
- pcwalton 7y ago
  This is incorrect. Neither Cyclone nor ATS had borrow checking. In fact the ATS author at one point dismissed borrow checking as too inflexible. The borrow checker is actually original, though based on known techniques. Specifically, the original part is that it allows the per-use-site choice of aliasing vs. mutability instead of making the decision globally.
  - pjmlp 7y ago
    I might be wrong on the origins, but I am certainly right that everyone else is now adopting similar algorithms. So while it is great that Rust is making these concepts mainstream, in about 5 years time, the other languages will have their New Jersey style implementations mature and available for their communities.
    - pcwalton 7y ago
      Borrow checking cannot be soundly added to C++, or most other languages, for systematic reasons. Soundness isn't a theoretical property here: C++ has constantly been adding things that make it safer as opposed to making it safe, and memory safety problems are still a huge issue. See "Safe C++ Subset is Vaporware" by Robert O'Callahan: https://robert.ocallahan.org/2016/06/safe-c-subset-is-vapourware.html https://robert.ocallahan.org/2016/06/safe-c-subset-is-vapour...
      - pjmlp 7y ago
        Why do you think I mentioned New Jersey style implementation? Google and Microsoft are the ones driving that effort, in what concerns C++. That vapourware is quite welcomed when using DriverKit, Unreal, COM/UWP, Project Treble drivers,..

_bxg1 7y ago

In other languages I'm familiar with as long as the syntax can actually be parsed, errors are mostly localized. Of course if you change the type of something that can cause errors elsewhere. But this is different. The new errors have nothing at all to do with the one that was fixed except that they come from an earlier stage of the compilation process.

the8472 7y ago

Eclipse's ECJ will keep compiling a class even when a specific method is invalid. And even inside a method it'll try to massage the AST into a somewhat valid state while you're typing so it can keep analyzing the code and show errors/make suggestions. A missing bracket on line 15 won't prevent it from soldiering on to spot a misspelled method call in line 40 even though the nesting is totally messed up and if taken at face value line 40 would be syntactically invalid since it's outside the class body.

_bxg1 7y ago
I could even understand not trying to handle the brackets scenario. In RLS, a type error on a local variable can hide a borrow-checker problem in a completely different file.
usrusr 7y ago
And it doesn't just march on to identify errors elsewhere, it can often continue all the way to runnable bytecode. The invalid parts will just be replaced by exceptions that parrot the compiler error. Meanwhile other code paths can already be exercised which can be very handy at times.
- gmueckl 7y ago
  On the flipside, I have managed to actually run non-compiling Java classes because of that a couple of times, only to stare at the debugger with wide eyes when I realized what was going on.

Matthias247 7y ago

It’s more pronounced than in other languages. You could have an entire file with zero errors. No red squiggles, nothing. Then after you fix your errors in different files suddenly errors show up (eg for borrow checking, thread safety analysis, etc).

dx87 7y ago
That always gets me. I'll be writing some code and think I finally got really proficient with Rust because I'm not getting any errors or warnings, then I try to compile and find out an error in another file was preventing the compiler from showing me everything wrong in my current file.
mxcrossb 7y ago
Yes I think what rust fans should argue is not that it’s just like compile time errors in other languages, but more like run time errors.

onei 7y ago

It depends on the compiler. A naïve parser might reach a syntax error and error out. A more advanced parser will look for a synchronidation point that it can move to and carry on. If the compiler is in a statement, that might be a semicolon, for a function it could be a closing brace. From there it can reset to some degree and carry on parsing the file.