[cogman10]

Rust's std lib approach is the best way to approach a std lib (IMO). Even in java world, some dependencies end up being the defacto standard while others end up dying off.

The JDK has a bunch of garbage in the JDK that people shouldn't use. That stuff has to remain due to strong backwards compatibility guarantees.

Rust's approach means that non-standard stuff that we end up realizing is a mistake can quietly die off.

Now, should it be larger? Probably. I'd prefer if rustlang had a standard async/await implementation rather than leaving it up to the ecosystem. But I don't think rust needs, for example, a gui api (like swing or awt) in the standard library.

I'd prefer if rust was managed a bit more closely to the way java is managed today. Java doesn't pull in new apis willy nilly, but the ones they do pull in end up being things that have broad appeal and utility. Rust could take a look at common crates in the ecosystem and start pulling those in to the standard lib.

[bryanlarsen]

> I'd prefer if rustlang had a standard async/await implementation rather than leaving it up to the ecosystem

The "default" is tokio, and I think even the tokio authors would agree that it's neither suitable nor ready to be part of the stdlib.

OTOH, pollster[1] (or something like it) should be pulled into the standard library. Not particularly useful for anybody who wants async, but super useful for anybody who doesn't want async but wants to use a 3rd party crate that includes async.

1: https://docs.rs/pollster/latest/pollster/

[cmrdporcupine]

On the async front, more work needs to be done to allow a more "plug and play" scenario for async runtimes. Standard APIs/traits for task spawning & mgmt, channels, locks, etc. Because right now it's not really feasible to write a library in an async-agnostic way, and tokio just owns the field even in places where it's not really appropriate or the best choice.

[gertop]

In Java land, I can just ignore dead stdlib stuff. In rust land I have to fight bugs when two crates depend on different async or applicator libraries.

Surely you can see how one is worse than the other?

[cogman10]

> Now, should it be larger? Probably. I'd prefer if rustlang had a standard async/await implementation rather than leaving it up to the ecosystem.

What you are describing is a problem, no doubt about it, but it's not as if this isn't something that can't come up in javaland. For example, dealing with a project that uses both Gson and Jackson. Or dealing with a project that's mixed together Netty with Apache http.

And when you can ignore these dead libs very much depends on what the other parts of the lib you are dealing with. For example, you might never interact with `Enumeration` or `Vector` yet there are parts of the Swing api that expose those.

[bigstrat2003]

> The JDK has a bunch of garbage in the JDK that people shouldn't use. That stuff has to remain due to strong backwards compatibility guarantees.

That is not actually a problem. Let it stay there, it hurts nobody and may actually occasionally help people.

[cogman10]

I disagree that it's not hurting.

The massive feature set of the JDK bloats the size of every container shipping with the JVM. It pumps up the requirements for metaspace. And it negatively impacts JVM startup time.

I'm not saying the JVM needs to remove every dated API. But things like JNDI, for example, are not only dangerous to use (that was the root cause of log4j2's big vulnerability), they are massive feature sets that pretty much nobody wants to use.

Java was designed in an era where we thought having thinish clients streaming jars/classes from central network servers was probably a good idea. When we thought the JVM could be more than just a language VM, it could be an operating system. A lot of those concepts simply don't apply to modern jvm dev or even jvm dev that's happened in the last 20 years.

And, to be clear, the JDK was not wrong in bringing along all these libraries. After all, in the 90s it's not like we really had a great story around community package development. That was an era where devs routinely downloaded their dependencies manually. Clever devs even had curl scripts wired into ant or make to do that job.