3 ms·

From personal experience Rust has the lowest “Google search to error message” ratio (if that’s a metric) of any programming tool I’ve used. It’s genuinely a del

From personal experience Rust has the lowest “Google search to error message” ratio (if that’s a metric) of any programming tool I’ve used. It’s genuinely a delight to use after having to deal with error messages from various JavaScript tools, Python packages, and C/C++ build tools.

inferiorhuman 8y ago
That all depends on how deep into macro territory you get. My experience has been that serde-derive and diesel.rs give absolutely arcane error messages. There are a lot of things that rust at least tries to get right, and that helps a lot. That said, even with all the nagging faults I find that rust development feels more productive than lots of other languages. A large part of that is the tools, sure, but the other major part is the rust community itself.
- thomasfoster96 8y ago
  It sounds like I probably haven’t gone deep enough into macro territory then. Still, when having to do things with JS/Python/C++ I’ve wasted many afternoons down the rabbit hole of trying to glean information from Github Issues, stackoverflow answers, Twitter threads and obscure forum threads — usually to find the problem (and fix) I ran into was so trivial it could have been a single line in an error message. (I feel like a lot of JS tools - particularly Webpack, Jest and Babel - have regressed a fair bit recently in this regard. Python just fails silently (or bizarrely) too often and C/C++ compiler error messages are often less readable than the code itself.)
  - inferiorhuman 8y ago
    IIRC rust was designed from the get go to be user friendly. That's why you have things like intelligible error messages and rls. The rust community, as well, plays a huge part in how easy it can be to track down answers. But try debugging a nom parser sometime. Your eyes will bleed. OTOH the contrast to Javascript is pretty stark. As much as I've got plenty of complaints about the language itself, the community really a detriment. Things like Electron and Node actively shun cross-platform compatibility. Tools like webpack tend to attract cargo cultists. It seems there's a lot of wizardry and hair pulling involved anytime I touch JS. C/C++ though has gotten a lot better with the advent of clang.
- drbawb 8y ago
  Honestly I don't think Diesel error messages are too bad, they're just extremely verbose to a fault. It'd be nice if it could filter out a lot of the duplicate information, or maybe just print spans. Usually when I get a Diesel error message it's of the form: "got <this huge tuple of types>, expected <this huge tuple of types with one of them transposed>." If diesel (or the compiler) could just put a span under the element(s) of a generic tuple that don't match it'd help immensely w/ the vast majority of errors I see from that crate.
  - inferiorhuman 8y ago
    What caught me off guard were the error messages when not enabling serde functionality for optional dependent crates (e.g. chrono). Nom, which I love, has been a matter of interpreting the error messages with a divining rod though. Emphasizing which part of the tuple didn't match up would be a big win, but IMO it should be pulled out and mentioned first. Highlighting could get lost in the noise (moreso without all the ANSI escape codes if you're redirecting output or whatnot).
    - ay 8y ago
      +1 on needing to specify “serde” as a feature for chrono. Another one was needing to enable “huge-tables” for diesel itself - some of my tables from the “legacy” system have many fields.
      - inferiorhuman 8y ago
        Not just chrono but bigdecimal too (diesel really needs some more explicit documentation IMO).
- ay 8y ago
  Diesel.rs does give very scary looking errors but I found they are mostly due to the entire record structure being there as a (part of) type signature - after some time I started to get a “feeling” for what is wrong. Also, over time, as I gained experience with the language, I found myself taking repeating code fragments and creating higher-order macros - both for Diesel.rs stuff. That reduces the repetitive code and errors. Macros in Rust are a great way to reduce a complexity where the functions can’t. Source: during the past 1.5 years period in a couple of 2-3 month spurts I rewrote a C#/ASP.Net homegrown NMS dealing with provisioning and operation of a large-ish (about 15K people) event network consisting ~500 devices, all in all probably about 50KLoC of Rust code doing FTP/TFTP/SNMP and ssh/telnet interactions and this year the frontend. Now (over the new year holidays) I am using the learnings from that to build a stateless-at-server ASP.Net-like framework using Iron, Diesel.rs, rust-Mustache and iron-sessionstorage on the server side and HyperHTML on the client side. I hope to open source it (the framework) at some point, when I get it to Rails-like ease of use. Some additional impressions: I feel I am about half as productive with Rust initially compared to C# for smaller changes, but the final result is much more solid, requiring practically zero debugging. And as I build the abstractions later it becomes easier and easier. Also it is a joy to get a consistent and easily traceable memory footprint compared to mono and about 10x the performance (in debug build) compared to the mono version. And the benchmarks show I have about 5x-7x more if I run it in release mode. So - a very happy Rust user here.

