5 ms·

> Yes, but some (e.g. ripgrep) don't actually do the same thing as the programs they are supposed to "re-implement". Most Rust "re-implementations" don't actual

by spuz 8y ago

> Yes, but some (e.g. ripgrep) don't actually do the same thing as the programs they are supposed to "re-implement". Most Rust "re-implementations" don't actually re-implement programs, they are new programs doing a similar-but-not-quite thing to the older C implementations. For example, ripgrep is neither GNU or POSIX compliant, and therefore it is not a re-implementation. Is there a reason that command line tools cannot be re-implemented in Rust and maintain GNU and POSIX compliance? If not then the fact that ripgrep is not compliant is irrelevant to the larger point that Rust command line tools could eventually replace existing C command line tools.

nicoburns 8y ago
I think it's more that part od the attraction of rewriting the software is being able to upfate and improve the interface. If you want the old interface then the existing tools are usually perfecrly good.
gammagoblin 8y ago
>Is there a reason that command line tools cannot be re-implemented in Rust and maintain GNU and POSIX compliance? No, there isn't, but what "re-implementations" that I know of don't even try to do that. >If not then the fact that ripgrep is not compliant is irrelevant to the larger point that Rust command line tools could eventually replace existing C command line tools. Of course it's possible. You can go ahead and re-implement them in BASIC even. The point is that it hasn't been done, and until it has been done then such a replacement will not happen. At that point there are further considerations. The C linker is ubiquitous, and remains a strong, underlying presence even on Windows, the one platform where C stands the weakest. The reason that the C linker is so widespread is that while C has no standard ABI, the platforms have very strongly defined ABIs (e.g. systemv abi), and those ABIs are extremely stable and haven't had a single change in over a decade. Those ABIs are also very, very simple and the result is that writing any type of software towards a C library in any language is dead simple. C++ at least has extern "C" going for it, which disables name mangling. Rust doesn't have that, nor does it have a stable ABI. C/C++ are the two most interoperable language out there, with an extremely mature and reliable toolchain. It's simply not justifiable to replace C/C++ with Rust as a systems programming language until this serious problem is fixed. Then furthermore, a vast amount of effort has been put into these tools over the last years to ensure that they run on any *nix and any architecture, and even so they can be ported with relative ease. For example, how do you suggest implementing glibc in Rust? You might argue "why would we need the C standard library when we're porting things to Rust", and the answer is that if you want to make a move towards rust, having a C library (particularly the GNU one, a lot of software depends on GNU extensions) is of utmost importance until that goal has been achieved.
- throwaway_se099 8y ago
  > C++ at least has extern "C" going for it, which disables name mangling. Rust doesn't have that It does, it's called "#[no_mangle]", and together with an extern "C" fn declaration you get a non-mangled function directly callable from C.
  - gammagoblin 8y ago
    I see, I admittedly didn't know that. Thanks.
- fredmorcos 8y ago
  I don't want to be defending Rust but your post has so many misconceptions. May I ask where you got all that information and what your background is? > C++ at least has extern "C" going for it, which disables name mangling. Rust doesn't have that, nor does it have a stable ABI. Rust has #[no_mangle] and extern "C" and those two guarantee that ABI stability you're looking for. > Then furthermore, a vast amount of effort has been put into these tools over the last years to ensure that they run on any *nix and any architecture, and even so they can be ported with relative ease. That's actually a breeze in Rust, including cross-compilation (which is relatively painful in C/C++). > For example, how do you suggest implementing glibc in Rust? You might argue "why would we need the C standard library when we're porting things to Rust", and the answer is that if you want to make a move towards rust, having a C library (particularly the GNU one, a lot of software depends on GNU extensions) is of utmost importance until that goal has been achieved. There's work towards that: https://gitlab.redox-os.org/redox-os/relibc https://gitlab.redox-os.org/redox-os/relibc
  - gammagoblin 8y ago
    >I don't want to be defending Rust but your post has so many misconceptions. May I ask where you got all that information and what your background is? I am primarily a systems programmer and write software for the petroleum industry in my country. I work with C++ and in some (rare) cases C, and I've been doing that for the past 4 years. I have my own WIP hobby unix-like microkernel project written in C as well. >Rust has #[no_mangle] and extern "C" and those two guarantee that ABI stability you're looking for. I admittedly did not know this before it was pointed out to me. >That's actually a breeze in Rust, including cross-compilation (which is relatively painful in C/C++). It really isn't. Have you looked at rustc's compiler targets? It's not a very long list. Support is improving, but there's still a lot of key areas that are completely missing. To my knowledge it supports x86, ARM, MIPS and POWER. That's not a long list. >There's work towards that: https://gitlab.redox-os.org/redox-os/relibc https://gitlab.redox-os.org/redox-os/relibc That's good, and is genuinely what's necessary to put Rust in key components.

