rust-lang / rfcs

RFCs for changes to Rust
https://rust-lang.github.io/rfcs/
Apache License 2.0
5.78k stars 1.55k forks source link

Advanced std: useful functionality not in the standard library #3578

Closed coolCucumber-cat closed 4 months ago

coolCucumber-cat commented 4 months ago

This is only somewhat a language feature and also not a concrete proposal. There are a lot of things that are very common and useful, and should be standardised, but would not make sense to add to the standard library. Like how std is more advanced than core, we could have another library that is more advanced than std, but still completely separate so it doesn't get polluteed. This could be done in many ways, it could be a builtin library like std, core and alloc (could be a opt-in as a feature or opt-out like #![no-std]), it could be a crate or many separate ones. Or they could be normal (maybe even existing) crates that are "verified".

Functionality could include:

Part of my inspiration is Go, which has a lot of standard library packages, but they definitely don't belong in normal std.

At the minimum I would like to see some "verified" crates, like chrono and rand, because those are so common and it's annoying to find the right one, so with some editor integration it could auto-import them and add it to your Cargo.toml.

TL,DR: I would like to see some basic functionalities be standardised and easier to find, not just finding any crate, but one that works for most cases.

Nilstrieb commented 4 months ago

What's the problem you're solving? Rusts ecosystem works well today, and for the problems it does have, putting some popular crates in a more "official" library does not solve them.

SOF3 commented 4 months ago

TL,DR: I would like to see some basic functionalities be standardised and easier to find.

Resources like crates.io, lib.rs, rust-cookbook, etc. exist to solve that problem.

coolCucumber-cat commented 4 months ago

@Nilstrieb @SOF3 That's true, but which one do you pick? You just have to pick one out and try, or research it. It would be nice if there were a few crates that are verefied, or something like that, and you can choose that whithout any major worries.

For example:

Lokathor commented 4 months ago

Even ignoring that the Rust Project should basically stay out of trying to pick winners and losers, what you're asking for is a huge additional ongoing burden to have people keep all the info up to date.

Really, you've gotta kinda ask around. Whoever you know that does Rust, ask them if they know a good crate, or ask them where you can find the people who do. Word of mouth really is best for this sort of thing.

coolCucumber-cat commented 4 months ago

@Lokathor Well, that was why my main suggestion wasn't that, it was that it should be a builtin like core or std, my second suggestion was a crate made by Rust and only my third suggestion was existing crates.

shepmaster commented 4 months ago

my main suggestion wasn't that, it was that it should be a builtin like core or std, my second suggestion was a crate made by Rust and only my third suggestion was existing crates.

Your primary suggestions are that some group of people rewrite an unknown number of existing crates from scratch so that it's easier for you to tell which crate to use? The same people that would be doing the rewriting are already people that can create and publish those crates, there's nothing magical about being published under the Rust name.

However, you have the ability to do all this today! All you need to do is create a crate that re-exports all the behavior from third-party crates that you want (or rewrites it, your choice), call it cool-cucumber-cat-std, and publish it to crates.io. Then everyone can use your hard work without having to spend time finding it on their own. Everyone has a happy end!

coolCucumber-cat commented 4 months ago

@shepmaster

I am very confused about your comment. I didn't say any of that. I not sure what your motivation towards lieing and misrepresenting what I said is, or why you are being so condescending about it. I have many arguments, but you took the weakest one and disregarded all the other ones, then you lied about it and pretended that was my entire argument. In fact, you told 5 lies in one sentence. Why did you not mention the other reasons? You're being intentionally disingenuous and misleading.

And I'm actually really curious as to why you lied so much. You don't have any incentive for it.

coolCucumber-cat commented 4 months ago

In fact, why is everyone only concentrating on my argument about being easier to find? And only on the actual finding a crate, not which one specifically.

Lokathor commented 4 months ago

Are you asking for people to have a list of approved crates? I said already: we don't really want the Project to pick winners at all, and we don't want to maintain such a list over time because we can barely do all the existing work.

