3 ms·

>The question is whether we will end up using their efforts or whether we keep on going back to the same monolith kernels we have been using for the last thirty

>The question is whether we will end up using their efforts or whether we keep on going back to the same monolith kernels we have been using for the last thirty years or so. Whether it is NT, Linux, or any of the BSD kernels, they each have decades of history behind them. Please just... stop. You are using terms that you clearly don't understand the meaning of. What is a "monolith" from your point of view? Because I can tell you that Windows NT is most certainly not a monolithic kernel. Its architecture is very much that of an impure hybrid kernel. You're using the term "monolith" as some sort of buzzword in a realm where that exact term already has a highly specific meaning. >At the same time, we are seeing Rust pop up in a lot of places that used to be the exclusive domain of C. People are already re-implementing libraries, popular command line tools, 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-the-same thing to the older C implementations. For example, ripgrep is neither GNU or POSIX compliant, and therefore it is not a re-implementation. >I could see linux evolve to a point where integrating drivers like that is both possible and common. Once that happens, it will be a hybrid kernel effectively. Hybrid kernels have absolutely nothing to do with the language they are written in beyond the fact that they're written in it. Monolithic, hybrid, microkernels and exokernels are all terms to describe the architecture of a kernel. >So one outcome would be a lot of Rust code running in a wasm sandbox on top of legacy kernels. So then Rust and wasm isn't a part of the kernel is what you're saying.

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.
burntsushi 8y ago
>> At the same time, we are seeing Rust pop up in a lot of places that used to be the exclusive domain of C. People are already re-implementing libraries, popular command line tools, > 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-the-same thing to the older C implementations. For example, ripgrep is neither GNU or POSIX compliant, and therefore it is not a re-implementation. That ripgrep isn't GNU or POSIX compliant is indeed a distinction worth making, but certainly not in this context. You're taking on a very pedantic interpretation of "re-implementation" here that doesn't really matter to the general point. Specifically: > At the same time, we are seeing Rust pop up in a lot of places that used to be the exclusive domain of C. People are already re-implementing libraries, popular command line tools, etc. A lot of these implementations have clear merit in the sense that they are faster, safer to use, easier to scale, maintain, etc. None of this requires any of the "re-implementations" to be 100% strict bug-for-bug compatible tools. This general confusion comes up so often that I have a FAQ item for it: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#posix4ever https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pos...
- paulddraper 8y ago
  > a distinction worth making, but certainly not in this context. It is a worthwhile distinction, because the "re-implementation" talked about is often materially different, to the point that it no longer adheres to what little standardization there is. So realistically we are talking about a new product, or a radical evolution of an existing one. It and everything above it also have to change.
  - burntsushi 8y ago
    I commented because ripgrep was specifically brought up as a counter-example to the notion "At the same time, we are seeing Rust pop up in a lot of places that used to be the exclusive domain of C." What specifically, about ripgrep, removes it from consideration as evidence that Rust programs can operate in the same domain as C? Consider this. If instead of > At the same time, we are seeing Rust pop up in a lot of places that used to be the exclusive domain of C. People are already re-implementing libraries, popular command line tools, etc. A lot of these implementations have clear merit in the sense that they are faster, safer to use, easier to scale, maintain, etc. they wrote > At the same time, we are seeing Rust pop up in a lot of places that used to be the exclusive domain of C. People are already re-implementing popular command line tools, albeit with different interfaces that lack POSIX compatibility. A lot of these implementations have clear merit in the sense that they are faster, safer to use, easier to scale, maintain, etc. Other that the words being more precise for pedants, does the central point of the statement change? No, it doesn't.

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.

burntsushi 8y ago

>> At the same time, we are seeing Rust pop up in a lot of places that used to be the exclusive domain of C. People are already re-implementing libraries, popular command line tools, > 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-the-same thing to the older C implementations. For example, ripgrep is neither GNU or POSIX compliant, and therefore it is not a re-implementation. That ripgrep isn't GNU or POSIX compliant is indeed a distinction worth making, but certainly not in this context. You're taking on a very pedantic interpretation of "re-implementation" here that doesn't really matter to the general point. Specifically: > At the same time, we are seeing Rust pop up in a lot of places that used to be the exclusive domain of C. People are already re-implementing libraries, popular command line tools, etc. A lot of these implementations have clear merit in the sense that they are faster, safer to use, easier to scale, maintain, etc. None of this requires any of the "re-implementations" to be 100% strict bug-for-bug compatible tools. This general confusion comes up so often that I have a FAQ item for it: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#posix4ever https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pos...

paulddraper 8y ago
> a distinction worth making, but certainly not in this context. It is a worthwhile distinction, because the "re-implementation" talked about is often materially different, to the point that it no longer adheres to what little standardization there is. So realistically we are talking about a new product, or a radical evolution of an existing one. It and everything above it also have to change.
- burntsushi 8y ago
  I commented because ripgrep was specifically brought up as a counter-example to the notion "At the same time, we are seeing Rust pop up in a lot of places that used to be the exclusive domain of C." What specifically, about ripgrep, removes it from consideration as evidence that Rust programs can operate in the same domain as C? Consider this. If instead of > At the same time, we are seeing Rust pop up in a lot of places that used to be the exclusive domain of C. People are already re-implementing libraries, popular command line tools, etc. A lot of these implementations have clear merit in the sense that they are faster, safer to use, easier to scale, maintain, etc. they wrote > At the same time, we are seeing Rust pop up in a lot of places that used to be the exclusive domain of C. People are already re-implementing popular command line tools, albeit with different interfaces that lack POSIX compatibility. A lot of these implementations have clear merit in the sense that they are faster, safer to use, easier to scale, maintain, etc. Other that the words being more precise for pedants, does the central point of the statement change? No, it doesn't.