Yes, I would have wanted to see a decent stdlib to be a goal for 1.0.
I recently wrote a 10 line script that had to work with date arithmetic *, and while importing URLs is pretty cool, it still was the same shit of spending 80% of the time it took to write the code browsing and evaluating multiple third party date libraries to find one good enough for my use case. So in practice the only improvement Deno had over Node in that example was that I didn't have to run `npm install`. Yay, great.
*: adding two dates together, converting to and from UTC, given a Date find the next midnight. And as expected the most popular JS library couldn't even get one of these simple tasks correct, there's a bug report open since 2017. Incredible stuff from this ecosystem.
I have yet to find a datetime library in any language that was adequate for all purposes I've needed. That's not a particularly damning example in my opinion. I've had to write very weird datetime code in JS, Python, and Ruby. I don't even want to imagine the horrible things you could find in some other languages.
In Java, Joda-Time was a third party library for ages. It was the dominant date-time lib for enterprise development. Then, it was standardised and added to the stdlib: java.time (JSR-310). The Joda-Time project lead, Stephen Colebourne, ran the standardisation process. It was well received by most, even the breaking API changes that SC was adamant were flaws in the original Joda-Time API. I can vouch for it: Both Joda-Time and the java.time libs are excellent. (In my job, I regularly need to perform complex date-time transformations, including time zones.)
I have also used Howard Hinnant's C++ date-time lib: https://github.com/HowardHinnant/date It is also very good. (He was the guy behind move semantics in C++ 11.)
In Python, the stdlib has a function to get UTC now, that does not include UTC timezone... so it weirdly and surprisingly acts like local time zone! There is endless shit-posting about it. I feel bad for Guido van Rossum et al. To be fair, the original Java date-time lib was horrible, so Joda-Time was created. And JDBC (Java database) dates are still horrible.
There is a difference however between "Does all the things my snowflake app needs" and "does the top 20 most common things". The latter is easy, and even quantifiable if you have the time (to scour open source repos for use cases). When you write dozens of utilities, a few libs, and several apps, its likely the common date time use cases will be suitable for 80% of them. Rinse and repeat across numerous other dependencies, and the result is a std library you learn once, that serves 80% of your use cases just fine. Its not about no dependencies, its about dependencies focused on novel or niche problems, not common and already solved ones.
I recently wrote a 10 line script that had to work with date arithmetic *, and while importing URLs is pretty cool, it still was the same shit of spending 80% of the time it took to write the code browsing and evaluating multiple third party date libraries to find one good enough for my use case. So in practice the only improvement Deno had over Node in that example was that I didn't have to run `npm install`. Yay, great.
*: adding two dates together, converting to and from UTC, given a Date find the next midnight. And as expected the most popular JS library couldn't even get one of these simple tasks correct, there's a bug report open since 2017. Incredible stuff from this ecosystem.