4 ms·

I'm from embedded too. We tried to use rust in one of our projects and came to the conclusion that it makes no sense to convert our team from experiences C++ de

I'm from embedded too. We tried to use rust in one of our projects and came to the conclusion that it makes no sense to convert our team from experiences C++ developers to beginner level Rust developers. Additionally to that, it was nearby impossible to control the amount of packages that come in with Cargo. We had for a small tool three versions of the same library as dependency in our binary. Additionally to that, a part of the team doesn't had fun on writing code with Rust. We trashed the whole tool, which was a massive loss of time for the project.

cmrdporcupine 1y ago
You can absolutely use rustc without Cargo and there's frankly plenty of arguments for doing so in the context of embedded.
- mgh95 1y ago
  Large parts of tooling dependent on cargo; for examples, lsp, analyzer, etc. Once you take out cargo, rusts development environment becomes quite poor.
  - jacquesm 1y ago
    This 'language requires an eco-system' is something that I really dislike. The linker is where it should come together, not in your choices about importing external dependencies, module packaging, source code hosting options, debugger and so on.
    - mgh95 1y ago
      Unfortunately, that is the way rust set up their toolchain. In many ways, and for most if not all ecosystems, I do agree with you.
  - steveklabnik 1y ago
    This is also just a matter of work, for example, the Buck folks have put in the work so that rust-analyzer works well with projects based on it.
    - mgh95 1y ago
      That's good. I generally think these kinds of tools (lsp, analyzers, etc.) should be based upon CLI tools. I'll be more open to when either projects seeking to integrate rust utilize tools such as buck or these tools can be more easily integrated into make/cmake based projects. There is a lot of legacy code out there and I generally feel like many of the rust advocates forget how important it is to play well with legacy project setups.
      - steveklabnik 1y ago
        For RA, it just needs a config file, Buck shipped a tool that writes it out for you.
- 1vuio0pswjnm7 1y ago
  Any recommended pointers to examples of how to use rustc without cargo I dislike the tone of the evangelism and the anti-C attitude but I'm not anti-rust. I purchased a computer with an oversized amount or RAM in part so I could experiment with rust. But determining how to write, edit and compile small programs, from the ground up, without cargo appears exceedingly difficult, and feels like going against the tide It stands to reason that the embedded programmer commenting was unable to determine how to avoid using cargo and pulling in unnecessary dependencies. Otherwise he would not have encountered this problem
  - cmrdporcupine 1y ago
    Definitely going against the tide; but possible e.g. Chrome & Fuchsia both build included Rust bits using their existing build system. Bazel and Buck2 both work well with it, relatively. One can also just be really disciplined with Cargo and not add superfluous deps and be careful about the ones you do include to monitor their transitive dependencies. IMHO this is more about crates.io than Cargo, and is the biggest weakness of the language community. A bulk of developers unfortunately I think come from an NPM-using background and so aren't philosophically ... attuned... to see the problem here.

cmrdporcupine 1y ago

You can absolutely use rustc without Cargo and there's frankly plenty of arguments for doing so in the context of embedded.

mgh95 1y ago
Large parts of tooling dependent on cargo; for examples, lsp, analyzer, etc. Once you take out cargo, rusts development environment becomes quite poor.
- jacquesm 1y ago
  This 'language requires an eco-system' is something that I really dislike. The linker is where it should come together, not in your choices about importing external dependencies, module packaging, source code hosting options, debugger and so on.
  - mgh95 1y ago
    Unfortunately, that is the way rust set up their toolchain. In many ways, and for most if not all ecosystems, I do agree with you.
- steveklabnik 1y ago
  This is also just a matter of work, for example, the Buck folks have put in the work so that rust-analyzer works well with projects based on it.
  - mgh95 1y ago
    That's good. I generally think these kinds of tools (lsp, analyzers, etc.) should be based upon CLI tools. I'll be more open to when either projects seeking to integrate rust utilize tools such as buck or these tools can be more easily integrated into make/cmake based projects. There is a lot of legacy code out there and I generally feel like many of the rust advocates forget how important it is to play well with legacy project setups.
    - steveklabnik 1y ago
      For RA, it just needs a config file, Buck shipped a tool that writes it out for you.
1vuio0pswjnm7 1y ago
Any recommended pointers to examples of how to use rustc without cargo I dislike the tone of the evangelism and the anti-C attitude but I'm not anti-rust. I purchased a computer with an oversized amount or RAM in part so I could experiment with rust. But determining how to write, edit and compile small programs, from the ground up, without cargo appears exceedingly difficult, and feels like going against the tide It stands to reason that the embedded programmer commenting was unable to determine how to avoid using cargo and pulling in unnecessary dependencies. Otherwise he would not have encountered this problem
- cmrdporcupine 1y ago
  Definitely going against the tide; but possible e.g. Chrome & Fuchsia both build included Rust bits using their existing build system. Bazel and Buck2 both work well with it, relatively. One can also just be really disciplined with Cargo and not add superfluous deps and be careful about the ones you do include to monitor their transitive dependencies. IMHO this is more about crates.io than Cargo, and is the biggest weakness of the language community. A bulk of developers unfortunately I think come from an NPM-using background and so aren't philosophically ... attuned... to see the problem here.