4 ms·

I think Rust is harder to learn, but once you grok it, I don't think it's harder to use, or at least to use correctly. It's hard to write correct C because the

I think Rust is harder to learn, but once you grok it, I don't think it's harder to use, or at least to use correctly. It's hard to write correct C because the standard tooling doesn't give you much help beyond `-Wall`. Rust's normal error messages are delightfully helpful. For example, I just wrote some bad code and got: --> src/main.rs:45:34 | 45 | actions.append(&mut func(opt.selected)); | ---- ^^^^^^^^^^^^ expected `&str`, found `String` | | | arguments to this function are incorrect | help: consider borrowing here | 45 | actions.append(&mut func(&opt.selected)); | I even had to cheat a little to get that far, because my editor used rust-analyzer to flag the error before I had the chance to build the code. Also, I highly recommend getting into the habit of running `cargo clippy` regularly. It's a wonderful tool for catching non-idiomatic code. I learned a lot from its suggestions on how I could improve my work.

kelnos 2y ago
> I think Rust is harder to learn, but once you grok it, I don't think it's harder to use, or at least to use correctly. It's hard to write correct C because the standard tooling doesn't give you much help beyond `-Wall`. When I say Rust is harder to use (even after learning it decently well), what I mean is that it's still easier to write a pile of C code and get it to compile than it is to write a pile of Rust code and get it to compile. The important difference is that the easier-written C code will have a bunch of bugs in it than the Rust code will. I think that's what I mean when I say Rust is harder to use, but I'm more productive in it: I have to do so much less debugging when writing Rust, and writing and debugging C code is more difficult and takes up more time than writing the Rust code (and doing whatever less debugging is necessary there). > Also, I highly recommend getting into the habit of running `cargo clippy` regularly. It's a wonderful tool for catching non-idiomatic code. That's a great tip, and I usually forget to do so. On a couple of my personal projects, I have a CI step that fails the build if there are any clippy messages, but I don't use it for most of my personal projects. I do have a `cargo fmt --check` in my pre-commit hooks, but I should add clippy to that as well.
- sestep 2y ago
  If you're using VS Code then you can add `"rust-analyzer.check.command": "clippy"` to your `settings.json`. I assume there's a similar setting for rust-analyzer in other editors.
  - maleldil 2y ago
    Neovim: require("lspconfig").rust_analyzer.setup({ settings = { ["rust-analyzer"] = { checkOnSave = { command = "clippy", allFeatures = true, }, }, }, })
  - pabs3 2y ago
    You might want to reconsider use of rust-analyzer, it isn't safe to use on code you haven't written yourself. https://rust-analyzer.github.io/book/security.html https://rust-analyzer.github.io/book/security.html
    - swiftcoder 2y ago
      > it isn't safe to use on code you haven't written yourself Neither is cargo (nor npm, nor any other package manager, for that matter). I'm not sure what value being that paranoid is buying you in the long run.
      - pabs3 2y ago
        Package managers are for running other people's code, I would not expect the same of static analysis tools, especially since they are of use while auditing other people's code before building/running it.
        swiftcoder 2y ago
        Cargo's threat model here is identical to that of rust analyser. If you trust your dependency tree sufficiently to run `cargo build`, then you trust it sufficiently to run rust analyser.