Are you asking to put code in the standard library? Well the policy has always been to be fairly minimal and sometimes we still get it wrong and have to work extra carefully to fix each mistake when the design turns out to be less good after the fact.

coolCucumber-cat commented 4 months ago

@Lokathor I don't mean to be condescending, but did you even read what I said? If I worded something badly, then tell me that.

Your first question is answered in the original post. It's my 3rd choice. 4th if you include the 2 possibilities of my 2nd choice. That means it's the least important of them all. In fact I was considering not even mentioning it, which I should have done since it's the only one people are concentrating on and the one that people are asking stupid questions about.

The second question is even stupider, assuming you mean ::std and not builtins. I mean it's even answered in the title. And then I even addressed that concern in the first sentence, which is the entire reason this post exists. Like even if you meant builtins in general, this is still a stupid question.

Maybe this is all a big misunderstanding. I keep rereading my post to see what I could have possibly said wrong.

Lokathor commented 4 months ago

I'll try to outline the specifics from your opening post:

This could be done in many ways, it could be a builtin library like std, core and alloc (could be a opt-in as a feature or opt-out like #![no-std])

That's effectively just a new part of the standard library, so all the usual concerns about how the standard library should be small to avoid stabilizing things that turn out to be less optimal designs would still seem to apply.

Putting it under std_extra or some alternative name doesn't change this.

it could be a crate or many separate ones.

One crate or many doesn't really change anything.

Or they could be normal (maybe even existing) crates that are "verified".

This is where I explain that "verified crates" is the "picking winners and losers" scenario, not really something that we should do. Also we don't really have the spare work capacity to do it anyway.


If there's any remaining points that you think have not been addressed please restate them specifically, because that's everything that I'm seeing.

coolCucumber-cat commented 4 months ago

@Lokathor why can you now suddenly understand what I'm saying? You could have skipped the stupid questions and gone straight to that.

About making an official crate or crates, I never said it mattered if it was one or many, I just made 2 suggestions how that idea could be implemented. So what do you mean by "One crate or many doesn't really change anything.".

coolCucumber-cat commented 4 months ago

I also didn't know about the limited work capacity. But it also doesn't have to be all of the things I said, I would also be happy if it were just command line argument parsing, which is needed for any CLI tool. My second pick is stdin tools, since that's pretty common in CLI tools too. The last thing would be worker threads.

You can just do the ones that are possible. That might be 0. We don't necessarily have to do it right now, know the exact scope or do everything at once. If there's suddenly the capacity, then maybe 1 or 2 could be done and see how it works out.

seritools commented 4 months ago

I'm confused - why don't you just... start doing it? Start a project that solves these issues for you first, then propose adding it as an "extended stdlib" later. In the meantime people can already try it out and give feedback, even if it's not "official" yet.

coolCucumber-cat commented 4 months ago

@seritools what's wrong with suggesting it now? I'm only one person and I don't have the technical knowledge. Part of my reasoning is that the people who make Rust are pretty good at Rust. And why would you be confused? I could have started it, it's not like I completely refused to do it or didn't think of it.

oli-obk commented 4 months ago

Moderator note: please remember to not insult people. Also let this be a reminder to assume good intent.

coolCucumber-cat commented 4 months ago

@oli-obk I don't think anyone said any insult. I said their question was stupid because I had already answered it before. I literally avoided calling them stupid because I did assume they had good intent, I still don't understand how it isn't a stupid question. I'm really trying my best to understand what other people mean and I try my best to not accuse or assume. It feels like people are trying to team up on me to troll me. When people lie about what I mean, act all condescending, ask stupid questions etc, it's all good, but when I tell them it's a stupid question, it gets marked as abuse, apparently I'm insulting people and people give negative reactions.

Can you guys please give me some actually constructive feedback, not just "😕".

oli-obk commented 4 months ago

Please reach out to me via DM on zulip if you want to discuss this.