5 ms·
> 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 th
by 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 agoMemory 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 agoWhile those C++ efforts are admirable, and good, they’re only setting out to do a subset of what Rust can do.
- ncmncm 7y agoAnd 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 agoThere’s no need to be so aggressive.
- ncmncm 7y agoBy "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.
- steveklabnik 7y ago> By "aggressive", you mean explaining the point in detail? No, I mean the stuff dang has already commented on. You also did not explain the point in detail, you responded to what I said with a whole bunch of off-topic things, and then insinuated that I did not have the point. The parent said that C++ would have "memory safety mechanisms similar to Rust," and my point was that while they are similar in some ways, they are not as comprehensive. That's an important distinction! All of this other stuff you're talking about has nothing to do with that.
- ncmncm 7y agoWhat I see is special pleading. C++ inherits flaws from C, Rust has flaws from its late start and weaker emphasis on expressibility, both sets of flaws interfere with reliable use.
- dang 7y agoPlease edit swipes like "Did you have a point?" out of your comments here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- marcosdumay 7y agoOh, boy. Don't go there. No amount of testing and bug-fixing solves badly created software. Systemd is begging for a rewrite. Now, I don't know if this one will be complete enough to replace the original. But yours is not a promising argument.
- dnautics 7y agoName one problem you personally have encountered deploying systemd in production.
- marcosdumay 7y agoThe launching order of the internal daemons is not explicit on the services graph. For a long while I had a computer that mounted the disks on a non-predictable time and most attempts to fsck the root partition would fail. For a while it would ignore the system DNS settings, so it didn't only require it to be configured twice, but the systemd settings had an habit of changing in format every so often. Udev failed a bit at the time it was being included on the package. Oh, there was the time when the simple service launcher didn't conform to the documentation so a lot of daemons could fail to launch in unpredictable ways. But the first I started using it was at the Debian migration. So the earlier bugs were all solved already.
- johnr2 7y ago> systemd, core system in many Linux distributions, written in C++ s/C++/C
- adev_ 7y agoYep, systemd is in plain old C....I wish it would be in C++.... Most of the security vulnerabilities reported (https://www.cvedetails.com/product/38088/Freedesktop-Systemd.html?vendor_id=7971 https://www.cvedetails.com/product/38088/Freedesktop-Systemd...) would not have existed in modern C++. Including all the heavy ones implying stack smash due to VLA buffers that do not exist in C++. Many will hate me for that, but preferring old-C over C++ for a system software after 2011 is a non-sense. Even the maintainers of GCC understood that.
- JdeBP 7y agoIndeed. It is other programs that are written in C++. (-: * http://jdebp.uk./Softwares/nosh/ http://jdebp.uk./Softwares/nosh/