4 ms·

I agree and I disagree. The ROI on improving widely used tools is quite large Yes indeed. You probably wanted to say: The ROI on reinventing widely used tools

I agree and I disagree. The ROI on improving widely used tools is quite large Yes indeed. You probably wanted to say: The ROI on reinventing widely used tools is quite large" There are some extremely used binaries that have a stagnant development and have not adapted to modern ergonomics. I beautiful example of that subset of widely used tools is cat. Cat is extremely used and yet, the rust rewrite bat is far superior, because among other things, it has color and code higlithing :0 For a rust rewrite to be successful you need the following conditions: You have ideas of improvments not present in the current tool. Your ideas are not on their roadmap. The current tool has not had too much of man/hours, which you can interpret heuristically as: the current tool has less than a few thousands of commits. Here we're talking about systemd which has 42,600 commits. By the time rustysd will have as much features as current* systemd, the original developer will be dead. As an end user I have almost zero benefits in this kind of rewrites, as I'm aware it's a far poorer software by design. If it was 1) a new kind of software or 2) a reimplementation of a tool that they can realistically manage to outcompete or 3) the development that will in the very longterm replace an old complex tool that has stopped development, then I would have been interested. Anyway if it's for fun/learning purpose, they do what they want, but utilitaristically there would be better choices.

Drdrdrq 7y ago
> For a rust rewrite to be successful you need the following conditions: You have ideas of improvments not present in the current tool. Your ideas are not on their roadmap. The current tool has not had too much of man/hours, which you can interpret heuristically as: the current tool has less than a few thousands of commits. I think you are missing the point completely. We are talking about rust, memory safe performant language, and systemd, core system in many Linux distributions, written in C++. I would love to be able to replace systemd (and kernel and core libraries too) with something that was safer at least in this aspect (memory safety). Big kudos to Mozilla for identifying the cause of many security bugs and for finding a way to solve it while keeping performance intact.
- The_rationalist 7y ago
  Memory bugs are only one kind of bugs. Even if stability where our only metric, systemd had more testing and bugfixing than a rust alternative would ever have. Thus even if the rust one would be free of most memory bugs, the testing made on systemd would outweigh by far this advantage. BTW by the time of the rewrite, c++ will have memory safety mechanisms similar to rust: https://news.ycombinator.com/item?id=18037566 https://news.ycombinator.com/item?id=18037566
  - steveklabnik 7y ago
    While those C++ efforts are admirable, and good, they’re only setting out to do a subset of what Rust can do.
    - ncmncm 7y ago
      And Rust is only setting out to do a subset of what C++ can do. Did you have a point? In particular, C++ has been engineered from the beginning to create expressive, powerful libraries, much moreso than Rust. The gap today is bigger than it was five years ago. This matters because every use of an idiomatic, powerful, mature library replaces code not using it that would have had bugs. Yes, Rust programs do have bugs. Powerful is important in libraries because it translates to actually usable where you need it, without compromise. Any library you can't or don't use does you and your users no good. Code that uses a good library will have none of the problematic, buggy constructs that Rust is supposed to protect you from.
      - steveklabnik 7y ago
        There’s no need to be so aggressive.
        ncmncm 7y ago
        By "aggressive", you mean explaining the point in detail? Rust and C++ have different emphases. C++ has a huge head start, but also massive backward-compatibility anchors. It is certain that, over time, Rust will get better at expressing powerful libraries, but C++ is not sitting still. It is very far from clear whether Rust will be important, ten years from now. It is far from clear that it is more beneficial to put resources into rewriting C things from scratch in Rust than to transition existing development from C to C++, and start replacing subsystems in-place. What is clear is that the difference in benefit to starting any new project in Rust or in C++ is absolutely overwhelmed by the absolute benefit of starting in one of those, and not C.

Drdrdrq 7y ago

> For a rust rewrite to be successful you need the following conditions: You have ideas of improvments not present in the current tool. Your ideas are not on their roadmap. The current tool has not had too much of man/hours, which you can interpret heuristically as: the current tool has less than a few thousands of commits. I think you are missing the point completely. We are talking about rust, memory safe performant language, and systemd, core system in many Linux distributions, written in C++. I would love to be able to replace systemd (and kernel and core libraries too) with something that was safer at least in this aspect (memory safety). Big kudos to Mozilla for identifying the cause of many security bugs and for finding a way to solve it while keeping performance intact.

The_rationalist 7y ago
Memory bugs are only one kind of bugs. Even if stability where our only metric, systemd had more testing and bugfixing than a rust alternative would ever have. Thus even if the rust one would be free of most memory bugs, the testing made on systemd would outweigh by far this advantage. BTW by the time of the rewrite, c++ will have memory safety mechanisms similar to rust: https://news.ycombinator.com/item?id=18037566 https://news.ycombinator.com/item?id=18037566
- steveklabnik 7y ago
  While those C++ efforts are admirable, and good, they’re only setting out to do a subset of what Rust can do.
  - ncmncm 7y ago
    And Rust is only setting out to do a subset of what C++ can do. Did you have a point? In particular, C++ has been engineered from the beginning to create expressive, powerful libraries, much moreso than Rust. The gap today is bigger than it was five years ago. This matters because every use of an idiomatic, powerful, mature library replaces code not using it that would have had bugs. Yes, Rust programs do have bugs. Powerful is important in libraries because it translates to actually usable where you need it, without compromise. Any library you can't or don't use does you and your users no good. Code that uses a good library will have none of the problematic, buggy constructs that Rust is supposed to protect you from.
    - steveklabnik 7y ago
      There’s no need to be so aggressive.
      - ncmncm 7y ago
        By "aggressive", you mean explaining the point in detail? Rust and C++ have different emphases. C++ has a huge head start, but also massive backward-compatibility anchors. It is certain that, over time, Rust will get better at expressing powerful libraries, but C++ is not sitting still. It is very far from clear whether Rust will be important, ten years from now. It is far from clear that it is more beneficial to put resources into rewriting C things from scratch in Rust than to transition existing development from C to C++, and start replacing subsystems in-place. What is clear is that the difference in benefit to starting any new project in Rust or in C++ is absolutely overwhelmed by the absolute benefit of starting in one of those, and not C.