6 ms·

As a meta comment, I really like how active Stepha(e?)n is on internet forums. And the energy around Rust is pretty intense. I feel like in there, people are u

As a meta comment, I really like how active Stepha(e?)n is on internet forums. And the energy around Rust is pretty intense. I feel like in there, people are unwilling to try to embrace some of the nuance in the arguments that some people make against Rust. A person should understand that no language(programming or otherwise) is perfect. Therefore there is some criticism of any language that is valid. Therefore some criticism should be taken seriously as there may be a real point to the criticism. There are many posts like this, where there are comparisons of Rust to C. Realistically they are all a little biased towards Rust as Rust is a C++ replacement really. A more proper comparison would be Zig or D as a better C against C. Just understand that a person defending C is not always an idiot, and maybe they have point. Consider the excessive memory use of any working Rust compiler. That will probably not be remedied anytime soon and is a legitimate complaint. The ideal of how something could be is not how something is. The reality is that C works pretty well most of the time, Rust works well most of the time. They both fail at some things.

vvanders 8y ago
I don't think I've seen anyone claiming that Rust is a perfect language without flaws. Heck I'd hold up all of the huge strides that have been made in errors, usability and constant feedback as a counter example of that. You see a lot of people holding up Rust precisely because we've been there for the last 5/10/15/20 years. The day I don't have to write a makefile or build yet another CMakeLists.txt is the day I rejoice. What Rust offers is another option in the native, non-GC'd language space. A space that has very few languages and even fewer yet that are shipped at scale. Rusts inclusion w/ FF means that the have to address the robustness, security, performance and usability of the language to a degree that you don't commonly see. Having just blown 4+ hours today dealing with the linker on a mixed C/C++ project I don't really miss a lot of the baggage that comes with native development these days. Rust gives you the option of dropping down to that level while still preserving a set of sane, opinionated defaults that are pretty well thought out.
- kxyvr 8y ago
  Since you made a mention of CMake, does Rust really provide an alternative for building multilanguage projects? When I went to look for examples on how this is managed, it seemed horrendous. For example, some projects manage this by writing a program to download, unzip, and build the source: https://github.com/elrnv/ipopt-rs/blob/master/ipopt-sys/build.rs https://github.com/elrnv/ipopt-rs/blob/master/ipopt-sys/buil... Others just assume that the libraries are there, but they still require a program to compile them: https://github.com/cmr/openblas-src/blob/master/build.rs https://github.com/cmr/openblas-src/blob/master/build.rs As long as all of the dependencies are in Rust, things appear nice. At the same time, unless I'm missing something, it seems like crates manages multilanguage projects poorly. Though I have some major gripes with CMake, I've managed multilanguage projects mostly well. Is there a sane way outside of CMake to manage a multilanguage project with Rust?
  - OtterCoder 8y ago
    Not so much with Rust in the driver's seat. Cargo, Rust's primary toolchain, only has weak support for pre/post build scripts. It's solely concerned with Rust's own dependencies and compilation. In the couple of projects where I've added Rust to a larger project, it's always been bash or node that coordinates the overall build.
    - oever 8y ago
      You can call a compiler for C/C++ from build.rs. That tooling is currently not very advanced. As far as I know there is no crate to write compile recipes that as easily as a Makefile or CMakeLists.txt. When I tried this in build.rs, I had to check modification times myself. There is an opening for a ninja-type crate in Rust.
  - blakesmith 8y ago
    Check out Bazel: http://bazel.build http://bazel.build. I've been using it a lot to build several multi lingual projects that include Java, C++, embedded C, Javascript, CSS, and even Docker images. There are community Rust rules, that I haven't tried yet, but am planning on investigating soon: https://github.com/bazelbuild/rules_rust https://github.com/bazelbuild/rules_rust