inferiorhuman 8y ago

That all depends on how deep into macro territory you get. My experience has been that serde-derive and diesel.rs give absolutely arcane error messages. There are a lot of things that rust at least tries to get right, and that helps a lot. That said, even with all the nagging faults I find that rust development feels more productive than lots of other languages. A large part of that is the tools, sure, but the other major part is the rust community itself.

thomasfoster96 8y ago
It sounds like I probably haven’t gone deep enough into macro territory then. Still, when having to do things with JS/Python/C++ I’ve wasted many afternoons down the rabbit hole of trying to glean information from Github Issues, stackoverflow answers, Twitter threads and obscure forum threads — usually to find the problem (and fix) I ran into was so trivial it could have been a single line in an error message. (I feel like a lot of JS tools - particularly Webpack, Jest and Babel - have regressed a fair bit recently in this regard. Python just fails silently (or bizarrely) too often and C/C++ compiler error messages are often less readable than the code itself.)
- inferiorhuman 8y ago
  IIRC rust was designed from the get go to be user friendly. That's why you have things like intelligible error messages and rls. The rust community, as well, plays a huge part in how easy it can be to track down answers. But try debugging a nom parser sometime. Your eyes will bleed. OTOH the contrast to Javascript is pretty stark. As much as I've got plenty of complaints about the language itself, the community really a detriment. Things like Electron and Node actively shun cross-platform compatibility. Tools like webpack tend to attract cargo cultists. It seems there's a lot of wizardry and hair pulling involved anytime I touch JS. C/C++ though has gotten a lot better with the advent of clang.
drbawb 8y ago
Honestly I don't think Diesel error messages are too bad, they're just extremely verbose to a fault. It'd be nice if it could filter out a lot of the duplicate information, or maybe just print spans. Usually when I get a Diesel error message it's of the form: "got <this huge tuple of types>, expected <this huge tuple of types with one of them transposed>." If diesel (or the compiler) could just put a span under the element(s) of a generic tuple that don't match it'd help immensely w/ the vast majority of errors I see from that crate.
- inferiorhuman 8y ago
  What caught me off guard were the error messages when not enabling serde functionality for optional dependent crates (e.g. chrono). Nom, which I love, has been a matter of interpreting the error messages with a divining rod though. Emphasizing which part of the tuple didn't match up would be a big win, but IMO it should be pulled out and mentioned first. Highlighting could get lost in the noise (moreso without all the ANSI escape codes if you're redirecting output or whatnot).
  - ay 8y ago
    +1 on needing to specify “serde” as a feature for chrono. Another one was needing to enable “huge-tables” for diesel itself - some of my tables from the “legacy” system have many fields.
    - inferiorhuman 8y ago
      Not just chrono but bigdecimal too (diesel really needs some more explicit documentation IMO).
ay 8y ago
Diesel.rs does give very scary looking errors but I found they are mostly due to the entire record structure being there as a (part of) type signature - after some time I started to get a “feeling” for what is wrong. Also, over time, as I gained experience with the language, I found myself taking repeating code fragments and creating higher-order macros - both for Diesel.rs stuff. That reduces the repetitive code and errors. Macros in Rust are a great way to reduce a complexity where the functions can’t. Source: during the past 1.5 years period in a couple of 2-3 month spurts I rewrote a C#/ASP.Net homegrown NMS dealing with provisioning and operation of a large-ish (about 15K people) event network consisting ~500 devices, all in all probably about 50KLoC of Rust code doing FTP/TFTP/SNMP and ssh/telnet interactions and this year the frontend. Now (over the new year holidays) I am using the learnings from that to build a stateless-at-server ASP.Net-like framework using Iron, Diesel.rs, rust-Mustache and iron-sessionstorage on the server side and HyperHTML on the client side. I hope to open source it (the framework) at some point, when I get it to Rails-like ease of use. Some additional impressions: I feel I am about half as productive with Rust initially compared to C# for smaller changes, but the final result is much more solid, requiring practically zero debugging. And as I build the abstractions later it becomes easier and easier. Also it is a joy to get a consistent and easily traceable memory footprint compared to mono and about 10x the performance (in debug build) compared to the mono version. And the benchmarks show I have about 5x-7x more if I run it in release mode. So - a very happy Rust user here.