4 ms·

I know Rust (esp on HN) is very hyped for its memory safety and nice abstractions, but I really wonder how much Rust owes its popularity to its error messages.

I know Rust (esp on HN) is very hyped for its memory safety and nice abstractions, but I really wonder how much Rust owes its popularity to its error messages. I would say the #1 reason I stop learning a technology is because of frustrating or unclear errors. EDIT: Getting a bit of topic, but I meant more because I love C and would love it more with rust level error messages.

dist1ll 3y ago
That's what makes me wary of modifying my NixOS config. A single typo and you get an error dump comparable to C++03 templates.
- Quekid5 3y ago
  ... but you do get an error. That's a lot better what you typically get with C or C++. Assuming it's valid systax, of course. This is a veering off topic, but I do agree that Nix-the-language has a lot of issues. (You might suggest Guix, but I don't want to faff about with non-supported repositories for table stakes like firmware and such. Maybe Nickel will eventually provide a more pleasant and principled way to define Nix configurations?)
  - nh2 3y ago
    My favourite Nix error message is infinite recursion encountered, at undefined position
    - Quekid5 3y ago
      Haha, reminds me of some Scheme interpreter that would just say something like 'missing paren' at position 0 or EOF depending on where the imbalance was :) ... but, yeah... I'm pretty sure there could be some hints as to whereabouts that infinite recursion was detected.
    - vintermann 3y ago
      I tried some kind of BBC micro at a computer museum, and found out that if you had an error anywhere in your BASIC program, it would just print "error". No line number, no hint at what the problem was.
      - danudey 3y ago
        I could understand some kind of ancient system not having the detail or knowledge to explain what happened in particular, but this is something that still happens in a lot of Microsoft software in particular. Outlook has a consistent tendency to give you errors like "Couldn't get your mail for some reason", or Windows saying "Hey networking isn't working". No "connection timed out" or "couldn't get an IP address" or "DNS lookup failed" or any other error message that is possible to diagnose. Even the Windows network troubleshooting wizard (the "let us try to diagnose why things aren't working for you" process) would consistently give me "yeah man idk" results, when the error is that I'm not getting an address from DHCP and should be extremely easy to diagnose. I get that in a lot of cases, problems cut across lots of errors or areas of responsibility, and getting some other team making some other library to expose their internals to your application might be difficult in an environment like Microsoft, but it's just inexplicable that so much software, even these days, resorts to "nope can't do it" and bail out.
- pxc 3y ago
  That's definitely the most painful part of iterating on Nix code for me, even in simple configs. You eventually develop an intuition for common problems and rely more on that than on deciphering the stack traces, but that's really not ideal.
- lynx23 3y ago
  Actually, thats a reason why I never even touched Nix. Besides, being functional and all the hype, but the syntax and naming of the language feels ad-hoc enough for me to never have caught on...
- crest 3y ago
  It's what got me pissed of enough with xmonad to discard it.
hardwaregeek 3y ago
Yeah Rust is popular because it's a practical language with a nice type system, decent escape hatches, and good tooling. The borrow checker attracts some, but it could have easily been done in a way with terrible usability.
- darby_eight 3y ago
  > The borrow checker attracts some, but it could have easily been done in a way with terrible usability. Why would anyone use the resulting language over C? What you're describing is C with a slightly friendlier compiler.
  - Ar-Curunir 3y ago
    I have never heard C as being described to have a good type system.
    - darby_eight 3y ago
      You could try to argue this is the only source of rust's popularity.... or you could admit that the borrow checker is in fact a reason why folks use Rust over C.
    - jjgreen 3y ago
      To this day, many C programmers believe that strong typing just means pounding extra hard on the keyboard. Peter van der Linden, "Expert C Programming"
    - tialaramex 3y ago
      "Strongly typed, weakly checked". Which is a funny way to say "Not strongly typed" or perhaps more generously "The compilers aren't very good and neither are the programmers but other than that..." (and yes I write that as a long time C programmer) But hey, C does have types: First it has several different integers with silly names like "long" and "short". Then it has the integers again but wearing a Groucho mask and with twice as many zeroes, "float" and "double". Then an integer that's probably one byte, unless it isn't, in which case it is anyway, and which doesn't know whether it's signed or not, "char". Then a very small integer that takes up too much space ("_Bool" aka bool) Finally though, it does have types which definitely aren't integers, unfortunately they participates in integer arithmetic anyway and many C programmers believe they're integers, but the compiler doesn't so that's... well it's a disaster, I speak of course of the pointers.
