8 ms·

In fact, Sutter (et al) are working on lifetimes in CppCoreGuidelines [1]. I built their clang tree and tried it out without bothering to RTFM and tried out th

In fact, Sutter (et al) are working on lifetimes in CppCoreGuidelines [1]. I built their clang tree and tried it out without bothering to RTFM and tried out the warning on a pile of C++ code. I naively assumed that it might be a generally-useful warning ("-Wlifetime") that's not ready to be introduced upstream. That's not the case AFAICT. What I suppose I would've learned from RTFM is that the profile specified by the guidelines is sorta like an opt-in 'dialect' to annotate/specify lifetime information. Without it, there's lots of spurious findings. Either that, or the codebase I tried it on isn't as good as I thought it was. Here's a couple of interesting examples of failure modes -Wlifetime can detect on godbolt[2][3]. I watched a video [5] a while back on the Guidelines Support Library (GSL) [4] and it seemed like a really interesting concept. I think it's a valuable idea and I'd love to see popular C++ projects leveraging it. I'm a card-carrying RESF member† (but have a day job w/mostly C++). Don't RIIR for one thing, RIIR to get all the things. Cargo is the sleeper hit of Rust. Hygienic macros and more! [1] https://github.com/isocpp/CppCoreGuidelines/blob/master/docs/Lifetime.pdf https://github.com/isocpp/CppCoreGuidelines/blob/master/docs... [2] https://godbolt.org/z/dymV_C https://godbolt.org/z/dymV_C [3] https://godbolt.org/z/_midIP https://godbolt.org/z/_midIP [4] http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#S-gsl http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#... [5] CppCon 2017: Kate Gregory “10 Core Guidelines You Need to Start Using Now” https://www.youtube.com/watch?v=XkDEzfpdcSg https://www.youtube.com/watch?v=XkDEzfpdcSg † Rust Evangelism Strike Force -- maybe we really should have cards

matthewbauer 7y ago
Rewriting stable software in Rust is a very bad idea. Especially in open source, where we don't have enough maintainers, it ends up hurting the ecosystem. A certain prominent GNOME maintainer has been trying this recently and breaking things along the way: https://gitlab.gnome.org/GNOME/librsvg/issues/456 https://gitlab.gnome.org/GNOME/librsvg/issues/456 Apparently, GObject Introspection doesn't even work in Rust, yet it is expected to be a perfectly valid replacement: https://github.com/gtk-rs/gir-files/issues/35 https://github.com/gtk-rs/gir-files/issues/35 Please don't be like these people! Keep the stable software we have, and maybe write new software in Rust.
- bluejekyll 7y ago
  > Please don't be like these people! As the maintainers of the software shouldn't they have the prerogative to maintain the software in the best way they see fit? Bugs happen while refactoring, regardless of how the refactoring is done.
  - matthewbauer 7y ago
    They do, but that doesn't mean the decision is wise. The point is you are creating more bugs than you could ever possible fix in this kind of refactor.
    - arcticbull 7y ago
      I also err on the side of never re-writing things, and pros and cons must always be weighed on a case by case basis. It's not possible to say in general that re-writing software in a language not prone to many important classes of bugs would "create more bugs than you could ever possibly fix." We won't know the decision is wise or unwise until it's attempted and studied maybe even a few times over.
    - pcwalton 7y ago
      And those bugs get fixed, and the software ends up better. I've contributed to two successful "rewrite it in Rust" projects now: Stylo and WebRender. Both of them ended up fixing long-standing bugs in the previous implementation that were difficult to address in the old codebase, but a new clean approach offered a nice opportunity to fix them.
    - xedrac 7y ago
      If you're rewriting into a language like C++, this may very well be true. However rewriting in Rust in my experience yields far fewer bugs, and the ones that do surface are usually simple to fix. If a project truly is "stable" - there's very little effort involved in maintaining it, then yeah, it doesn't make sense to rewrite it. But if it's plagued by bugs and is painful to maintain, you'd be much better off rewriting it in Rust, assuming you're familiar with the existing project's limitations.

matthewbauer 7y ago

Rewriting stable software in Rust is a very bad idea. Especially in open source, where we don't have enough maintainers, it ends up hurting the ecosystem. A certain prominent GNOME maintainer has been trying this recently and breaking things along the way: https://gitlab.gnome.org/GNOME/librsvg/issues/456 https://gitlab.gnome.org/GNOME/librsvg/issues/456 Apparently, GObject Introspection doesn't even work in Rust, yet it is expected to be a perfectly valid replacement: https://github.com/gtk-rs/gir-files/issues/35 https://github.com/gtk-rs/gir-files/issues/35 Please don't be like these people! Keep the stable software we have, and maybe write new software in Rust.

bluejekyll 7y ago
> Please don't be like these people! As the maintainers of the software shouldn't they have the prerogative to maintain the software in the best way they see fit? Bugs happen while refactoring, regardless of how the refactoring is done.
- matthewbauer 7y ago
  They do, but that doesn't mean the decision is wise. The point is you are creating more bugs than you could ever possible fix in this kind of refactor.
  - arcticbull 7y ago
    I also err on the side of never re-writing things, and pros and cons must always be weighed on a case by case basis. It's not possible to say in general that re-writing software in a language not prone to many important classes of bugs would "create more bugs than you could ever possibly fix." We won't know the decision is wise or unwise until it's attempted and studied maybe even a few times over.
  - pcwalton 7y ago
    And those bugs get fixed, and the software ends up better. I've contributed to two successful "rewrite it in Rust" projects now: Stylo and WebRender. Both of them ended up fixing long-standing bugs in the previous implementation that were difficult to address in the old codebase, but a new clean approach offered a nice opportunity to fix them.
  - xedrac 7y ago
    If you're rewriting into a language like C++, this may very well be true. However rewriting in Rust in my experience yields far fewer bugs, and the ones that do surface are usually simple to fix. If a project truly is "stable" - there's very little effort involved in maintaining it, then yeah, it doesn't make sense to rewrite it. But if it's plagued by bugs and is painful to maintain, you'd be much better off rewriting it in Rust, assuming you're familiar with the existing project's limitations.