8 ms·

Lots of extreme generalisations and exaggerations of the situation with C. It's great that you like rust and want to write your code in it, I don't really care

Lots of extreme generalisations and exaggerations of the situation with C. It's great that you like rust and want to write your code in it, I don't really care at the end of the day, but vague statements such are not very useful or productive. >There's no standard for building C programs. Is there a written standard for compiling rust programs? I don't think so. Rust doesn't do standards after all. Jokes aside, this is basically irrelevant. Why does there need to be a standard for building C programs? Making something build across platforms (including cross compilation to other platforms) has been solved by everyone and their grandmother at this point. This means that aside from taking the route of re-implementing it yourself (not particularly difficult) you have literally dozens of perfectly good options to chose from. In fact, most of this rant sounds like it stems from your dislike of OpenMP not C. >I could have kept the library in C and replaced OpenMP with some other solution instead, but I wasn't keen on reinventing this wheel. Even basic things like spawning a thread run into C's portability woes. Thankfully, you don't need to reinvent the wheel, the problem of cross platform multiprocessing in C has been solved at least a dozen times by now. It should be trivial to use one of these many options (or even write your own, even if you don't like the idea of "reinventing the wheel" it's certainly not particularly difficult either and can likely be lighter than any other more general option). >The platonic ideal portable C exists only as a hypothetical construct in the C standard. The C that exists in the real world is whatever Microsoft, Apple, and others have shipped. That C is a mess of vendor-specific toolchains, each with its own way of doing things, missing features, broken headers, and leaky abstractions. Shouting "it's not C's fault, screw <insert vendor name>!" doesn't solve the problem, but switching to Rust does. I mean, rust is hardly helping you here. There's one implementation of rust doing their own thing so far, nothing stops anyone from making this situation as "bad" as in C. You may as well just say you only support clang or only support GCC and base your project around that assumption. In fact, if you're making the mistake of trying to support a microsoft compiler then I would argue that you've made your life difficult for no reason and blamed it on C. >dreadful state of C dependency management did. Hardly any more dreadful than rust's solution to the problem.

sanxiyn 5y ago
I disagree about dependency management. Let's say, to avoid reinventing the wheel, I decided to use GLib for cross-platform threading. How do I add GLib as a dependency to my C project? Now compare it to adding Tokio as a dependency to my Rust project, which is entirely trivial.
- rightbyte 5y ago
  > How do I add GLib as a dependency to my C project? Use symbol versioning. Anyway, I feel the author is a bit unfair. He traded supporting multiple compilers for Rust's only and it is not really surprising that he felt that the maintainer burden decreased. As soon as Rust gets broad adaption I guess there will be subtly incompatible compiler vendors in Rust too.
  - masklinn 5y ago
    > Use symbol versioning. That doesn't mean anything. > Anyway, I feel the author is a bit unfair. He traded supporting multiple compilers They wanted to support multiple platforms, that multiple platforms implied multiple compilers was part of the portability issues the original goal led to.
    - jcelerier 5y ago
      > They wanted to support multiple platforms, that multiple platforms implied multiple compilers was part of the portability issues the original goal led to. No, people are just inflicting that upon themselves for no good reason. I ship software built with the same clang / libc++ toolchain targetting Mac / Windows / Linux and things works absolutely fine.
      - masklinn 5y ago
        > I ship software Is it an open-source library?
    - rightbyte 5y ago
      > That doesn't mean anything. I meant that you can specify symbol versions to link to glibc specifically. https://sourceware.org/binutils/docs/ld/VERSION.html https://sourceware.org/binutils/docs/ld/VERSION.html > They wanted to support multiple platforms, that multiple platforms implied multiple compilers was part of the portability issues the original goal led to. He could have used gcc on different platforms too. He writes: "the platonic ideal portable C exists only as a hypothetical construct in the C standard. The C that exists in the real world is whatever Microsoft, Apple, and others have shipped. That C is a mess" I.e. his problem could have been solved by sticking to one compiler, be it Rust or Clang ...
