5 ms·

The culture of the programmers comes into it too. In the Java/.NET world devs are happier to take what the core libraries provide. A case in point is how the O

The culture of the programmers comes into it too. In the Java/.NET world devs are happier to take what the core libraries provide. A case in point is how the ORM Entity Framework that comes with .NET has made the older NHibernate (a separate package) obsolete. .NET developers love using the standard libs, but OTOH Microsoft has a lot of resources to create very complete libraries.

chc 7y ago
Even in Java, if you're looking to do anything with dates, everyone will tell you to use Joda-Time over java.util.Date.
- darksaints 7y ago
  That's true if you're still on Java 7. java.time.* is the go-to now, and it is very high quality.
- sanderjd 7y ago
  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.
  - bluejekyll 7y ago
    But won’t the community converge on that anyway, and in a similar amount of time? So why add it to the stdlib?
    - quantummkv 7y ago
      Stability? Guarantee that the api will continue to work and that no one will wake up one morning and left-pad the entire ecosystem?
    - sanderjd 7y ago
      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.
      - steveklabnik 7y ago
        There are libraries that are maintained by the project itself, but are not part of the standard library, yes.
        sanderjd 7y ago
        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?
        steveklabnik 7y ago
        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.
        raphlinus 7y ago
        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.
        steveklabnik 7y ago
        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 :)
    - erik_seaberg 7y ago
      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.
    - tikkabhuna 7y ago
      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.
- pjmlp 7y ago
  Only if one is stuck in pre-Java 8.
stackzero 7y ago
I think this reflects the enterprise culture and auditing practices more than anything
stuartd 7y ago
> .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 https://github.com/microsoft/botframework-sdk/issues/938 [2] http://www.nhforge.org/doc/nh/en/index.html http://www.nhforge.org/doc/nh/en/index.html [3] https://ayende.com/blog/4139/nhibernate-documentation https://ayende.com/blog/4139/nhibernate-documentation [4] https://stackoverflow.com/questions/tagged/nhibernate https://stackoverflow.com/questions/tagged/nhibernate
- quickthrower2 7y ago
  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.
GordonS 7y ago
> 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.
tjalfi 7y ago
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 https://mcfunley.com/choose-boring-technology

chc 7y ago

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

darksaints 7y ago
That's true if you're still on Java 7. java.time.* is the go-to now, and it is very high quality.
sanderjd 7y ago
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.
- bluejekyll 7y ago
  But won’t the community converge on that anyway, and in a similar amount of time? So why add it to the stdlib?
  - quantummkv 7y ago
    Stability? Guarantee that the api will continue to work and that no one will wake up one morning and left-pad the entire ecosystem?
  - sanderjd 7y ago
    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.
    - steveklabnik 7y ago
      There are libraries that are maintained by the project itself, but are not part of the standard library, yes.
      - sanderjd 7y ago
        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?
        steveklabnik 7y ago
        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.
        raphlinus 7y ago
        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.
        steveklabnik 7y ago
        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 :)
  - erik_seaberg 7y ago
    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.
  - tikkabhuna 7y ago
    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.
pjmlp 7y ago
Only if one is stuck in pre-Java 8.

stackzero 7y ago

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

stuartd 7y ago

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

quickthrower2 7y ago
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.

GordonS 7y ago

> 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.

tjalfi 7y ago

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 https://mcfunley.com/choose-boring-technology