Quekid5 3y ago
The hard problem with C is that it's hard to tell if what the programmer wrote is an error. Hence warnings... which can be very hit or miss, or absurd overkill in some cases. (Signed overflow being a prime example where you really either just need to define what happens or accept that your compiler is basically never going to warn you about a possible signed overflow -- which is UB. The compromise here by Rust is to allow one to pick between some implementation defined behaviors. That seems pretty sensible.)
- uecker 3y ago
  For signed overflow I use -fsanitize=signed-integer-overflow .
  - Quekid5 3y ago
    Good. I wonder how many people do and also if their compilers support it. (One would hope so, of course. I assume clang and GCC do.) ... but the question is really what you ship to production. Btw, possible signed overflow was just an example of things people do not want warnings for. OOB is far more dangerous, obviously... and the cost for sanitizer in that case is HUGE... and it doesn't actually catch all cases AFAIUI.
    - uecker 3y ago
      For production one could use -fsanitize-undefined-trap-on-error that turns it into traps. I would not describe the cost of -fsanitize-undefined=bounds has huge. The cost of Asan is huge.
    - gpderetta 3y ago
      For OOB you can enable bound checking in the C++ standard library. That's relatively cheap. Of course it won't help with C raw pointers and C array.
giovannibonetti 3y ago
Arguably Rust got good error messages by learning from Elm: https://elm-lang.org/news/compiler-errors-for-humans https://elm-lang.org/news/compiler-errors-for-humans
- estebank 3y ago
  Elm is acknowledged as being the initial inspiration for focusing on diagnostics early on, but Rust got good error messages through elbow grease and focused attention over a long period of time. People getting used to good errors and demanding more, is part of the virtuous circle that keeps them high quality. Making good looking diagnostics requires UX work, but making good diagnostics requires a flexible compiler architecture and a lot of effort, nothing more, nothing less.
- darby_eight 3y ago
  Rust's eye towards errors predates Elm entirely.
  - sirwhinesalot 3y ago
    https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-com... Go read the above.
jonathankoren 3y ago
> I would say the #1 reason I stop learning a technology is because of frustrating or unclear errors. Overly verbose error messages that obscure more than illuminate are chief complaint against C++. Honestly, they can just sap all the energy out of a project.
- cogman10 3y ago
  "You violated a template rule. Here's a novel on everything that's broken as a result" It's why the Constraint system was important for C++.
darby_eight 3y ago
Clang already had decent error messages by the time rust stabilized. There's simply not much you can do at runtime to explain a segfault.
- GrumpySloth 3y ago
  Not when you called templated functions and were greeted with compile-time template stack traces. Or you called overloaded functions and were presented with 50 alternatives you might have meant. The language is inherently unfriendly to user-friendly error messages.
  - darby_eight 3y ago
    [flagged]
    - GrumpySloth 3y ago
      I’m talking about C++. You wrote that Clang already had friendly error messages. While they were less unfriendly than GCC, calling them friendly is a stretch. Rust having traits instead of templates is a big ergonomic improvement in that area.
      - estebank 3y ago
        Funnily enough, trait bounds are still a big pain in the neck to provide good diagnostics for because of the amount of things that need to be tracked that are cross cutting across stages of the compiler that under normal operation don't need to talk to each other. They got better in 2018, as async/await put them even more front and center and focused some attention on them, and a lot of work for keeping additional metadata around was added since then (search the codebase for enum ObligationCauseCode if you're curious) to improve them. Now with the new "next" trait solver they have a chance to get even better. It still easier than providing good diagnostics for template errors though :) (althought I'm convinced that if addressing those errors was high priority, common cases of template instantiations could be modeled internally in the same way as traits purely for diagnostics and materially improve the situation — I understand why it hasn't happened, it is hard and not obviously important).

