4 ms·
> Another thing is difference in handling invalid code. A traditional compiler front-end is usually organized as a progression of phases, where each phase takes
by _bxg1 7y ago
> Another thing is difference in handling invalid code. A traditional compiler front-end is usually organized as a progression of phases, where each phase takes an unstructured input, checks the input for validity, and, if it is indeed valid, adds more structure on top. Specifically, an error in an early phase (like parsing) usually means that the latter phase (like type checking) is not run for this bit of code at all. In other words, "correct code" is a happy case, and everything else can be treated as an error condition. In contrast, in IDE code is always broken, because the user constantly modifies it. As soon as the code is valid, the job of IDE ends and the job of the batch compiler begins. So, an IDE-oriented compiler should accommodate an incomplete and broken code, and provide IDE features, like completion, for such code.
This has been one of the most frustrating things about Rust's development experience. 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. It makes it really hard to develop something piece by piece.
I'm glad they're aware of these problems and are making a concerted effort to address them.
- epage 7y agoHadn't thought of that potential benefit to the rust-analyzer work: I could get borrow errors upfront even if there are irrelevant errors in other areas of code. (borrow checker seems like it is one of the last phases).
- woah 7y agoThat’s how you know you’re reaching the light at the end of the tunnel, when the borrow checker errors start showing up
- empath75 7y agoThat’s usually when I give up and start writing go, tbh.
- echelon 7y agoDo you have to dump on Rust because of its learning curve? It isn't even that bad. It's not like Golang doesn't have warts of its own. I have a hard time believing you make this choice often or "usually". This seems like flat out prejudice.
- galangalalgol 7y agoIf go was fast enough why didn't you start out using it, or some other language that is 3x slower than rust but has gc and comfy ergonomics. C#, clojure, julia, ocaml( if you dont need threads). Or just plane Java.
- _bxg1 7y agoI've started associating a shower of warnings with "success", because those only appear once all the errors have been taken care of
- nirui 7y agoOr, in my case, it tells me why I have to restructure my code :( I mean, an early warning, before I actually made those mistakes would help a lot, if it can be done that is :)
- Buttons840 7y ago> 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 agoAn 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 agoThis 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 agoI 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.
- earenndil 7y ago> Another thing is difference in handling invalid code. A traditional compiler front-end is usually organized as a progression of phases, where each phase takes an unstructured input, checks the input for validity, and, if it is indeed valid, adds more structure on top. Is this true? The way the d compiler does it is to make a special ast node type called 'error', which allows it to avoid this problem. I have also gotten error messages from c compilers that indicated they were doing something similar. Now, in the d compiler, this is not a panacea, because erroneous code can cause erroneous error messages about unreachable code, but it generally works quite well.
- estebank 7y agorustc does the same. I believe the op complaint is that rustc does not perform type and lifetime checks on blocks of code that haven't been successfully parsed.