Re:Thoughts on Rust bloat
by sanderjd on Wednesday August 21, 2019 @08:45PM
(#20763541)
I think not anymore since java.time - which is incredibly similar to Joda - came around? This is actually an illustrative example of the process I like and hope rust will develop over time: let the community reach a consensus on the best third party libraries things, then consider pulling them in to or at least taking the best parts of their APIs for the standard library.
[ Parent
| on HN ]
Re:Thoughts on Rust bloat
by bluejekyll on Wednesday August 21, 2019 @09:40PM
(#20763858)
But won’t the community converge on that anyway, and in a similar amount of time? So why add it to the stdlib?
Re:Thoughts on Rust bloat
by tikkabhuna on Thursday August 22, 2019 @07:39AM
(#20766944)
Other Java stdlib packages can't depend on Joda-time. If it wasn't added and I used joda-time I'd have to convert to the old datetime classes if I wanted to use it with stdlib packages.
Another example was CompletableFutures which were inspired by ListenableFutures from Guava.
I can now use these with guarantees that they will be stable as Java has strong commitments to backwards compatibility.
Re:Thoughts on Rust bloat
by erik_seaberg on Thursday August 22, 2019 @03:02AM
(#20765390)
The JRE should be self-sufficient. By bundling java.time, it can finally start offering methods that take and return those types, instead of the current jumble of millis, nanos, long+TimeUnit pairs, Dates, and Calendars.
There's a cost to discovering the consensus choices that I think inclusion in a standard lib minimizes. But there may be other similarly good ways to accomplish this. If I'm remembering correctly, doesn't Rust have a set of libraries that aren't in the standard library but are somehow vouched for? Maybe that's a similarly good approach to solve the discovery problem, I'm not sure.
Re:Thoughts on Rust bloat
by steveklabnik on Thursday August 22, 2019 @01:44AM
(#20765012)
There are libraries that are maintained by the project itself, but are not part of the standard library, yes.
Ok thanks. Is the intention for that to grow, as a curated set of libraries that isn't quite the standard library? Or so you think some of those will move into the standard library if they become canonical or stable enough?
Re:Thoughts on Rust bloat
by steveklabnik on Thursday August 22, 2019 @11:00AM
(#20768832)
We’ll see; it’s not a simple thing.
In theory they can move into the standard library, but none ever have. The process exists though.
I can think of a bunch of stuff that has moved or is moving from third party crates into the standard library: parking_lot, hashbrown, (minimal) Future trait. But I agree that no crate has moved wholesale into the standard lib.
Re:Thoughts on Rust bloat
by steveklabnik on Thursday August 22, 2019 @03:03PM
(#20771340)
parking lot and hashbrown moved their internals, replacing ones that already existed. This is probably a distinction that doesn’t actually matter but in my head it’s different for some reason, thanks for pointing it out :)
Is there a list of these somewhere? Crates.io doesn’t appear to let me sort by author.
Re:Thoughts on Rust bloat
by throwupaway123 on Thursday August 22, 2019 @09:59AM
(#20768109)
This is the GitHub repository
Re:Thoughts on Rust bloat
by steveklabnik on Thursday August 22, 2019 @10:59AM
(#20768828)
We’re in the process of deprecating the nursery, so they’ll end up in the rust-lang org at some point.
Re:Thoughts on Rust bloat
by quantummkv on Thursday August 22, 2019 @12:51AM
(#20764734)
Stability? Guarantee that the api will continue to work and that no one will wake up one morning and left-pad the entire ecosystem?