dist1ll 3y ago

That's what makes me wary of modifying my NixOS config. A single typo and you get an error dump comparable to C++03 templates.

Quekid5 3y ago
... but you do get an error. That's a lot better what you typically get with C or C++. Assuming it's valid systax, of course. This is a veering off topic, but I do agree that Nix-the-language has a lot of issues. (You might suggest Guix, but I don't want to faff about with non-supported repositories for table stakes like firmware and such. Maybe Nickel will eventually provide a more pleasant and principled way to define Nix configurations?)
- nh2 3y ago
  My favourite Nix error message is infinite recursion encountered, at undefined position
  - Quekid5 3y ago
    Haha, reminds me of some Scheme interpreter that would just say something like 'missing paren' at position 0 or EOF depending on where the imbalance was :) ... but, yeah... I'm pretty sure there could be some hints as to whereabouts that infinite recursion was detected.
  - vintermann 3y ago
    I tried some kind of BBC micro at a computer museum, and found out that if you had an error anywhere in your BASIC program, it would just print "error". No line number, no hint at what the problem was.
    - danudey 3y ago
      I could understand some kind of ancient system not having the detail or knowledge to explain what happened in particular, but this is something that still happens in a lot of Microsoft software in particular. Outlook has a consistent tendency to give you errors like "Couldn't get your mail for some reason", or Windows saying "Hey networking isn't working". No "connection timed out" or "couldn't get an IP address" or "DNS lookup failed" or any other error message that is possible to diagnose. Even the Windows network troubleshooting wizard (the "let us try to diagnose why things aren't working for you" process) would consistently give me "yeah man idk" results, when the error is that I'm not getting an address from DHCP and should be extremely easy to diagnose. I get that in a lot of cases, problems cut across lots of errors or areas of responsibility, and getting some other team making some other library to expose their internals to your application might be difficult in an environment like Microsoft, but it's just inexplicable that so much software, even these days, resorts to "nope can't do it" and bail out.
pxc 3y ago
That's definitely the most painful part of iterating on Nix code for me, even in simple configs. You eventually develop an intuition for common problems and rely more on that than on deciphering the stack traces, but that's really not ideal.
lynx23 3y ago
Actually, thats a reason why I never even touched Nix. Besides, being functional and all the hype, but the syntax and naming of the language feels ad-hoc enough for me to never have caught on...
crest 3y ago
It's what got me pissed of enough with xmonad to discard it.

hardwaregeek 3y ago

Yeah Rust is popular because it's a practical language with a nice type system, decent escape hatches, and good tooling. The borrow checker attracts some, but it could have easily been done in a way with terrible usability.

darby_eight 3y ago
> The borrow checker attracts some, but it could have easily been done in a way with terrible usability. Why would anyone use the resulting language over C? What you're describing is C with a slightly friendlier compiler.
- Ar-Curunir 3y ago
  I have never heard C as being described to have a good type system.
  - darby_eight 3y ago
    You could try to argue this is the only source of rust's popularity.... or you could admit that the borrow checker is in fact a reason why folks use Rust over C.
  - jjgreen 3y ago
    To this day, many C programmers believe that strong typing just means pounding extra hard on the keyboard. Peter van der Linden, "Expert C Programming"
  - tialaramex 3y ago
    "Strongly typed, weakly checked". Which is a funny way to say "Not strongly typed" or perhaps more generously "The compilers aren't very good and neither are the programmers but other than that..." (and yes I write that as a long time C programmer) But hey, C does have types: First it has several different integers with silly names like "long" and "short". Then it has the integers again but wearing a Groucho mask and with twice as many zeroes, "float" and "double". Then an integer that's probably one byte, unless it isn't, in which case it is anyway, and which doesn't know whether it's signed or not, "char". Then a very small integer that takes up too much space ("_Bool" aka bool) Finally though, it does have types which definitely aren't integers, unfortunately they participates in integer arithmetic anyway and many C programmers believe they're integers, but the compiler doesn't so that's... well it's a disaster, I speak of course of the pointers.