epidemian 2y ago
> Also, I highly recommend getting into the habit of running `cargo clippy` regularly. You can also have that hooked up to the editor, just like `cargo check` errors. I find this to be quite useful, because i hace a hard time getting into habits, especially for thing that i'm not forced to do in some way. It's important that those Clippy lints are shown as soft warnings instead of hard errors though, as otherwise they'd be too distracting at times.
crabbone 2y ago
* Rust errors can be equally unhelpful. Also, the error you posted is hands down awful. It doesn't tell you what went wrong, and it's excessively naive to rely on compiler to offer a correct fix in all but the most trivial cases. When errors happen, it's a consequence of an impasse, a logical contradiction: two mutually exclusive arguments have been made: a file was assumed to exist, but was also assumed not to exist -- this is what's at the core of the error. The idiotic error that Rust compiler gave you doesn't say what were the assumptions, it just, essentially, tells you "here's the error, deal with it". * In Rust, you will have to deal with a lot of unnecessary errors. The language is designed to make its users create a host of auxiliary entities: results, options, futures, tasks and so on. Instead of dealing with the "interesting" domain objects, the user of the language is mired in the "intricate interplay" between objects she doesn't care about. This is, in general, a woe of languages with extensive type systems, but in Rust it's a woe on a whole new level. Every program becomes a Sisyphean struggle to wrangle through all those unnecessary objects to finally get to write the actual code. Interestingly though, there's a tendency in a lot of programmers to like solving these useless problems instead of dealing with the objectives of their program (often because those objectives are boring or because programmers don't understand them, or because they have no influence over them).
- necubi 2y ago
  I don't follow your first point—the compiler is pointing out exactly what the problem is (the argument has the incorrect type) and then telling you what you likely wanted to do (borrow the String). What would you see as a more helpful error message in this case?
  - crabbone 2y ago
    The compiler says "expected X, but found Y". I don't know how to interpret this: is the type of the thing underlined with "^^^" X or Y? "Expected" and "found" are just like "up" and "down" in space: they are meaningless if you don't know what the compiler expects (and why should it?). What it needs to say is something along the lines of "a function f is defined with type X, but is given an argument of type Y": maybe the function should be defined differently, maybe the argument needs to change -- it's up to the programmer to decide.
mountainriver 2y ago
Agree, Rust is quite hard to learn, but now that I know it I have a hard time writing anything else. It really gives you the best of a lot of worlds. Granted I can still crank out a python program faster, that kinda works but god forbid you need to scale it or use any sort of concurrency at all.
- kelvinjps10 2y ago
  Go?
  - mountainriver 2y ago
    I do a lot of ML, and the Go memory model is highly problematic. The Go to C FFI is too slow and doesn't interface with CUDA well.
seba_dos1 2y ago
> It's hard to write correct C because the standard tooling doesn't give you much help beyond `-Wall` I won't disagree that correct C is harder to write, but it's not 2005 anymore and standard tooling gives you access to things like asan, msan, ubsan, tsan, clang-tidy...
- oconnor663 2y ago
  C-with-sanitizers is miles ahead of what C used to be, but just a couple weeks ago I ran into a dangling pointer bug that ASan doesn't catch. (Sidenote 5 here: https://jacko.io/smart_pointers.html https://jacko.io/smart_pointers.html) It seems like one of the big downsides of sanitizers is that they can't instrument other people's code, in this case the C standard library.

kelnos 2y ago

> I think Rust is harder to learn, but once you grok it, I don't think it's harder to use, or at least to use correctly. It's hard to write correct C because the standard tooling doesn't give you much help beyond `-Wall`. When I say Rust is harder to use (even after learning it decently well), what I mean is that it's still easier to write a pile of C code and get it to compile than it is to write a pile of Rust code and get it to compile. The important difference is that the easier-written C code will have a bunch of bugs in it than the Rust code will. I think that's what I mean when I say Rust is harder to use, but I'm more productive in it: I have to do so much less debugging when writing Rust, and writing and debugging C code is more difficult and takes up more time than writing the Rust code (and doing whatever less debugging is necessary there). > Also, I highly recommend getting into the habit of running `cargo clippy` regularly. It's a wonderful tool for catching non-idiomatic code. That's a great tip, and I usually forget to do so. On a couple of my personal projects, I have a CI step that fails the build if there are any clippy messages, but I don't use it for most of my personal projects. I do have a `cargo fmt --check` in my pre-commit hooks, but I should add clippy to that as well.

sestep 2y ago
If you're using VS Code then you can add `"rust-analyzer.check.command": "clippy"` to your `settings.json`. I assume there's a similar setting for rust-analyzer in other editors.
- maleldil 2y ago
  Neovim: require("lspconfig").rust_analyzer.setup({ settings = { ["rust-analyzer"] = { checkOnSave = { command = "clippy", allFeatures = true, }, }, }, })