by spuz 8y ago

nicoburns 8y ago

I think it's more that part od the attraction of rewriting the software is being able to upfate and improve the interface. If you want the old interface then the existing tools are usually perfecrly good.

gammagoblin 8y ago

>Is there a reason that command line tools cannot be re-implemented in Rust and maintain GNU and POSIX compliance? No, there isn't, but what "re-implementations" that I know of don't even try to do that. >If not then the fact that ripgrep is not compliant is irrelevant to the larger point that Rust command line tools could eventually replace existing C command line tools. Of course it's possible. You can go ahead and re-implement them in BASIC even. The point is that it hasn't been done, and until it has been done then such a replacement will not happen. At that point there are further considerations. The C linker is ubiquitous, and remains a strong, underlying presence even on Windows, the one platform where C stands the weakest. The reason that the C linker is so widespread is that while C has no standard ABI, the platforms have very strongly defined ABIs (e.g. systemv abi), and those ABIs are extremely stable and haven't had a single change in over a decade. Those ABIs are also very, very simple and the result is that writing any type of software towards a C library in any language is dead simple. C++ at least has extern "C" going for it, which disables name mangling. Rust doesn't have that, nor does it have a stable ABI. C/C++ are the two most interoperable language out there, with an extremely mature and reliable toolchain. It's simply not justifiable to replace C/C++ with Rust as a systems programming language until this serious problem is fixed. Then furthermore, a vast amount of effort has been put into these tools over the last years to ensure that they run on any *nix and any architecture, and even so they can be ported with relative ease. For example, how do you suggest implementing glibc in Rust? You might argue "why would we need the C standard library when we're porting things to Rust", and the answer is that if you want to make a move towards rust, having a C library (particularly the GNU one, a lot of software depends on GNU extensions) is of utmost importance until that goal has been achieved.

throwaway_se099 8y ago
> C++ at least has extern "C" going for it, which disables name mangling. Rust doesn't have that It does, it's called "#[no_mangle]", and together with an extern "C" fn declaration you get a non-mangled function directly callable from C.
- gammagoblin 8y ago
  I see, I admittedly didn't know that. Thanks.
fredmorcos 8y ago
I don't want to be defending Rust but your post has so many misconceptions. May I ask where you got all that information and what your background is? > C++ at least has extern "C" going for it, which disables name mangling. Rust doesn't have that, nor does it have a stable ABI. Rust has #[no_mangle] and extern "C" and those two guarantee that ABI stability you're looking for. > Then furthermore, a vast amount of effort has been put into these tools over the last years to ensure that they run on any *nix and any architecture, and even so they can be ported with relative ease. That's actually a breeze in Rust, including cross-compilation (which is relatively painful in C/C++). > For example, how do you suggest implementing glibc in Rust? You might argue "why would we need the C standard library when we're porting things to Rust", and the answer is that if you want to make a move towards rust, having a C library (particularly the GNU one, a lot of software depends on GNU extensions) is of utmost importance until that goal has been achieved. There's work towards that: https://gitlab.redox-os.org/redox-os/relibc https://gitlab.redox-os.org/redox-os/relibc
- gammagoblin 8y ago
  >I don't want to be defending Rust but your post has so many misconceptions. May I ask where you got all that information and what your background is? I am primarily a systems programmer and write software for the petroleum industry in my country. I work with C++ and in some (rare) cases C, and I've been doing that for the past 4 years. I have my own WIP hobby unix-like microkernel project written in C as well. >Rust has #[no_mangle] and extern "C" and those two guarantee that ABI stability you're looking for. I admittedly did not know this before it was pointed out to me. >That's actually a breeze in Rust, including cross-compilation (which is relatively painful in C/C++). It really isn't. Have you looked at rustc's compiler targets? It's not a very long list. Support is improving, but there's still a lot of key areas that are completely missing. To my knowledge it supports x86, ARM, MIPS and POWER. That's not a long list. >There's work towards that: https://gitlab.redox-os.org/redox-os/relibc https://gitlab.redox-os.org/redox-os/relibc That's good, and is genuinely what's necessary to put Rust in key components.