suggestion: re-consider the deprecation of read()/write() methods and std/io

[iuioiua]

The Deno.Reader interface and friends are deprecated in favour of the Streams API, pending removal in Deno v2 (see #21465). However, classes that implement these interfaces (e.g. Deno.FsFile and Deno.Conn) are supposed to be keeping their read() and other related methods (see #21701). There are pros and cons to either keeping or removing these methods.

Should we keep read(), write() and friends? These methods are fast, easy to use, and easy to understand. This is more than likely why devs use them. However, keeping these methods means we have two means of interacting with IO when there's also the Streams API. This incurs an engineering cost. Arguably, read(), write(), etc., are simple enough that their maintenance within the runtime is minimal. If so, we should reconsider the deprecation of std/io, as the sub-module validly justifies staying around.

Or should we remove read(), write() and friends? This would likely cut engineering costs and focus efforts on making the Streams API faster and easier to use. There'd likely be some unhappy devs with the decision initially, but such engineering efforts over time may counteract that, especially from developing helpers in the Standard Library (i.e. std/streams). The drawback is that we lose a simple means of interacting with IO.

To be clear, I'm not strongly for or against doing either. I'd like to outline the pros and cons, including those related to std/io.

[bartlomieju]

If you're discussing read() and write() methods on various classes then yes, we should keep them (otherwise it would be a huge breaking change and I know @dsherret especially would like to keep them). But it should only be these methods that are directly on the classes - we want to get rid of all the methods/API that accept a "resource id" (rid).

[iuioiua]

Ok. I realise read() and write() methods are here to stay. Closing in favour of denoland/std#4120.