- pabs3 2y ago
  You might want to reconsider use of rust-analyzer, it isn't safe to use on code you haven't written yourself. https://rust-analyzer.github.io/book/security.html https://rust-analyzer.github.io/book/security.html
  - swiftcoder 2y ago
    > it isn't safe to use on code you haven't written yourself Neither is cargo (nor npm, nor any other package manager, for that matter). I'm not sure what value being that paranoid is buying you in the long run.
    - pabs3 2y ago
      Package managers are for running other people's code, I would not expect the same of static analysis tools, especially since they are of use while auditing other people's code before building/running it.
      - swiftcoder 2y ago
        Cargo's threat model here is identical to that of rust analyser. If you trust your dependency tree sufficiently to run `cargo build`, then you trust it sufficiently to run rust analyser.

epidemian 2y ago

> Also, I highly recommend getting into the habit of running `cargo clippy` regularly. You can also have that hooked up to the editor, just like `cargo check` errors. I find this to be quite useful, because i hace a hard time getting into habits, especially for thing that i'm not forced to do in some way. It's important that those Clippy lints are shown as soft warnings instead of hard errors though, as otherwise they'd be too distracting at times.

crabbone 2y ago

* Rust errors can be equally unhelpful. Also, the error you posted is hands down awful. It doesn't tell you what went wrong, and it's excessively naive to rely on compiler to offer a correct fix in all but the most trivial cases. When errors happen, it's a consequence of an impasse, a logical contradiction: two mutually exclusive arguments have been made: a file was assumed to exist, but was also assumed not to exist -- this is what's at the core of the error. The idiotic error that Rust compiler gave you doesn't say what were the assumptions, it just, essentially, tells you "here's the error, deal with it". * In Rust, you will have to deal with a lot of unnecessary errors. The language is designed to make its users create a host of auxiliary entities: results, options, futures, tasks and so on. Instead of dealing with the "interesting" domain objects, the user of the language is mired in the "intricate interplay" between objects she doesn't care about. This is, in general, a woe of languages with extensive type systems, but in Rust it's a woe on a whole new level. Every program becomes a Sisyphean struggle to wrangle through all those unnecessary objects to finally get to write the actual code. Interestingly though, there's a tendency in a lot of programmers to like solving these useless problems instead of dealing with the objectives of their program (often because those objectives are boring or because programmers don't understand them, or because they have no influence over them).

necubi 2y ago
I don't follow your first point—the compiler is pointing out exactly what the problem is (the argument has the incorrect type) and then telling you what you likely wanted to do (borrow the String). What would you see as a more helpful error message in this case?
- crabbone 2y ago
  The compiler says "expected X, but found Y". I don't know how to interpret this: is the type of the thing underlined with "^^^" X or Y? "Expected" and "found" are just like "up" and "down" in space: they are meaningless if you don't know what the compiler expects (and why should it?). What it needs to say is something along the lines of "a function f is defined with type X, but is given an argument of type Y": maybe the function should be defined differently, maybe the argument needs to change -- it's up to the programmer to decide.

mountainriver 2y ago

Agree, Rust is quite hard to learn, but now that I know it I have a hard time writing anything else. It really gives you the best of a lot of worlds. Granted I can still crank out a python program faster, that kinda works but god forbid you need to scale it or use any sort of concurrency at all.

kelvinjps10 2y ago
Go?
- mountainriver 2y ago
  I do a lot of ML, and the Go memory model is highly problematic. The Go to C FFI is too slow and doesn't interface with CUDA well.

seba_dos1 2y ago

> It's hard to write correct C because the standard tooling doesn't give you much help beyond `-Wall` I won't disagree that correct C is harder to write, but it's not 2005 anymore and standard tooling gives you access to things like asan, msan, ubsan, tsan, clang-tidy...

oconnor663 2y ago
C-with-sanitizers is miles ahead of what C used to be, but just a couple weeks ago I ran into a dangling pointer bug that ASan doesn't catch. (Sidenote 5 here: https://jacko.io/smart_pointers.html https://jacko.io/smart_pointers.html) It seems like one of the big downsides of sanitizers is that they can't instrument other people's code, in this case the C standard library.