- AceJohnny2 8y ago
  Indeed. Rust is the only new contender in the field of systems programming, where C++ has to contend with decades of negative mindshare (C++11: "I've changed! I promise!"), and D, well, never really took off (because it started off in the early Internet era as a commercial compiler?).
  - lasagnaphil 8y ago
    There is also Zig, which seems nice as a C replacement but still highly unstable, and Jai, which is also a nice C replacement but currently has no publicly available compiler yet... So for the time Rust is the only new systems programming language (And please don’t say Go/Nim is a contender, they’re good languages in their own ways but having a garbage collector disqualifies it fron that categorization)
    - geezerjay 8y ago
      > Jai, which is also a nice C replacement but currently has no publicly available compiler yet... If there is no compiler then there is no programming language.
      - timClicks 8y ago
        Well, there are videos of code being compiled. But nothing verifiable outside of the Jai team.
        majewsky 8y ago
        If that counts as existing, then cold fusion exists.
        potiuper 8y ago
        Of course https://en.wikipedia.org/wiki/ColdFusion https://en.wikipedia.org/wiki/ColdFusion exists.
        8y ago
- vmchale 8y ago
  > You see a lot of people holding up Rust precisely because we've been there for the last 5/10/15/20 years. The day I don't have to write a makefile or build yet another CMakeLists.txt is the day I rejoice. Ironically, cargo is one of the areas the rust ecosystem falls down completely. Not to mention, there's no ABI... > What Rust offers is another option in the native, non-GC'd language space. True, and while this is great in principle for embedded development, not using a GC is overrated. > Rust gives you the option of dropping down to that level Well, if you're not dealing with the linker, you're not at "that level"
gnulinux 8y ago
Very strongly disagree that Rust is a C++ replacement and D is a C replacement. If anything, it's the exact opposite, Rust is a C replacement and D is a C++ replacement. If you tracked communities so far, you'd see that Rust community is very sensitive on the issue of memory print, performance impact and asm implicitness of Rust. There is already a huge osdev community built around Rust, I know kernels written in Rust. Rust is the perfect language to reliably write drivers, embedded systems or system tools. I cannot think of a language semantically closer to C than Rust. Not even C++ is there. Rust is literally just C with a good type system, and that's what makes it so awesome.
- vmchale 8y ago
  > I cannot think of a language semantically closer to C than Rust. Not even C++ is there. Rust is literally just C with a good type system, and that's what makes it so awesome. ATS is far closer and indeed compiles to C. Rust's type system is still less expressive than that of ATS.
  - hcs 8y ago
    Never heard of it, link?
    - zeptomu 8y ago
      "Applied Type System" - a language built for correct low-level programming inspired by functional programming and theorem proving. http://lmgtfy.com/?q=ats+language http://lmgtfy.com/?q=ats+language If I remember correctly there were plans to implement GNU Hurd (the Half-Life 3 of kernels) in ATS, but that probably went nowhere. But there is a small osdev community messing with kernels and ATS.
- jcelerier 8y ago
  > Rust is a C replacement well, which language of C and C++ has the possibility of having traits, structs with function definitions, generics which work through monomorphism, variants, optional, reference-counted pointer and pointer ownership semantics ? > If you tracked communities so far, you'd see that Rust community is very sensitive on the issue of memory print, performance impact and asm implicitness of Rust. yeah... like C++ ?
blub 8y ago
Actually Rust is clearly both a C and C++ replacement, but C programmers tend to become quite fanatical and for some inexplicable reason C also has a quite decent reputation, so the Rust community is focusing their efforts on the much more controversial C++ instead of attacking the holy cow of C. I think they've also figured out that with time C will be squeezed into smaller and smaller areas of use, as is already happening. Writing robust code hasn't really found a space to live in the mental model of C programmers. Using C outside a kernel or existing C project today is professional negligence.
- vmchale 8y ago
  > some inexplicable reason C also has a quite decent reputation if you think like this, you will never replace C... > Using C outside a kernel or existing C project today is professional negligence. or embedded development lol
  - blub 8y ago
    C has been in the process of being replaced for decades. I specifically mentioned kernels and legacy projects, because these are its last retreats; even embedded has lost a large chunk to C++. Here's a silly prediction: in the next 10 years a significant number of C programmers will retire without replacement. The new generations will rather learn Go, C++ and Rust for low-level stuff and will banish C to pure legacy projects.
    - pjmlp 8y ago
      Fully agree with you. Although not politically correct, that is the only way to overcome religious resistance against new technologies.
    - creatornator 8y ago
      I disagree about replacement programmers--at the moment, practically every graduating electrical engineer and computer engineer will have a working knowledge of C. Embedded C has lost some ground to C++, but primarily in ARM and x86 architectures, since for more memory constrained AVR/PIC/etc. microcontrollers, you absolutely avoid template inheritance because vtables are untenable, there often isn't an available STL for the chip toolchain anyways, templates balloon the program space, and you are still constrained to using just stack allocation. That right there pretty much means there will always be a space where C is more pragmatic. I see this pattern a lot on HN. Many aren't aware that there are fields alive and well that require the use of unsafe, deterministic C that can compile to programs on the order of kb.

