Comment by shepherdjerred | Hacker News Reader

Comment by shepherdjerred | Hacker News Reader

The author provides very surface-level criticism of two Rust tools , but they don't look into why those choices were made. I'm ignoring the Python complaint since it's discussed in other comments.

With about five minutes of my time, I found out:

wrap_comments was introduced in 2019 [0]. There are bugs in the implementation (it breaks Markdown tables), so the option hasn't been marked as stable. Progress on the issue has been spotty.

--no-merge-sources is not trivial to re-implement [1]. The author has already explained why the flag no longer works -- Cargo integrated the command, but not all of the flags. This commit [2] explains why this functionality was removed in the first place.

Rust is open source, so the author of this blog post could improve the state of the software they care about by championing these issues. The --no-merge-sources error message even encourages you to open an issue, presumably so that the authors of Cargo can gauge the importance of certain flags/features.

You could even do something much simpler, like adding a comment to the related issues mentioning that you ran into these rough edges and that it made your life a little worse, or with a workaround that you found.

Alternatively, you can continue to write about how much free software sucks.

[0]: https://github.com/rust-lang/rustfmt/issues/3347

[1]: https://github.com/rust-lang/cargo/pull/10344

[2]: https://github.com/rust-lang/cargo/commit/3842d8e6f20067f716...

> you can continue to write about how much free software sucks.

I think that's unfair. He wasn't writing about how much free software sucks, he was writing about how some of the rust tooling sucks.

Even in the larger context, everything he wrote applies just as readily to proprietary software. These sorts of issues are everywhere.

The post itself isn't very generous; its title is “You can’t do that because I hate you.”

You're right that "frustrating to use software" applies to proprietary software as well, but the author only gives very specific examples all of which involve open source.

> The post itself isn't very generous; its title is “You can’t do that because I hate you.”

Well, sure, the post is a good old-fashioned rant to vent his frustrations. The title is part of that. A well-written one, but nothing more than a rant.

You're right.

Rants are fine, and I've been frustrated by software too many times to count.

I'm being a bit protective because I would feel hurt if someone wrote that "I hate them" about some of the software I've worked on for free and open sourced.

5 years to get a wrap_comments feature stable? I sometime wonder if people read the things they write?

I mean... check out the issue tracker for any project, open source or commercial. It's just how it goes when things aren't a priority. Happens all the time.

The conversation was about why the feature wasn't stable.

I have no idea how the Rust project organizes itself, but my guess is that this simply isn't a high enough priority for them, which would explain why it hasn't been made stable.

Large backlogs with stale are a common problem that software projects have.

I don't know if this is hard in their codebase (although I have a guess), but I have worked on a code formatter before and easy-sounding things were often an unimaginable nightmare.

Code reformatting is, apparently, surprisingly hard. This classic article has popped up on HN a few times over the years: https://journal.stuffwithstuff.com/2015/09/08/the-hardest-pr... (one reappearance at https://news.ycombinator.com/item?id=30566111)

So I can understand why such a feature remains behind an experimental flag. "But you are not touching code, only reformatting comments!" - well, not just thta. Adding whitespace and N+1 effectively empty lines will at some point cascade into whatever logic the wider code formatter will have to consider. The number of edge cases must be non-trivial.

Reply on news.ycombinator.com