Even in Java, if you're looking to do anything with dates, everyone will tell you to use Joda-Time over java.util.Date.

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.

But won’t the community converge on that anyway, and in a similar amount of time? So why add it to the stdlib?

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.

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.

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?

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.

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.

This is the GitHub repository

https://github.com/rust-lang-nursery/

We’re in the process of deprecating the nursery, so they’ll end up in the rust-lang org at some point.

Stability? Guarantee that the api will continue to work and that no one will wake up one morning and left-pad the entire ecosystem?

That's true if you're still on Java 7. java.time.* is the go-to now, and it is very high quality.

Only if one is stuck in pre-Java 8.

> A case in point is how the ORM Entity Framework that comes with .NET has made the older NHibernate (a separate package) obsolete

This did happen over time, but NHibernate was still really popular for a long time after EF came out, because of limitations it had.

I also don't think it was entirely because EF existed - over time, EF implemented more and more features that NHibernate had, yet at the same time it seemed like the NHibernate team had given up - there were no updates to it for a long time. It was the lack of updates that moved me to EF, but I always preferred NHibernate.

My goal for choosing .NET libraries is to minimize the total complexity of our software stack. [0]

I won’t add a library to our stack if we have an existing solution.

Most of our apps are written in C# and use Entity Framework with either ASP.NET MVC or Windows Forms.

I would need an excellent reason to use something else.

[0] https://mcfunley.com/choose-boring-technology

> .NET developers love using the standard libs

I may not be a typical .Net developer, but my personal feeling is that this is too general and somewhat glib.

If you're inexperienced you will (and should!) choose the default option, if there's one available, and the most commonly used option if there isn't a default. So, if you wanted an ORM, then before EF there was NHibernate. But after a while you become able (from painfully gained experience) to determine what you want from a tool and what trade-offs you want to make, so you might use something like Dapper or no ORM at all.

Personally, I have found some of the MS provided implementations - shall we say - less than optimal. The Unity Framework. EF (which I dearly wish I have never had to suffer using). MSTest. Enterprise Library (oh god ugh).

So I make other - informed - choices about what to use. Some things I keep using because they are 'good enough' and I have a library of utilities and a mental map of how they work - log4net, NUnit - and some things I find I just don't need any more (mocking libraries, for one).

MS still support their provided implementations - as they should - but even their own projects can and do use third-party frameworks rather than the MS provided implementation (for example, Bot Framework used AutoFac (back when I was using it, anyway) [1]) - because their developers have been released from the requirement to exclusively use MS provided frameworks, and are making their own choices about what to use in their projects, and consequently what their users should use when using those tools.

Eventually, of course, if a tool is so crucial that it becomes part of .Net itself - the best example I can think of is dependency injection in .Net Core, which is in Microsoft.Extensions.DependencyInjection - you'd have to be mighty stubborn to use anything else.

One other point: I wouldn't describe NHibernate as 'obsolete', but given their historic and chronic inability to keep their documentation sites live and working ([2] referenced from [3]) it's easy to get that impression. But people are certainly still using it [4]. Just not as many as there used to be.

[1] https://github.com/microsoft/botframework-sdk/issues/938 [2] http://www.nhforge.org/doc/nh/en/index.html [3] https://ayende.com/blog/4139/nhibernate-documentation [4] https://stackoverflow.com/questions/tagged/nhibernate

I'm not saying .NET developers will never use other libraries as an alternative, but they wont invent wheels (or used reinvented wheels) where the .NET provided one is solid. I am speaking generally of course. And there are many developers who are .NET + something else. I'm .NET and dabbled with Haskell and Node JS for example. I'm looking at Lisp as it is interesting. But let's write a web app in .NET. How many .NET developers will think "which framework should I use?". That is a valid question in JS/Haskell/Lisp. It's quite interesting, and its a positive for .NET in many ways. You can get stuff done, and also come in on a project and it be familiar.

I think this reflects the enterprise culture and auditing practices more than anything