vvanders 8y ago

I don't think I've seen anyone claiming that Rust is a perfect language without flaws. Heck I'd hold up all of the huge strides that have been made in errors, usability and constant feedback as a counter example of that. You see a lot of people holding up Rust precisely because we've been there for the last 5/10/15/20 years. The day I don't have to write a makefile or build yet another CMakeLists.txt is the day I rejoice. What Rust offers is another option in the native, non-GC'd language space. A space that has very few languages and even fewer yet that are shipped at scale. Rusts inclusion w/ FF means that the have to address the robustness, security, performance and usability of the language to a degree that you don't commonly see. Having just blown 4+ hours today dealing with the linker on a mixed C/C++ project I don't really miss a lot of the baggage that comes with native development these days. Rust gives you the option of dropping down to that level while still preserving a set of sane, opinionated defaults that are pretty well thought out.

kxyvr 8y ago
Since you made a mention of CMake, does Rust really provide an alternative for building multilanguage projects? When I went to look for examples on how this is managed, it seemed horrendous. For example, some projects manage this by writing a program to download, unzip, and build the source: https://github.com/elrnv/ipopt-rs/blob/master/ipopt-sys/build.rs https://github.com/elrnv/ipopt-rs/blob/master/ipopt-sys/buil... Others just assume that the libraries are there, but they still require a program to compile them: https://github.com/cmr/openblas-src/blob/master/build.rs https://github.com/cmr/openblas-src/blob/master/build.rs As long as all of the dependencies are in Rust, things appear nice. At the same time, unless I'm missing something, it seems like crates manages multilanguage projects poorly. Though I have some major gripes with CMake, I've managed multilanguage projects mostly well. Is there a sane way outside of CMake to manage a multilanguage project with Rust?
- OtterCoder 8y ago
  Not so much with Rust in the driver's seat. Cargo, Rust's primary toolchain, only has weak support for pre/post build scripts. It's solely concerned with Rust's own dependencies and compilation. In the couple of projects where I've added Rust to a larger project, it's always been bash or node that coordinates the overall build.
  - oever 8y ago
    You can call a compiler for C/C++ from build.rs. That tooling is currently not very advanced. As far as I know there is no crate to write compile recipes that as easily as a Makefile or CMakeLists.txt. When I tried this in build.rs, I had to check modification times myself. There is an opening for a ninja-type crate in Rust.
- blakesmith 8y ago
  Check out Bazel: http://bazel.build http://bazel.build. I've been using it a lot to build several multi lingual projects that include Java, C++, embedded C, Javascript, CSS, and even Docker images. There are community Rust rules, that I haven't tried yet, but am planning on investigating soon: https://github.com/bazelbuild/rules_rust https://github.com/bazelbuild/rules_rust
AceJohnny2 8y ago
Indeed. Rust is the only new contender in the field of systems programming, where C++ has to contend with decades of negative mindshare (C++11: "I've changed! I promise!"), and D, well, never really took off (because it started off in the early Internet era as a commercial compiler?).
- lasagnaphil 8y ago
  There is also Zig, which seems nice as a C replacement but still highly unstable, and Jai, which is also a nice C replacement but currently has no publicly available compiler yet... So for the time Rust is the only new systems programming language (And please don’t say Go/Nim is a contender, they’re good languages in their own ways but having a garbage collector disqualifies it fron that categorization)
  - geezerjay 8y ago
    > Jai, which is also a nice C replacement but currently has no publicly available compiler yet... If there is no compiler then there is no programming language.
    - timClicks 8y ago
      Well, there are videos of code being compiled. But nothing verifiable outside of the Jai team.
      - majewsky 8y ago
        If that counts as existing, then cold fusion exists.
        potiuper 8y ago
        Of course https://en.wikipedia.org/wiki/ColdFusion https://en.wikipedia.org/wiki/ColdFusion exists.
      - 8y ago
