15 ms·

I think one thing that has helped Rust make the first serious advances towards C that we've seen in a long time is also the development tool chain. Getting star

I think one thing that has helped Rust make the first serious advances towards C that we've seen in a long time is also the development tool chain. Getting started with Rust on any major platform, besides embedded development though that's coming along, is so much easier with Rustup and Cargo than the bizarre (to the uninitiated) work you have to do to setup and actually understand your development tool chain in C as well as C++.

IgorPartola 4y ago
cc main.c is about as easy as it gets, no?
- linkdd 4y ago
  Now add some dependencies, some required, some optional, for all platforms, or some specific to some platforms. Then add configuration options for conditional compilation, and a build system to define them properly. Then use the configuration options of your dependencies in your build system. Finally, repeat this process for every project and make sure you use the same syntax/api for your build system so you don't have to relearn everything everytime. cc main.c is as easy as it gets when you rewrite everything from scratch. cargo is as easy as it gets when you want an ecosystem.
  - snovv_crash 4y ago
    Add a closed source dependency in Rust and see how far cargo takes you.
    - linkdd 4y ago
      I assume the closed source dependency is distributed as a .a/.so/.dll file, then you can use bindgen[0]. Still, yes it's a bit more complicated. But can we not pretend that the non-existent toolchain in C/C++ is easier in 99% of use cases? [0] - https://medium.com/dwelo-r-d/using-c-libraries-in-rust-13961948c72a https://medium.com/dwelo-r-d/using-c-libraries-in-rust-13961...
      - snovv_crash 4y ago
        No, I want a closed source Rust dependency. Otherwise it's going through a C API and I lose all of the benefits of using Rust. Once you solve this problem, C++ & CMake are of similar complexity for C++ dependencies. Otherwise to compare C++ toolchains, if it's distributed as a .a file, just adding -l/path/to/libclosed.a works for C++, can't get more simple than that. Or one line in the CMake file with basically the same thing.
        linkdd 4y ago
        A .rlib file then, that you can then add with: RUSTFLAGS="--extern closedlib=path/to/libclosedlib.rlib"
- noselasd 4y ago
  Yes, but only for tiny tools or toys. Most software have dependencies that should be managed, linked in, figure the header file path of etc. Most software consists of several files which you don't want to re-build every time you change just 1 file (unless you change compiler flags etc.). It's a very tiny step from your example until the C or C++ toolchain becomes far from easy.
KingOfCoders 4y ago
Yes (working with Scala, Python, JS/TS in the past), Rust hast the most stable and joyful and complete build environment with rustup, cargo, clippy, audit etc.
seba_dos1 4y ago
When you set things up on your local machine, then this tooling is great. However, once you want to package your stuff, or want to maintain support for a stable distro, you're in for a hell of a ride if you decide to go with Rust. It's not impossible, but it can give you nightmares.
- ssokolow 4y ago
  What is currently missing from https://github.com/cross-rs/cross https://github.com/cross-rs/cross ?
  - seba_dos1 4y ago
    I don't think cross is related to what I'm talking about at all? In fact, relying on it likely makes things worse for downstreams. For packaging, you want your dependencies to be packaged as well, with build system using system-wide versions instead of pulling things from Cargo, with proper dynamic linking. There are several tools that help you manage that for Rust, Debian has some packaging helpers too, but it's pain nevertheless once you have to, say, support multiple crate versions in your code to deal with stable distros. Some of these troubles come more from the ecosystem than the tooling itself.
    - ssokolow 4y ago
      Ahh, the dynamic linking thing. To some extent, I see that more as "Distros have ossified around the workflows and tooling that is essentially 'a third-party package manager like Conan for C++, but for C'". How do you deal with the same monomorphization problems in C++ libraries? See https://blogs.gentoo.org/mgorny/2012/08/20/the-impact-of-cxx-templates-on-library-abi/ https://blogs.gentoo.org/mgorny/2012/08/20/the-impact-of-cxx... How do you deal with vendored single-header libraries and bespoke implementations brought about by C's lack of a cross-distro, cross-platform dependency handling story? You generally don't. https://wiki.alopex.li/LetsBeRealAboutDependencies#gotta-go-deeper https://wiki.alopex.li/LetsBeRealAboutDependencies#gotta-go-... As that article points out, Rust's approach to package management allows things to be shared between projects which, in practice, don't get shared between C projects. With Crates.io not allowing existing crate versions to have their contents modified and Cargo.lock providing a SHA256-verified record of the exact dependencies your project used, you've got a record of what build dependency versions went into your package, which can be used by tools like `cargo audit`. Yes, it means that you need tooling to automate rebuilding the binaries whenever they're statically linked but, as Michał Górny pointed out in 2012, that's already necessary with libraries that use C++ templates and, as was said in "Let's Be Real About Dependencies", "On the flip side, I wonder how many times vlc’s XML parser has been fuzzed?" While it's slow going, discussion and an experimental prototype do exist for embedding full dependency versioning information inside Rust binaries to further help that approach: https://github.com/rust-lang/rfcs/pull/2801 https://github.com/rust-lang/rfcs/pull/2801
