Rust beginner notes & questions

[BatmanAoD]

I've read through this thread [edit: most of it; see below] and the blogpost about the Pipelines interface, and I'm not quite sure I understand your current position on the stream-vs-pipes issue, @peter_bertok.

@peter_bertok

PPS: I take it all back, I just had a play with the C# Pipelines API, and it turns out that it is not template based, its data stream is always made up of bytes. I was tricked by seeing SomeClass<byte> in code samples, but that’s just code reuse. The API itself does not generalise to other value types such as char or whatever. Sigh…

In light of this addendum:

• Do you still think the Pipeline implementation in C# is an example of what you'd prefer to see in Rust?
• Since Pipelines are implemented in C# with byte-streams, do you still think the Pipe concept is incompatible with a byte-stream API in principle?
  • You mentioned downthread that you were "wrong...[that Read2 is] inherently incompatible with what's already there," but you went on to say that you would expect Read to be implemented using Read2 (and gave the code for this implementation), not the other way around.
  • Since the C# version of your preferred API is implemented using bytestreams, but you think that's the wrong approach, can you provide an example of an IO pipeline implementation that doesn't rely on bytestreams, or flesh out your ideas for how such a thing could exist? It doesn't seem to me that you've fully addressed the point upthread (unfortunately I can't find the quote) that everything in memory really is byte-based at the lowest level, nor @BurntSushi's point that any implementation of the Pipeline API will necessarily require a large internal buffer that the client can't control.

In short, do you still think that Rust has taken a "wrong turn" that will have permanent negative repercussions that can't be solved without a major breaking change (comparable to e.g. the change in byte/string handling in Python 3), or are you just concerned that the standard library is too "thin" compared to more "batteries-included" languages?

[Edit: this is much the same as @vitalyd's question a few posts up, which was written after I began composing this post.]

@peter_bertok

• Turns out templates are hard! They need all sorts of restrictions such as being constrained to value (copy) types, types that implement a particular API, and so forth. The C++ guys are still trying to work this out. Rust has had this since before v1.0 via Traits. <- You are here
• At some point someone realises that with the advances made in step #4, a lot of APIs can be rewritten to be vastly more elegant. “Obviously”, making things like Stream a lightweight synchronous wrapper around a byte-only file descriptor was a mistake , so now the entire language is slowly reinvented piece by piece, leaving an absolute mess of incompatible APIs next to a bunch of legacy garbage. Modern C++, dotnet core 2.x, and Java 10 are here now.

This is a fairly minor point, but I'm a bit confused by your "placement" of various languages.

• It seems like you're saying that Rust "skipped over" the first four issues, but hasn't adequately addressed the fifth. So would it be more accurate to say that Rust is "in between" issues 4 and 5, rather than "on" step 4?
• I'm familiar with C++14 but don't know as much about C++17. What (if anything) is C++ doing to address this issue? (I agree that in the general case, C++ has a major "legacy garbage" problem, but I'm unaware of anything like the Pipeline API in the C++17 standard library.)