vmchale 8y ago
> You see a lot of people holding up Rust precisely because we've been there for the last 5/10/15/20 years. The day I don't have to write a makefile or build yet another CMakeLists.txt is the day I rejoice. Ironically, cargo is one of the areas the rust ecosystem falls down completely. Not to mention, there's no ABI... > What Rust offers is another option in the native, non-GC'd language space. True, and while this is great in principle for embedded development, not using a GC is overrated. > Rust gives you the option of dropping down to that level Well, if you're not dealing with the linker, you're not at "that level"

gnulinux 8y ago

Very strongly disagree that Rust is a C++ replacement and D is a C replacement. If anything, it's the exact opposite, Rust is a C replacement and D is a C++ replacement. If you tracked communities so far, you'd see that Rust community is very sensitive on the issue of memory print, performance impact and asm implicitness of Rust. There is already a huge osdev community built around Rust, I know kernels written in Rust. Rust is the perfect language to reliably write drivers, embedded systems or system tools. I cannot think of a language semantically closer to C than Rust. Not even C++ is there. Rust is literally just C with a good type system, and that's what makes it so awesome.

vmchale 8y ago
> I cannot think of a language semantically closer to C than Rust. Not even C++ is there. Rust is literally just C with a good type system, and that's what makes it so awesome. ATS is far closer and indeed compiles to C. Rust's type system is still less expressive than that of ATS.
- hcs 8y ago
  Never heard of it, link?
  - zeptomu 8y ago
    "Applied Type System" - a language built for correct low-level programming inspired by functional programming and theorem proving. http://lmgtfy.com/?q=ats+language http://lmgtfy.com/?q=ats+language If I remember correctly there were plans to implement GNU Hurd (the Half-Life 3 of kernels) in ATS, but that probably went nowhere. But there is a small osdev community messing with kernels and ATS.
jcelerier 8y ago
> Rust is a C replacement well, which language of C and C++ has the possibility of having traits, structs with function definitions, generics which work through monomorphism, variants, optional, reference-counted pointer and pointer ownership semantics ? > If you tracked communities so far, you'd see that Rust community is very sensitive on the issue of memory print, performance impact and asm implicitness of Rust. yeah... like C++ ?

blub 8y ago

Actually Rust is clearly both a C and C++ replacement, but C programmers tend to become quite fanatical and for some inexplicable reason C also has a quite decent reputation, so the Rust community is focusing their efforts on the much more controversial C++ instead of attacking the holy cow of C. I think they've also figured out that with time C will be squeezed into smaller and smaller areas of use, as is already happening. Writing robust code hasn't really found a space to live in the mental model of C programmers. Using C outside a kernel or existing C project today is professional negligence.

vmchale 8y ago
> some inexplicable reason C also has a quite decent reputation if you think like this, you will never replace C... > Using C outside a kernel or existing C project today is professional negligence. or embedded development lol
- blub 8y ago
  C has been in the process of being replaced for decades. I specifically mentioned kernels and legacy projects, because these are its last retreats; even embedded has lost a large chunk to C++. Here's a silly prediction: in the next 10 years a significant number of C programmers will retire without replacement. The new generations will rather learn Go, C++ and Rust for low-level stuff and will banish C to pure legacy projects.
  - pjmlp 8y ago
    Fully agree with you. Although not politically correct, that is the only way to overcome religious resistance against new technologies.
  - creatornator 8y ago
    I disagree about replacement programmers--at the moment, practically every graduating electrical engineer and computer engineer will have a working knowledge of C. Embedded C has lost some ground to C++, but primarily in ARM and x86 architectures, since for more memory constrained AVR/PIC/etc. microcontrollers, you absolutely avoid template inheritance because vtables are untenable, there often isn't an available STL for the chip toolchain anyways, templates balloon the program space, and you are still constrained to using just stack allocation. That right there pretty much means there will always be a space where C is more pragmatic. I see this pattern a lot on HN. Many aren't aware that there are fields alive and well that require the use of unsafe, deterministic C that can compile to programs on the order of kb.