redman25 4y ago
Does rust have any other implementations? It seems like that would help adoption as well.
- ______-_-______ 4y ago
  Besides the standard llvm-based compiler, I know of at least two others: https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc
- mustache_kimono 4y ago
  > It seems like that would help adoption as well. How do you mean? Where?
dahfizz 4y ago
Maybe it's just because I am more familiar with C/C++, but I disagree. Cargo is very opinionated, forcing upon you certain directory structures and even a default VCS. If you have a large project, cargo makes you jump through hoops. Building multiple binaries and libraries from one project is a pain, and has to be done exactly as cargo wants. In terms of being able to "just get started", I think `gcc app.c` is way easier than using cargo. But that's not really important. You're not going to replace a million line C project with Rust just because "getting started" was a few seconds faster/slower.
- cgh 4y ago
  Does Cargo have the equivalent of Maven’s archetypes? Eg, project templates to generate a particular directory structure, some default files, etc.
  - ssokolow 4y ago
    Currently, it has two built-in ones for `cargo new` and `cargo init` (--bin and --lib) and there are third-party tools like `cargo generate` which provide for more, but they haven't accepted anything into the main distribution yet. https://github.com/cargo-generate/cargo-generate https://github.com/cargo-generate/cargo-generate
- jitl 4y ago
  You can `rustc app.rs`, and do all the C Makefile stuff that way too (example in the kernel: https://github.com/Rust-for-Linux/linux/blob/rust/rust/Makefile https://github.com/Rust-for-Linux/linux/blob/rust/rust/Makef...). Nothing is forcing you to use Cargo except for convenience.
- linkdd 4y ago
  > Cargo is very opinionated, forcing upon you certain directory structures No, it expects source code in `src` like most C/C++ projects anyway. Then it's `lib.rs` or `main.rs`. The opinionated directory structure (`pkg.rs` or `pkg/mod.rs`) is rustc not cargo. > even a default VCS Because it's the one used by most projects. Anyway, nothing prevents you from using mercurial, svn, ... > Building multiple binaries and libraries from one project is a pain Have you heard of Cargo workspaces? Because I've had no troubles with it. > I think `gcc app.c` is way easier than using cargo Agree to disagree. Because really soon, you'll want to manage dependencies.
scoutt 4y ago
> work you have to do to setup and actually understand your development tool chain in C as well as C++ Open visual studio (or Qt) 'File' menu, 'New C/C++ project'. Press F7 to compile. No command line, no cargo build, no cargo run, no cargo.toml. Just press the green "play" button and your full graphic application shows up. Embedded with Arduino C++: 'file' menu, then 'new sketch', click the arrow to compile and download to the board.
- Cyph0n 4y ago
  Now walk us through how you would use a relatively large library in your new project (e.g., libav or boost). And then show us how to cross-compile both for another OS + arch.
  - scoutt 4y ago
    libav: On Windows: download shared from here(1), unzip anywhere. Right click on the project, select "Project settings" (IIRC) then point to .libs you want to use (or add them all), add include path (ffmpeg/include). Done. On linux (Qt): install with apt-get. Point to libs, add include path (in the .pro file). The only complication is that you have to wrap the #includes with extern "C" {} if you are on C++. I did it for both platforms the other day and it works. Super easy. Cross-compile: on Qt you do it through packs you select at install stage. Sometimes it requires the runtime to be installed (like for Android) but it's not complicated. On VS, I don't know today. I remember for Windows CE you had to install an SDK, and compilation/debug was out-of-the-box (F7 to compile, F5 to debug in-target). And I used Platform Builder for years, and I cross-compiled the entire OS from the menu. On Arduino: select your board from the menu. Also, installing libraries is done through a menu. Pulled from online resources automatically. But I guess I will not convince you. You'll come up with another challenge. (1) https://github.com/BtbN/FFmpeg-Builds/releases https://github.com/BtbN/FFmpeg-Builds/releases
    - lifthrasiir 4y ago
      You have just (inadvertently) demonstrated the exact problem: if you don't have a pre-built binary your job is significantly harder. But everyone knows that and most popular libraries do have a pre-built binary officially or unofficially. That makes this kind of discussion harder, because someone is talking about the worst case and another (in this case you) is talking about the best case.

IgorPartola 4y ago

cc main.c is about as easy as it gets, no?

linkdd 4y ago
Now add some dependencies, some required, some optional, for all platforms, or some specific to some platforms. Then add configuration options for conditional compilation, and a build system to define them properly. Then use the configuration options of your dependencies in your build system. Finally, repeat this process for every project and make sure you use the same syntax/api for your build system so you don't have to relearn everything everytime. cc main.c is as easy as it gets when you rewrite everything from scratch. cargo is as easy as it gets when you want an ecosystem.
- snovv_crash 4y ago
  Add a closed source dependency in Rust and see how far cargo takes you.
  - linkdd 4y ago
    I assume the closed source dependency is distributed as a .a/.so/.dll file, then you can use bindgen[0]. Still, yes it's a bit more complicated. But can we not pretend that the non-existent toolchain in C/C++ is easier in 99% of use cases? [0] - https://medium.com/dwelo-r-d/using-c-libraries-in-rust-13961948c72a https://medium.com/dwelo-r-d/using-c-libraries-in-rust-13961...
    - snovv_crash 4y ago
      No, I want a closed source Rust dependency. Otherwise it's going through a C API and I lose all of the benefits of using Rust. Once you solve this problem, C++ & CMake are of similar complexity for C++ dependencies. Otherwise to compare C++ toolchains, if it's distributed as a .a file, just adding -l/path/to/libclosed.a works for C++, can't get more simple than that. Or one line in the CMake file with basically the same thing.
      - linkdd 4y ago
        A .rlib file then, that you can then add with: RUSTFLAGS="--extern closedlib=path/to/libclosedlib.rlib"
noselasd 4y ago
Yes, but only for tiny tools or toys. Most software have dependencies that should be managed, linked in, figure the header file path of etc. Most software consists of several files which you don't want to re-build every time you change just 1 file (unless you change compiler flags etc.). It's a very tiny step from your example until the C or C++ toolchain becomes far from easy.

KingOfCoders 4y ago

Yes (working with Scala, Python, JS/TS in the past), Rust hast the most stable and joyful and complete build environment with rustup, cargo, clippy, audit etc.

seba_dos1 4y ago

When you set things up on your local machine, then this tooling is great. However, once you want to package your stuff, or want to maintain support for a stable distro, you're in for a hell of a ride if you decide to go with Rust. It's not impossible, but it can give you nightmares.

ssokolow 4y ago
What is currently missing from https://github.com/cross-rs/cross https://github.com/cross-rs/cross ?
- seba_dos1 4y ago
  I don't think cross is related to what I'm talking about at all? In fact, relying on it likely makes things worse for downstreams. For packaging, you want your dependencies to be packaged as well, with build system using system-wide versions instead of pulling things from Cargo, with proper dynamic linking. There are several tools that help you manage that for Rust, Debian has some packaging helpers too, but it's pain nevertheless once you have to, say, support multiple crate versions in your code to deal with stable distros. Some of these troubles come more from the ecosystem than the tooling itself.
  - ssokolow 4y ago
    Ahh, the dynamic linking thing. To some extent, I see that more as "Distros have ossified around the workflows and tooling that is essentially 'a third-party package manager like Conan for C++, but for C'". How do you deal with the same monomorphization problems in C++ libraries? See https://blogs.gentoo.org/mgorny/2012/08/20/the-impact-of-cxx-templates-on-library-abi/ https://blogs.gentoo.org/mgorny/2012/08/20/the-impact-of-cxx... How do you deal with vendored single-header libraries and bespoke implementations brought about by C's lack of a cross-distro, cross-platform dependency handling story? You generally don't. https://wiki.alopex.li/LetsBeRealAboutDependencies#gotta-go-deeper https://wiki.alopex.li/LetsBeRealAboutDependencies#gotta-go-... As that article points out, Rust's approach to package management allows things to be shared between projects which, in practice, don't get shared between C projects. With Crates.io not allowing existing crate versions to have their contents modified and Cargo.lock providing a SHA256-verified record of the exact dependencies your project used, you've got a record of what build dependency versions went into your package, which can be used by tools like `cargo audit`. Yes, it means that you need tooling to automate rebuilding the binaries whenever they're statically linked but, as Michał Górny pointed out in 2012, that's already necessary with libraries that use C++ templates and, as was said in "Let's Be Real About Dependencies", "On the flip side, I wonder how many times vlc’s XML parser has been fuzzed?" While it's slow going, discussion and an experimental prototype do exist for embedding full dependency versioning information inside Rust binaries to further help that approach: https://github.com/rust-lang/rfcs/pull/2801 https://github.com/rust-lang/rfcs/pull/2801

redman25 4y ago

Does rust have any other implementations? It seems like that would help adoption as well.

______-_-______ 4y ago
Besides the standard llvm-based compiler, I know of at least two others: https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc
mustache_kimono 4y ago
> It seems like that would help adoption as well. How do you mean? Where?

dahfizz 4y ago

Maybe it's just because I am more familiar with C/C++, but I disagree. Cargo is very opinionated, forcing upon you certain directory structures and even a default VCS. If you have a large project, cargo makes you jump through hoops. Building multiple binaries and libraries from one project is a pain, and has to be done exactly as cargo wants. In terms of being able to "just get started", I think `gcc app.c` is way easier than using cargo. But that's not really important. You're not going to replace a million line C project with Rust just because "getting started" was a few seconds faster/slower.

cgh 4y ago
Does Cargo have the equivalent of Maven’s archetypes? Eg, project templates to generate a particular directory structure, some default files, etc.
- ssokolow 4y ago
  Currently, it has two built-in ones for `cargo new` and `cargo init` (--bin and --lib) and there are third-party tools like `cargo generate` which provide for more, but they haven't accepted anything into the main distribution yet. https://github.com/cargo-generate/cargo-generate https://github.com/cargo-generate/cargo-generate
jitl 4y ago
You can `rustc app.rs`, and do all the C Makefile stuff that way too (example in the kernel: https://github.com/Rust-for-Linux/linux/blob/rust/rust/Makefile https://github.com/Rust-for-Linux/linux/blob/rust/rust/Makef...). Nothing is forcing you to use Cargo except for convenience.
linkdd 4y ago
> Cargo is very opinionated, forcing upon you certain directory structures No, it expects source code in `src` like most C/C++ projects anyway. Then it's `lib.rs` or `main.rs`. The opinionated directory structure (`pkg.rs` or `pkg/mod.rs`) is rustc not cargo. > even a default VCS Because it's the one used by most projects. Anyway, nothing prevents you from using mercurial, svn, ... > Building multiple binaries and libraries from one project is a pain Have you heard of Cargo workspaces? Because I've had no troubles with it. > I think `gcc app.c` is way easier than using cargo Agree to disagree. Because really soon, you'll want to manage dependencies.

scoutt 4y ago

> work you have to do to setup and actually understand your development tool chain in C as well as C++ Open visual studio (or Qt) 'File' menu, 'New C/C++ project'. Press F7 to compile. No command line, no cargo build, no cargo run, no cargo.toml. Just press the green "play" button and your full graphic application shows up. Embedded with Arduino C++: 'file' menu, then 'new sketch', click the arrow to compile and download to the board.

Cyph0n 4y ago
Now walk us through how you would use a relatively large library in your new project (e.g., libav or boost). And then show us how to cross-compile both for another OS + arch.
- scoutt 4y ago
  libav: On Windows: download shared from here(1), unzip anywhere. Right click on the project, select "Project settings" (IIRC) then point to .libs you want to use (or add them all), add include path (ffmpeg/include). Done. On linux (Qt): install with apt-get. Point to libs, add include path (in the .pro file). The only complication is that you have to wrap the #includes with extern "C" {} if you are on C++. I did it for both platforms the other day and it works. Super easy. Cross-compile: on Qt you do it through packs you select at install stage. Sometimes it requires the runtime to be installed (like for Android) but it's not complicated. On VS, I don't know today. I remember for Windows CE you had to install an SDK, and compilation/debug was out-of-the-box (F7 to compile, F5 to debug in-target). And I used Platform Builder for years, and I cross-compiled the entire OS from the menu. On Arduino: select your board from the menu. Also, installing libraries is done through a menu. Pulled from online resources automatically. But I guess I will not convince you. You'll come up with another challenge. (1) https://github.com/BtbN/FFmpeg-Builds/releases https://github.com/BtbN/FFmpeg-Builds/releases
  - lifthrasiir 4y ago
    You have just (inadvertently) demonstrated the exact problem: if you don't have a pre-built binary your job is significantly harder. But everyone knows that and most popular libraries do have a pre-built binary officially or unofficially. That makes this kind of discussion harder, because someone is talking about the worst case and another (in this case you) is talking about the best case.