5 ms·

Programming in Rust is really not like being in an abusive relationship. The compiler is trying to help out as much as possible, especially since rustc has the

Programming in Rust is really not like being in an abusive relationship. The compiler is trying to help out as much as possible, especially since rustc has the best error messages in the world.

fawadasaurus 3y ago
[flagged]
- sunshowers 3y ago
  This really is an inappropriate comparison. Can we be serious for a bit? A professional-grade tool providing professional-grade feedback is not remotely like an abusive or even turbulent relationship.
  - civilitty 3y ago
    Besides, it's mostly the programmers doing the abusing. People do sick things with lifetimes and generic associated types. Sick, sick things.
- estebank 3y ago
  As one of the main people working on Rust compiler diagnostics, I find this comparison beyond distasteful. The tooling is not capricious in its restrictions and we go out of our way to make it communicate to people with as much empathy and support as possible.
  - latency-guy2 3y ago
    There's a clear distinction between someone who writes the code and everyone else in the world who works with the outputs of your code. Doesn't feel that way to me.
    - maxbond 3y ago
      I'm sorry you're having a bad experience. I've found changing a couple habits developed in other languages helped me to have a good experience with Rust's diagnostics. 1. Reading the error messages. I was used to error messages verbosely printing a lot of details which were mostly irrelevant and letting the programmer sort it out, and I developed a habit of skimming them. I had a better time with Rust when I realized it was giving me information that was mostly relevant, and that I should actually read them. 2. Interpreting error messages as feedback rather than failure. I was used to error messages meaning I had done something wrong, and getting them all the time was frustrating. Watching Jon Gjengset's coding videos, I was struck that he wrote code to trigger errors deliberately in order to get feedback from the compiler. I now try to work through Rust error messages the same way I would failing unit tests; I make some small changes, I knock out the errors, and then move on to the next subtask. This keeps the number of errors small and manageable, and gets me into a tight feedback loop with the compiler. Relatedly, I encountered the idea (in a blog post I no longer remember) that the Rust compiler is more like an automated pair programming partner than other compilers. This change in mindset really helped for me; thinking of it as a friendly helper rather than a loud complainer made the work lighter. (That's why I personally don't like the 'abusive partner' metaphor, for me that mindset makes it toilsome and miserable. Also because I've had an abusive partner, and it's nothing like that, and I could do without the reminder.) 3. Setting up my IDE to show me inline type annotations and error messages. This made the feedback loop tighter, I only have to drop into a terminal for complex or unfamiliar error messages. With practice I can fix most errors using a one-line summary. 4. With practice, I've internalized Rust's semantics, and I've stopped painting myself into corners with unnecessarily cyclic data structures and such. I also read a blog article or maybe a tweet (which I've also forgotten) about giving yourself permission to use Box or clone and not sweating every copy or allocation. It pointed out that if you were writing Python, everything would be an Arc<T>, and you'd think nothing of it; in Rust the performance cost is explicit, so you agonize over it, but a lot of the time it's not a big deal to copy some data or to perform an allocation.
      - latency-guy2 3y ago
        No thanks, that seems a long winded way of saying you're not welcome here unless you think exactly like me.
- johnnyanmac 3y ago
  More like "this submission has errors check your work". That's the job of any compiler, Rust was made to be especially strict. If you want sugarcoating or simply rapid prototyping I'd use a dynamic or scripting language instead.
emporas 3y ago
The OSes want programmers to handle resources correctly, and the Rust compiler makes that task a breeze. We are in a more abusive relationship with our OSes, than the Rust compiler. How about the hardware? Doesn't that need to run assembly in a correct way? That counts as an abusive relationship as well. Rust's error messages are one of a kind. There no other compiler which comes even close. As a side note, i used latex lately, it's error messages are horrendous. What a nightmare to figure out what's wrong by inspecting the error.
- Aerbil313 3y ago
  Rustc is so good I learnt a lot about the language by just reading errors.
CGamesPlay 3y ago
> The compiler is trying to help out as much as possible, especially since rustc has the best error messages in the world. Generally good, but man do I hate how any error in my async function causes every recursive call site to generate an error about how the Future is no longer Send and Sync. Literally an entire console scrollback of errors with the actual syntax error buried somewhere in the middle.
- estebank 3y ago
  I believe this is in our radar and waiting on the new trait solver, but just in case if you have a repro I would appreciate a ticket to improve the diagnostic.
  - CGamesPlay 3y ago
    https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4c0c32f255e65594369556fb3589d3ae https://play.rust-lang.org/?version=stable&mode=debug&editio... In this case, the first two errors are clear. The next 3 provide multiple, redundant context blocks. The upshot is that this simple example results in rustc printing 11 lines of useful error messages and 86 lines of useless messages. Add to that the fact that the useful error messages need not be at the top or bottom of the error list, they can be anywhere inside of it, depending on the declaration order.
    - estebank 3y ago
      That is a different problem than the one I thought you were seeing. We do spend a lot of time trying to silence errors that are irrelevant. We also get a lot of complaints when fixing a single error produces a wave of new errors that were hidden due to failures in earlier stages. It's a balancing act. Also, specific errors are verbose in order to give people a fighting chance to fix their issue. An error that is too verbose is annoying. An error that is too terse will leave users in the cold as to what the problem was. It's yet another balancing act. I filed https://github.com/rust-lang/rust/issues/117233 https://github.com/rust-lang/rust/issues/117233 for you. Could I ask you why you didn't consider doing so when you first encountered this problem? Edit: good news, from the next stable onwards the issue you saw no longer reproduces. You only get the parse errors with your case. https://play.rust-lang.org/?version=beta&mode=debug&edition=2018&gist=4c0c32f255e65594369556fb3589d3ae https://play.rust-lang.org/?version=beta&mode=debug&edition=...
Tade0 3y ago
Rust's compiler is the first one I've seen to use the word perhaps. My main gripe is that I still don't fully comprehend lifetimes and the compiler can't really help me every time, because it (understandably) errs on the side of caution.
- estebank 3y ago
  Whenever you see weasel words like that, it means the compiler knows that the issue you encountered could be what it is saying but the necessary metadata to figure out for sure is inaccessible to it. It's the problem with classical stage-oriented compilers. A compiler designed for diagnostics from the beginning would end up looking like a plate of spaghetti where you can call type checking from the parser, to give an example.
  - awused 3y ago
    >It's the problem with classical stage-oriented compilers. A compiler designed for diagnostics from the beginning I'm not sure any compiler, even one "designed for diagnostics," can gather the "necessary metadata" from inside my brain based on my original intentions. If the compiler could unambiguously interpret what I meant to write, it wouldn't have needed to fail with a compilation error in the first place. Whenever I see something like "perhaps" or "maybe" in a compilation error, the information just didn't exist anywhere the compiler could possibly get to, and it's just a suggestion based on common mistakes.

Programming in Rust is really not like being in an abusive relationship. The compiler is trying to help out as much as possible, especially since rustc has the best error messages in the world.

fawadasaurus 3y ago

[flagged]

sunshowers 3y ago
This really is an inappropriate comparison. Can we be serious for a bit? A professional-grade tool providing professional-grade feedback is not remotely like an abusive or even turbulent relationship.
- civilitty 3y ago
  Besides, it's mostly the programmers doing the abusing. People do sick things with lifetimes and generic associated types. Sick, sick things.
estebank 3y ago
As one of the main people working on Rust compiler diagnostics, I find this comparison beyond distasteful. The tooling is not capricious in its restrictions and we go out of our way to make it communicate to people with as much empathy and support as possible.
- latency-guy2 3y ago
  There's a clear distinction between someone who writes the code and everyone else in the world who works with the outputs of your code. Doesn't feel that way to me.
  - maxbond 3y ago
    I'm sorry you're having a bad experience. I've found changing a couple habits developed in other languages helped me to have a good experience with Rust's diagnostics. 1. Reading the error messages. I was used to error messages verbosely printing a lot of details which were mostly irrelevant and letting the programmer sort it out, and I developed a habit of skimming them. I had a better time with Rust when I realized it was giving me information that was mostly relevant, and that I should actually read them. 2. Interpreting error messages as feedback rather than failure. I was used to error messages meaning I had done something wrong, and getting them all the time was frustrating. Watching Jon Gjengset's coding videos, I was struck that he wrote code to trigger errors deliberately in order to get feedback from the compiler. I now try to work through Rust error messages the same way I would failing unit tests; I make some small changes, I knock out the errors, and then move on to the next subtask. This keeps the number of errors small and manageable, and gets me into a tight feedback loop with the compiler. Relatedly, I encountered the idea (in a blog post I no longer remember) that the Rust compiler is more like an automated pair programming partner than other compilers. This change in mindset really helped for me; thinking of it as a friendly helper rather than a loud complainer made the work lighter. (That's why I personally don't like the 'abusive partner' metaphor, for me that mindset makes it toilsome and miserable. Also because I've had an abusive partner, and it's nothing like that, and I could do without the reminder.) 3. Setting up my IDE to show me inline type annotations and error messages. This made the feedback loop tighter, I only have to drop into a terminal for complex or unfamiliar error messages. With practice I can fix most errors using a one-line summary. 4. With practice, I've internalized Rust's semantics, and I've stopped painting myself into corners with unnecessarily cyclic data structures and such. I also read a blog article or maybe a tweet (which I've also forgotten) about giving yourself permission to use Box or clone and not sweating every copy or allocation. It pointed out that if you were writing Python, everything would be an Arc<T>, and you'd think nothing of it; in Rust the performance cost is explicit, so you agonize over it, but a lot of the time it's not a big deal to copy some data or to perform an allocation.
    - latency-guy2 3y ago
      No thanks, that seems a long winded way of saying you're not welcome here unless you think exactly like me.
johnnyanmac 3y ago
More like "this submission has errors check your work". That's the job of any compiler, Rust was made to be especially strict. If you want sugarcoating or simply rapid prototyping I'd use a dynamic or scripting language instead.

emporas 3y ago

The OSes want programmers to handle resources correctly, and the Rust compiler makes that task a breeze. We are in a more abusive relationship with our OSes, than the Rust compiler. How about the hardware? Doesn't that need to run assembly in a correct way? That counts as an abusive relationship as well. Rust's error messages are one of a kind. There no other compiler which comes even close. As a side note, i used latex lately, it's error messages are horrendous. What a nightmare to figure out what's wrong by inspecting the error.

Aerbil313 3y ago
Rustc is so good I learnt a lot about the language by just reading errors.

CGamesPlay 3y ago

> The compiler is trying to help out as much as possible, especially since rustc has the best error messages in the world. Generally good, but man do I hate how any error in my async function causes every recursive call site to generate an error about how the Future is no longer Send and Sync. Literally an entire console scrollback of errors with the actual syntax error buried somewhere in the middle.

estebank 3y ago
I believe this is in our radar and waiting on the new trait solver, but just in case if you have a repro I would appreciate a ticket to improve the diagnostic.
- CGamesPlay 3y ago
  https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4c0c32f255e65594369556fb3589d3ae https://play.rust-lang.org/?version=stable&mode=debug&editio... In this case, the first two errors are clear. The next 3 provide multiple, redundant context blocks. The upshot is that this simple example results in rustc printing 11 lines of useful error messages and 86 lines of useless messages. Add to that the fact that the useful error messages need not be at the top or bottom of the error list, they can be anywhere inside of it, depending on the declaration order.
  - estebank 3y ago
    That is a different problem than the one I thought you were seeing. We do spend a lot of time trying to silence errors that are irrelevant. We also get a lot of complaints when fixing a single error produces a wave of new errors that were hidden due to failures in earlier stages. It's a balancing act. Also, specific errors are verbose in order to give people a fighting chance to fix their issue. An error that is too verbose is annoying. An error that is too terse will leave users in the cold as to what the problem was. It's yet another balancing act. I filed https://github.com/rust-lang/rust/issues/117233 https://github.com/rust-lang/rust/issues/117233 for you. Could I ask you why you didn't consider doing so when you first encountered this problem? Edit: good news, from the next stable onwards the issue you saw no longer reproduces. You only get the parse errors with your case. https://play.rust-lang.org/?version=beta&mode=debug&edition=2018&gist=4c0c32f255e65594369556fb3589d3ae https://play.rust-lang.org/?version=beta&mode=debug&edition=...

Tade0 3y ago

Rust's compiler is the first one I've seen to use the word perhaps. My main gripe is that I still don't fully comprehend lifetimes and the compiler can't really help me every time, because it (understandably) errs on the side of caution.

estebank 3y ago
Whenever you see weasel words like that, it means the compiler knows that the issue you encountered could be what it is saying but the necessary metadata to figure out for sure is inaccessible to it. It's the problem with classical stage-oriented compilers. A compiler designed for diagnostics from the beginning would end up looking like a plate of spaghetti where you can call type checking from the parser, to give an example.
- awused 3y ago
  >It's the problem with classical stage-oriented compilers. A compiler designed for diagnostics from the beginning I'm not sure any compiler, even one "designed for diagnostics," can gather the "necessary metadata" from inside my brain based on my original intentions. If the compiler could unambiguously interpret what I meant to write, it wouldn't have needed to fail with a compilation error in the first place. Whenever I see something like "perhaps" or "maybe" in a compilation error, the information just didn't exist anywhere the compiler could possibly get to, and it's just a suggestion based on common mistakes.