Yep that is the intended Deno standard modules -- the goal is to have a standard library large enough to cover most use cases (and that this standard library would not depend on external sources), while making sure that it is independent from the Deno binary to avoid bloat and allow choices (you can definitely implement your own alternatives)

Sounds a lot like Python with its standard library, eq. "batteries included".

They also note most of it is a loose port of Go's standard lib, which is quite good imo.

Go's stdlib mistakenly sorted files by default on directory walks(with no option to not sort them). This of course means a directory must be fully iterated on before you can process or bail out of processing. I wonder if Deno ported this directly or reworked it.

There are some other issues with file stats as well; requiring multiple syscalls to retrieve information that can be had in just one.

It's a mystery to me why they made such a high level decision in such low level code without an escape hatch.. Been a lot of talk but probably won't be fixed any time soon due to backwards compatibility.

> with no option to not sort them

Just implement your own directory walk based on `readdir` or whatever fs operations you need directly.

Or use a library that has already done this: https://github.com/karrick/godirwalk#configurable-sorting-of...

The high level interface made one choice. The escape hatch is to use a lower level interface.

readdir is problematic in ways godirwalk works around.

Of course one could always just make direct syscalls or use a library that does, but this was a comment about stdlib. These would likely be implemented differently in hindsight per discussions on the Go project; and there have been discussions about improving them somehow in Go 2(readdir2?).