Writing this sort of rant in English is meta-hilarious.
You can't do that because I hate you
41–50 of 216 posts
Re: You can't do that because I hate you
#42The 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...
Re: You can't do that because I hate you
#43Earlier quoted context omitted.
Yeah. "I know it's not right, but it's not totally wrong and probably better than not doing anything" actions as maddening as the behaviour he describes. A world where that's the standard would be chaos. When you work with _precise_ systems, they sometime take _precise_ input to work. That's kinda just part of the job.
Except in the case of the 'exit' clearly this is accepting and parsing imprecise input in order to guide the user. If the code wasn't looking for 'exit' in order to correct the user (to use 'exit()'), it would just spit out some other error for 'I don't know what you're talking about'. Instead, they actually detect the intent by specifically coding for it... and then ignore it anyway. That's bloody minded.
Except they didn't -- the result of a statement is turned into a string, and the string is printed. There are standard ways of turning objects into strings, and the `__repr__` function on the `exit` object returns that string. If you call that object then it raises an exception that triggers a REPL to cleanly quit.
The code is here: https://github.com/python/cpython/blob/3.12/Lib/_sitebuiltin...
Re: You can't do that because I hate you
#44Do what I mean, not what I said can be problematic for tools. That being said, the example where the devs left a link to file an issue to beg to restore functionality was maddening.
Agreed, but in that case the tool shouldn't be trying to detect what I mean. Why look for 'exit' only so you can print 'no actually, it's exit() dummy'. If you're parsing for it then just bloody do it! Otherwise I'll get a syntax error and realise that 'exit' isn't the right way to exit. And I'll do a quick search myself. But explicitly looking for and detecting my intention and then ignoring it is just dumb.
Nothing is looking for exit. The REPL is calling repr(result) to show the result of the expression to the user. repr(exit) is the string "Use exit() or Ctrl-D (i.e. EOF) to exit". You _really_ don’t want repr(builtin) to have a side-effect like terminating the program.
Stop being toxic and patronizing towards open-source developers out of ignorance.
Re: You can't do that because I hate you
#45Earlier quoted context omitted.
Yeah. "I know it's not right, but it's not totally wrong and probably better than not doing anything" actions as maddening as the behaviour he describes. A world where that's the standard would be chaos. When you work with _precise_ systems, they sometime take _precise_ input to work. That's kinda just part of the job.
Except in the case of the 'exit' clearly this is accepting and parsing imprecise input in order to guide the user. If the code wasn't looking for 'exit' in order to correct the user (to use 'exit()'), it would just spit out some other error for 'I don't know what you're talking about'. Instead, they actually detect the intent by specifically coding for it... and then ignore it anyway. That's bloody minded.
If it actually exited, you might incorrectly conclude that exit would work the same way in a script.
Re: You can't do that because I hate you
#46I feel the same way about Rust unstable features. Either you can only use features that are "stabilized"—guaranteed to never change—or you can throw all guarantees out the window, and use the unstable, experimental version of the toolchain.
This would be fine if "unstable" features were actually experimental messes, but all sorts of completely-benign utility functions are "unstable". You have to throw out all guarantees for your entire toolchain just to use, say, `Result::into_ok`, which was introduced in 2019, but is still unstable due to being "newly added".
At best, this is misleading, at worst, this greatly compromises the developer experience, especially when writing libraries which need to work on stable or else nobody will install them. Even for application projects, I don't want to use unstable features, because it's extraordinarily stupid to make the entire project nightly-only just because I want to use a two-line utility function, and I'm petty that way.
Sure, I'll use unstable for things like bare-metal programming that deserve to be unstable, but if I'm writing regular application code and the perfect utility function is "unstable", I'm not going to lock myself into nightly just for that.
Re: You can't do that because I hate you
#47I feel the same way about Rust unstable features. Either you can only use features that are "stabilized"—guaranteed to never change—or you can throw all guarantees out the window, and use the unstable, experimental version of the toolchain. This would be fine if "unstable" features were actually experimental messes, but all sorts of completely-benign utility functions are "unstable". You have to throw out all guarant…
> but is still unstable due to being "newly added".
Where did you get this from? The tracking issue says nothing of the sort: https://github.com/rust-lang/rust/issues/61695
Re: You can't do that because I hate you
#48>I understand that might be confusing for newcomers, and exiting might be too destructive. But denying you the normal REPL behavior and denying you the ability to exit is just insulting. Sentence 1 provides a clear justification for the behavior. Then sentence 2 declares, by bare assertion, that it's "insulting". I find sentence 1 more persuasive than sentence 2.
1 may be more persuasive but it’s 2 that makes me wish someone a very bad day every time that message prints.
Re: You can't do that because I hate you
#49The 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…
5 years to get a wrap_comments feature stable? I sometime wonder if people read the things they write?
Re: You can't do that because I hate you
#50Rust is a great language but the developers suffer really badly from Reddit Intellectual syndrome. If they put some people with social skills at the forefront of relations with users it would definitely get more adoption.