but we can agree on which of two implementations is shorter.
Shortness for the sake of being short sounds like optimizing for the wrong metric. Code needs to be easy to read, but it's more important that the code is easy to change and easy to test. Inline code and function calls are renowned to render code untestable, and introducing abstract classes and handles is a renowned technique to stub out dependencies.
Duplicate code can be a code smell, but it's far better to have the same function definition or code block appear twice in the code than extracting a function that tightly couples two components that should not be coupled at all.
See Write Everything Twice (WET) principle.
I agree. The GIL and packaging woes are a good indication that it's range of applications isn't as extensive as other tech stacks.
Here’s another: most code reviews on larger companies are BS, just for show and nitpicking.
Story time.
Once I worked with a developer that just joined the company straight out of college, and had far more ambition than competency. That developer decided that code reviews where the venue where their high bar for code quality would shine, so they decided to nitpick everything that went against their poorly formed sense of taste. As luck would have it, the developer was assigned to a legacy project that was in cold storage for years and had no tests and linters, and was in a really poor state, and proceeded to leverage that to challenge each and every insignificant detail such as if a space should be at the left or at the right of a symbol. Each code review automatically received dozens of comments nitpicking whitespace changes. What a waste of time with so much noise.
I drop by the project, and noticed the churn that developer alone forced upon everyone, as that team had a rule that all code reviews should be passed by all reviewers and that reviewer made it their point to reject reviews that didn't complied to their opinion on whitespace. So the first thing I did was onboard a code formatter, and made it my point to subject the spec to an unanimous code review. That problematic developer made it their point to nitpick away each and every single setting, but it turned out some of their opinions conflicted with previous feedback.
So the code formatter tool was onboarded onto the team. Did that stopped the problematic developer from continuing their nitpicking? No. Except this time around other developers started pushing back because the opinions were contradictory and contrasted with the official code formatting style.
All it took was a couple of days for the problematic developer to go from dozens of comments per day to zero. The code formatter was still optional and not fully adopted, but the problematic developer simply ceased with the bickering.
Python is only good for short programs
Was Python designed with enterprise applications in mind?
It sounds like some developers have a Python hammer and they can only envision using that hammer to drive any kind of nail, no matter how poorly.
Having fun when programming should be much more important than having correct or fast code (...)
That's only remotely reasonable if you're a weekend warrior that messes with coding as a pastime. Even so, I'm not sure what fun you can extract from dealing with slow, broken code.
HTML is bad. The language itself feels unintuitive and is clunky compared to modern markdown languages, and let’s be honest, your webpage just consists of nested tags.
My websites do not consist of nested divs. Your webpages might just consist of nested divs, but only if you are clueless about what you're doing and are oblivious to basic stuff like accessibility support.
CSS is bad. Who knew styling can be so unintuitive and unmanageable? Maybe it made sense 25 years ago, but now it’s just terrible. It’s very clunkily integrated with HTML too in my opinion.
Being unmanageable is the output of the developer team, not the languages they use. Decoupling Presentation from the data and semantics never ceases to make sense. CSS has many issues but the way its integrated with HTML is certainly not one of them.
Frankly, you sound like you blame your tools a lot.
You don’t have guarantee nobody touched your file, we should database that keep structure information instead.
What is your definition of file and database? For example, do you think SQLite is a database, and a SQLite database file counts as a file? Do you think that editing SQLite or PostgreSQL with a third party client counts as touching a file?
Does it have to?
If you're a developer looking for a pastime working on a personal project, no. You're free to waste your time and effort doing anything that pleases you.
Everyone else in the world only bothers with something if it provides any value at all. If a project such as this one fails to provide any value them no one will have any reason to waste their time with it, no matter how many times you rewrite it in Rust.
I always assume all the reviews are from plants or axe grinders.
That's my expectation as well. People need to be motivated to go out of their way to provide feedback, either good or bad. It's only natural that axe grinders are highly motivated to leave organic feedback while plants are either compelled game the metrics or pressured to game the metrics.
Either way, salary is the best indicator and lots of rosy pictures are as good as bad reviews.
But sudo-rs seems to have a bit of a different usecase since it is intended as a drop in replacement for sudo, hence it must be able to handle the sudoers file aso.
Other than being yet another "standard tool X clone written in Rust" project, does it actually provide any tangible value?
Readability is often in the eye of the beholder, but knowing that a component implements a design pattern is all you need to know how it's used without even having to peek at the code.
I think the most vocal critics of design patterns are those who are clueless about design patterns, and they are criticising their use just because they are scared of stuff they don't know.