lovasoa 5y ago
Let's say that, as you recommend, I only support one compiler and one build system in my C project. What is the "easy" solution to the problem stated by the author ? How do I add multi-threading to my project in a way that allows me to run a function on all available cores in two lines of code, while making the project cross-compile to every major OS and architecture from an M1 mac ? In rust the solution is just to edit a file named "Cargo.toml" and add one line in it: rayon = "*".
- Arch-TK 5y ago
  >rayon = "*". Doesn't this either effectively force you to pin versions to ensure your code doesn't break or require you to constantly re-test your code to ensure there wasn't a breaking change? I don't see how that's a desirable thing. >How do I add multi-threading to my project in a way that allows me to run a function on all available cores in two lines of code The author had to rewrite the project in a different language to add this cross platform multi-threading support. I'm not saying you can do this in two lines of code, the code likely needs some modifications and some considerations, but it's definitely easier to just use one of the multiple cross-platform threading libraries available (or even to write your own) and adapt the code to use it than it is to rewrite a whole project in rust. It's a little bit disingenuous to suggest that in rust any parallel processing task in any project out there can be achieved with 2 lines of code, it's like claiming that OMP can be effectively used by any C codebase with just a 1 line #pragma. If you write your code with the intention of using rayon for your multi-threading tasks then obviously it will not require any modification to make it work with rayon because presumably you had already written your code in a way that makes it usable with rayon. If you write your C code with the intention of using it with your multi-platform threading library of choice then it won't require changes to make it use that library.
  - steveklabnik 5y ago
    > Doesn't this either Cargo pins versions via Cargo.lock for you automatically. It's still not a great idea, (because when you update dependencies it will go to whatever version is the latest, which may not be compatible) and crates.io disallows packages to be uploaded that use this, but it is the easiest built-in way. If you install cargo-edit, you could "cargo add rayon" and it will add it with the latest version specifier instead, which is slightly easier and better but isn't built-in (yet, someday...) > The author had to rewrite the project in a different language to add this cross platform multi-threading support. They're not saying that, they're saying "how do I do what Rayon does for Rust in C?" OpenMP is sorta kinda an answer there, but the post is claiming it's not as good of a solution. "Rewrite it in Rust is easier than using OpenMP" is not what's being said, and you're certainly right that porting to another language entirely is not simple. > If you write your code with the intention of using rayon for your multi-threading tasks then obviously it will not require any modification to make it work with rayon because presumably you had already written your code in a way that makes it usable with rayon. The claim being made is that due to things like the borrow checker, this is often true for Rust code generally, moreso than it is with C and OpenMP. And, in Rust, if it doesn't Just Work, you'll get an error message pointing out exactly why not, whereas (in my understanding, I haven't used OpenMP) that is not going to happen in C.
jcranmer 5y ago
> Thankfully, you don't need to reinvent the wheel, the problem of cross platform multiprocessing in C has been solved at least a dozen times by now. It should be trivial to use one of these many options (or even write your own, even if you don't like the idea of "reinventing the wheel" it's certainly not particularly difficult either and can likely be lighter than any other more general option). This is basically the issue he's complaining about. The author wants to reuse a wheel, but reusing the wheel in C is difficult. What are your options? * OpenMP: Great, now you get the fun of figuring out how to cross-platform(/compiler) enable openmp in your build system (that you have to maintain yourself because there is no standard build system. Of course, you could also go with cmake or autotools to maintain the build system for you, but now you have similar issues with meta-build system stuff. Yay platform diversity!) * Okay, let's use another library instead. Now you just have to have the user tell you where it's located. And maybe have to provide lengthy instructions on how to find it. Or you can try having the build system automatically download it on the fly. There's a lot of potential error messages you have to deal with, just to get at what ought to be a core feature of any modern programming language. * Maybe you might want to vendor that library in your source tree, just to be sure you always have it. Now you get the fun of having your build system invoke another build system as a subproject. * Screw other dependencies, let's just use a newer C standard version, since it is in C11. How do you get your C compiler to compile for C11? Oh wait, that's basically the same world of pain as it is to try to use OpenMP. > Hardly any more dreadful than rust's solution to the problem. Contrast this with Rust's solution. * Your build system is cargo and you specify things primarily with Cargo.toml. This is as little work as the happiest happy paths of C/C++ build systems. And note you don't really choose build system; there is one ecosystem-approved build system--for C/C++, you have at the very least hand-rolled makefiles, IDE solutions, cmake, and autotools as major candidates, and many major projects very happily choose "none of the above" (with all the pain that entails). * If you want to add a dependency in cargo, you add a line in Cargo.toml. That's it; you're done. For the aforementioned C/C++ build systems, even the happiest happy paths aren't that happy. This isn't to say that Rust's solution is perfect (it has a fair amount of warts), but to assert that Rust is no better than C is an indication to me that you've never really had to actually support the build system of a project before.
- Arch-TK 5y ago
maxwell86 5y ago
I've shipped large C projects to dozens of platforms and have encountered all the issues the author mentions and many more. You claim that these issues aren't "real". Even if you are only shipping a project nobody uses to a handful of platforms, you'd have encountered many of them. So IMO the only conclusion I can draw for your comment is that you haven't even done that, and therefore you have no idea what you are talking about. Which is why all your comments in this thread are downvoted. Every single one of them makes your ignorance abundantly clear to everyone in the community.
- Arch-TK 5y ago
  The only conclusion I can draw from what you just wrote is that you've encountered easily fixable issues and rather than try to solve them in a sensible manner you've backed yourself into a corner of solving them in a complicated and difficult way. In my experience in the software industry it's not uncommon for teams of people to persuade themselves that there's no better solution when there does in fact exist a better solution and then to spend an inordinate amount of resources solving a non-problem.

sanxiyn 5y ago

I disagree about dependency management. Let's say, to avoid reinventing the wheel, I decided to use GLib for cross-platform threading. How do I add GLib as a dependency to my C project? Now compare it to adding Tokio as a dependency to my Rust project, which is entirely trivial.

rightbyte 5y ago
> How do I add GLib as a dependency to my C project? Use symbol versioning. Anyway, I feel the author is a bit unfair. He traded supporting multiple compilers for Rust's only and it is not really surprising that he felt that the maintainer burden decreased. As soon as Rust gets broad adaption I guess there will be subtly incompatible compiler vendors in Rust too.
- masklinn 5y ago
  > Use symbol versioning. That doesn't mean anything. > Anyway, I feel the author is a bit unfair. He traded supporting multiple compilers They wanted to support multiple platforms, that multiple platforms implied multiple compilers was part of the portability issues the original goal led to.
  - jcelerier 5y ago
    > They wanted to support multiple platforms, that multiple platforms implied multiple compilers was part of the portability issues the original goal led to. No, people are just inflicting that upon themselves for no good reason. I ship software built with the same clang / libc++ toolchain targetting Mac / Windows / Linux and things works absolutely fine.
    - masklinn 5y ago
      > I ship software Is it an open-source library?
  - rightbyte 5y ago
    > That doesn't mean anything. I meant that you can specify symbol versions to link to glibc specifically. https://sourceware.org/binutils/docs/ld/VERSION.html https://sourceware.org/binutils/docs/ld/VERSION.html > They wanted to support multiple platforms, that multiple platforms implied multiple compilers was part of the portability issues the original goal led to. He could have used gcc on different platforms too. He writes: "the platonic ideal portable C exists only as a hypothetical construct in the C standard. The C that exists in the real world is whatever Microsoft, Apple, and others have shipped. That C is a mess" I.e. his problem could have been solved by sticking to one compiler, be it Rust or Clang ...

lovasoa 5y ago

Let's say that, as you recommend, I only support one compiler and one build system in my C project. What is the "easy" solution to the problem stated by the author ? How do I add multi-threading to my project in a way that allows me to run a function on all available cores in two lines of code, while making the project cross-compile to every major OS and architecture from an M1 mac ? In rust the solution is just to edit a file named "Cargo.toml" and add one line in it: rayon = "*".

Arch-TK 5y ago
>rayon = "*". Doesn't this either effectively force you to pin versions to ensure your code doesn't break or require you to constantly re-test your code to ensure there wasn't a breaking change? I don't see how that's a desirable thing. >How do I add multi-threading to my project in a way that allows me to run a function on all available cores in two lines of code The author had to rewrite the project in a different language to add this cross platform multi-threading support. I'm not saying you can do this in two lines of code, the code likely needs some modifications and some considerations, but it's definitely easier to just use one of the multiple cross-platform threading libraries available (or even to write your own) and adapt the code to use it than it is to rewrite a whole project in rust. It's a little bit disingenuous to suggest that in rust any parallel processing task in any project out there can be achieved with 2 lines of code, it's like claiming that OMP can be effectively used by any C codebase with just a 1 line #pragma. If you write your code with the intention of using rayon for your multi-threading tasks then obviously it will not require any modification to make it work with rayon because presumably you had already written your code in a way that makes it usable with rayon. If you write your C code with the intention of using it with your multi-platform threading library of choice then it won't require changes to make it use that library.
- steveklabnik 5y ago
  > Doesn't this either Cargo pins versions via Cargo.lock for you automatically. It's still not a great idea, (because when you update dependencies it will go to whatever version is the latest, which may not be compatible) and crates.io disallows packages to be uploaded that use this, but it is the easiest built-in way. If you install cargo-edit, you could "cargo add rayon" and it will add it with the latest version specifier instead, which is slightly easier and better but isn't built-in (yet, someday...) > The author had to rewrite the project in a different language to add this cross platform multi-threading support. They're not saying that, they're saying "how do I do what Rayon does for Rust in C?" OpenMP is sorta kinda an answer there, but the post is claiming it's not as good of a solution. "Rewrite it in Rust is easier than using OpenMP" is not what's being said, and you're certainly right that porting to another language entirely is not simple. > If you write your code with the intention of using rayon for your multi-threading tasks then obviously it will not require any modification to make it work with rayon because presumably you had already written your code in a way that makes it usable with rayon. The claim being made is that due to things like the borrow checker, this is often true for Rust code generally, moreso than it is with C and OpenMP. And, in Rust, if it doesn't Just Work, you'll get an error message pointing out exactly why not, whereas (in my understanding, I haven't used OpenMP) that is not going to happen in C.

jcranmer 5y ago

> Thankfully, you don't need to reinvent the wheel, the problem of cross platform multiprocessing in C has been solved at least a dozen times by now. It should be trivial to use one of these many options (or even write your own, even if you don't like the idea of "reinventing the wheel" it's certainly not particularly difficult either and can likely be lighter than any other more general option). This is basically the issue he's complaining about. The author wants to reuse a wheel, but reusing the wheel in C is difficult. What are your options? * OpenMP: Great, now you get the fun of figuring out how to cross-platform(/compiler) enable openmp in your build system (that you have to maintain yourself because there is no standard build system. Of course, you could also go with cmake or autotools to maintain the build system for you, but now you have similar issues with meta-build system stuff. Yay platform diversity!) * Okay, let's use another library instead. Now you just have to have the user tell you where it's located. And maybe have to provide lengthy instructions on how to find it. Or you can try having the build system automatically download it on the fly. There's a lot of potential error messages you have to deal with, just to get at what ought to be a core feature of any modern programming language. * Maybe you might want to vendor that library in your source tree, just to be sure you always have it. Now you get the fun of having your build system invoke another build system as a subproject. * Screw other dependencies, let's just use a newer C standard version, since it is in C11. How do you get your C compiler to compile for C11? Oh wait, that's basically the same world of pain as it is to try to use OpenMP. > Hardly any more dreadful than rust's solution to the problem. Contrast this with Rust's solution. * Your build system is cargo and you specify things primarily with Cargo.toml. This is as little work as the happiest happy paths of C/C++ build systems. And note you don't really choose build system; there is one ecosystem-approved build system--for C/C++, you have at the very least hand-rolled makefiles, IDE solutions, cmake, and autotools as major candidates, and many major projects very happily choose "none of the above" (with all the pain that entails). * If you want to add a dependency in cargo, you add a line in Cargo.toml. That's it; you're done. For the aforementioned C/C++ build systems, even the happiest happy paths aren't that happy. This isn't to say that Rust's solution is perfect (it has a fair amount of warts), but to assert that Rust is no better than C is an indication to me that you've never really had to actually support the build system of a project before.

Arch-TK 5y ago

maxwell86 5y ago

I've shipped large C projects to dozens of platforms and have encountered all the issues the author mentions and many more. You claim that these issues aren't "real". Even if you are only shipping a project nobody uses to a handful of platforms, you'd have encountered many of them. So IMO the only conclusion I can draw for your comment is that you haven't even done that, and therefore you have no idea what you are talking about. Which is why all your comments in this thread are downvoted. Every single one of them makes your ignorance abundantly clear to everyone in the community.

Arch-TK 5y ago
The only conclusion I can draw from what you just wrote is that you've encountered easily fixable issues and rather than try to solve them in a sensible manner you've backed yourself into a corner of solving them in a complicated and difficult way. In my experience in the software industry it's not uncommon for teams of people to persuade themselves that there's no better solution when there does in fact exist a better solution and then to spend an inordinate amount of resources solving a non-problem.