Those are the demands of passionate early adopters.
There are *a lot* of people who don’t like things that move that quickly.
Are the rust teams sure they’re serving their user base? Or are they actually pandering to a vocal minority?
Are they actually addressing real pain points? Or just working on cool stuff?
Have they even asked?
You might not get to use the latest and greatest versions of libraries that way, but that's the explicit goal of not changing things anyway.
Do you use libraries from other people? Do you work on projects with others that like those features? Then I bet you'll have to use those features, whether you want to or not.
This isn't Rust specific, mind you, but any feature added that is used and has an effect on the API will be forced onto you at some point.
Since async popped up it's become really hard to avoid. And most packages have converged on Tokyo as an executor.
If you use these libraries they will not only force you to use async, they will even force you to pick their executor.
The introduction of GATs will impact interfaces. They will be forced onto you.
I'm not saying this shouldn't happen, in some way it's inevitable for it to happen. But it can be quite harrowing if you're not a sole developer doing all their own libraries.
This is kind of like the "if you use C++ properly you can create safe code in it" mantra. Which again, yes, but only if you have total control of the project, don't have any other developers on it that might impact your design, and don't use libraries.
I’m saying is the work currently being done valuable, compared to other quality of life issues in the language.
I posit to you, that, fundamentally if you have a finite allocation of effort, and that effort is devoted always to new features…
…the MVP of the features that exist, with their rough edges will remain, and the MVP of the new features will add to the pool of rough edges.
Go on, make a compelling argument that adding new features without pausing to tidy up doesn’t result in that.
I flat out don’t believe you can.
It’s not a point of contention; it’s a fundamental aspect of software development.
The point in contention here is: are the rough edges we have currently reaching a point where addressing them, rather than adding new ones should be a priority?
That’s a matter of opinion.
You clearly have yours; I disagree. That’s fine.
What I want to raise is that what you and I think individually is not important; this is something for the entire community to talk about and decide on.
Maybe the next rust survey should ask about it?
Then, rather than speculating, we would be able to know, and make decisions based upon n that.
Is that… totally unreasonable?
Communities discuss things in a whole bunch of one on one conversations as well as larger forums. There's an entire RFC process and a ton of outreach, and committee meetings that can be participated in as well, for more formal process.
So, lets discuss your specifics.
There's only one possible reason to end a collect() with ? surely?
Well there's Result as you point out. There's also Option. And there's a new feature, the Try trait that allows `?` to be used for other types too. It's still a nightly only feature, because these new changes that come way too fast for you still spend a lot of time in nightly to work out bugs (etc).
So I'm curious of your take here - is it that the features that exist should be worked on to fix them instead of adding new stuff? Is it that you suddenly think that the type requirement isn't a wart after all and they shouldn't be messing with `?`? Is it that your example wasn't one of the most pressing issues, just the first one that came to mind and obviously shouldn't be prioritized despite you claiming it should?
Or maybe you just are just wrapping your opinion (that is dislike of ? and rust in general) in some nonsense about how the community is being ignored.
Why can't you clone a boxed function?
What's your plan for fixing this? Are there already RFCs about it? What are the reasons it's not currently clone (e.g. Is it easy but would break old code? Is it actually really hard? Does it break some other invariant?)?
Saying "i want this" is great, but as you say PL ishard. The finite resource thing you mention is true: are you going to add resources and help out or are you going to sit back and complain about how other people choose to spend their time because they don't share your prioritization? No matter how highly you value yourself or your opinion, the people doing this work aren't beholden to you - do the work or hire someone to do the work. Maybe the community will accept your proposal or patch or whatever.
Why cant you express that a struct can contain an object and a reference to the object and have a 'static lifetime?
There have been proposals about doing this. Go read the discussions on them - usually they have all sorts of weird edge cases that are hard for borrow checking to prove. Perhaps you are the genius that can solve them, maybe you should participate as a community member and write some code to make this happen in a way that doesn't break old code or weaken the borrow checker.
Rust is done out in the open, and the community is who does it. Go participate instead of complaining that volunteers aren't catering to your whims (which no matter how you want to phrase it is what you're demanding).
Further about the wierd false dichotomies:
…the MVP of the features that exist, with their rough edges will remain, and the MVP of the new features will add to the pool of rough edges.
Go on, make a compelling argument that adding new features without pausing to tidy up doesn’t result in that.
The Linux kernel has spent 25+ years doing new features and cleanup in conjunction.
* Is that… totally unreasonable? *
Well no, that's why there RFCs, very welcoming working groups, great community projects, forums, chat, and... the survey. Maybe you could get your question on the survey if you go talk to the working groups? Perhaps you could go find the answers to your questions in one of the community spaces?
What is unreasonable is whining how a community driven project doesn't listen to people who choose not to participate in the community. What is unreasonable is claiming some imaginary mass of people who all just happen to agree with your exact opinion (coincidentally of course) is being ignored by design. What's unreasonable is that you are presenting a case for a massive conspiracy against users when it might simply be a case of "you didn't even try the existing channels" as it appears to be.
The compiler hasn't slowed down for them, in fact it was sped up recently.
So I'm curious if you can point to instances of your hypotheticals, sure that's all possible, but did it actually happen or are you arguing in the sense of "if you just write perfect code..." and similar grasping at strawmen styles.
Open source maintainers and authors owe you nothing. If you are not paying them, they owe you zero consideration in their work.
The entitlement from 'users' which open source maintainers constantly face is over the top.
The rust team ought to build the language they want and people can use it or not.