Quekid5 3y ago

The hard problem with C is that it's hard to tell if what the programmer wrote is an error. Hence warnings... which can be very hit or miss, or absurd overkill in some cases. (Signed overflow being a prime example where you really either just need to define what happens or accept that your compiler is basically never going to warn you about a possible signed overflow -- which is UB. The compromise here by Rust is to allow one to pick between some implementation defined behaviors. That seems pretty sensible.)

uecker 3y ago
For signed overflow I use -fsanitize=signed-integer-overflow .
- Quekid5 3y ago
  Good. I wonder how many people do and also if their compilers support it. (One would hope so, of course. I assume clang and GCC do.) ... but the question is really what you ship to production. Btw, possible signed overflow was just an example of things people do not want warnings for. OOB is far more dangerous, obviously... and the cost for sanitizer in that case is HUGE... and it doesn't actually catch all cases AFAIUI.
  - uecker 3y ago
    For production one could use -fsanitize-undefined-trap-on-error that turns it into traps. I would not describe the cost of -fsanitize-undefined=bounds has huge. The cost of Asan is huge.
  - gpderetta 3y ago
    For OOB you can enable bound checking in the C++ standard library. That's relatively cheap. Of course it won't help with C raw pointers and C array.

giovannibonetti 3y ago

Arguably Rust got good error messages by learning from Elm: https://elm-lang.org/news/compiler-errors-for-humans https://elm-lang.org/news/compiler-errors-for-humans

estebank 3y ago
Elm is acknowledged as being the initial inspiration for focusing on diagnostics early on, but Rust got good error messages through elbow grease and focused attention over a long period of time. People getting used to good errors and demanding more, is part of the virtuous circle that keeps them high quality. Making good looking diagnostics requires UX work, but making good diagnostics requires a flexible compiler architecture and a lot of effort, nothing more, nothing less.
darby_eight 3y ago
Rust's eye towards errors predates Elm entirely.
- sirwhinesalot 3y ago
  https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-com... Go read the above.

jonathankoren 3y ago

> I would say the #1 reason I stop learning a technology is because of frustrating or unclear errors. Overly verbose error messages that obscure more than illuminate are chief complaint against C++. Honestly, they can just sap all the energy out of a project.

cogman10 3y ago
"You violated a template rule. Here's a novel on everything that's broken as a result" It's why the Constraint system was important for C++.

darby_eight 3y ago

Clang already had decent error messages by the time rust stabilized. There's simply not much you can do at runtime to explain a segfault.

GrumpySloth 3y ago
Not when you called templated functions and were greeted with compile-time template stack traces. Or you called overloaded functions and were presented with 50 alternatives you might have meant. The language is inherently unfriendly to user-friendly error messages.
- darby_eight 3y ago
  [flagged]
  - GrumpySloth 3y ago
    I’m talking about C++. You wrote that Clang already had friendly error messages. While they were less unfriendly than GCC, calling them friendly is a stretch. Rust having traits instead of templates is a big ergonomic improvement in that area.
    - estebank 3y ago
      Funnily enough, trait bounds are still a big pain in the neck to provide good diagnostics for because of the amount of things that need to be tracked that are cross cutting across stages of the compiler that under normal operation don't need to talk to each other. They got better in 2018, as async/await put them even more front and center and focused some attention on them, and a lot of work for keeping additional metadata around was added since then (search the codebase for enum ObligationCauseCode if you're curious) to improve them. Now with the new "next" trait solver they have a chance to get even better. It still easier than providing good diagnostics for template errors though :) (althought I'm convinced that if addressing those errors was high priority, common cases of template instantiations could be modeled internally in the same way as traits purely for diagnostics and materially improve the situation — I understand why it hasn't happened, it is hard and not obviously important).