Continuing the discussion from
(spectacular) failure of abstraction, compile times, and toolboxes vs thin stdlib:
A quote from the second linked post:
We are all at risk of adopting an apologist viewpoint on missing features.
…and it is at this point that the absence of something in the standard library may become
How can this be prevented? I don’t know. Identifying and challenging one’s own cognitive biases is not easy. Sometimes somebody motivated appears and smacks whole the rust community with a harisen, writing an epic blog post to remind us all that
yes, there But in general? is still hope for having such a feature in the standard library.
I see people reimplementing identically named but incompatible traits as a failure:
I know that sounds harsh and nit-picky, but I feel that it’s a sign of things to come. This kind of thing will inevitably get worse as a consequence of stripping low-level abstractions out of std. The missing wheels will be reinvented, and it’s going to be a huge, incompatible mess.
(To clarify: I’m not generally advocating for std to include all-encompas…
This is what I imagine the story to be behind a lot of things that were stripped pre-1.0 like std::num::Zero.
Stabilization affects the language
At some point in time, the feature existed. However, there were things about it that were simply not as nice as it could be:
perhaps the best design was still unclear; it needed further experimentation and design iteration.
perhaps rust was missing critical language features to make it ergonomic (or these features existed and were buggy/unreliable),…
I’m curious if you’ve been able to get over your std::io::Read gripe and look at Rust some more, beyond your initial post in this thread.
I also think it’s incredibly unrealistic to expect a language and/or its stdlib to be flawless, regardless of how many have come before. Doubly so if you actually intend for people to use it rather than sit in someone’s imagination.
Branch to Stream API and types on implementation details mentioned in the following post.
First of all, I have to say that ripgrep is impressive work!! I’ve used it just recently because it smokes everything else if you need to trawl through gigabytes of data for a keyword.
The whole argument I’ve been trying to clumsily make above is that your hard work for things like BOM detection and encoding switching should have been built-in to Rust and not a part of the ripgrep codebase. At the end of the day, what you’ve written is a single-purpose tool, but large chunks of its codebase loo…
I think what might help here (as others have said) is some concrete code demonstrating what you want. I know I’m confused. It seems you have pointed out examples of what Rust should be doing, like C# Pipes, then only to back-track and say that no, that isn’t what you thought it was. I think everyone (I know I am) confused by the insistence that it must be in core or std instead of on
crates.io. I think the idea of a “Fat Standard Library” is wrong for a number of reasons (especially at this stag…
I’d like to point out that Microsoft has been heavily investing in the last few years in extracting things out of stdlib and into nuget packages, heavily because they were not happy being tied to monolithic .net framework releases just to iterate on an API. So I’m not even sure how much they would even agree that having a fat stdlib is good.
Afaik pipelines isn’t planned to be placed in stdlib, but will instead be kept in a nuget package that can be included if the application/library wants to…
Interestingly, things like “EntityFramework” are Nuget packages, not in the standard lib.
.Net core, the latest incarnation of .Net, is entirely made of up of small, modular Nuget Packages, not dissimilar from Rust’s philosophy with the stdlib. See the section “NuGet as a first class delivery vehicle” in
I think the case you lay out for read2 over read is compelling in the sense that an API like read2 needs to be created for Rust. It may even need pushed into the standard library at some point, and read reimplemented in terms of read2 at some point. That being said, I don’t see why it isn’t entirely appropriate to create and iterate on such an API on
crates.io and only once the kinks are worked out worry about whether or not it belongs in the standard library.
As has been pointed out, even C# w…
Read below post with regard to hex encoding and macros in stdlib; else branch to
Does Rust have severe shortcomings.
Now that I’ve toyed around with my pseudo-code of what it might look like (Read2), finding real issues (the avoidable mmap-related error in ripgrep), and realising that zero-copy is the future (NVDIMM), I feel like something akin to System.IO.Pipelines is necessary.
I’m not at all saying that it’ll look exactly like my Read2 sample, that’s just me doodling. A realistic example would probably have 3 to 4 low-level traits in some sort of hierarchy. It would obviously have to handle both read and…
Ah, okay, that sounds like a substantially different complaint than the one about streams/pipes. So are you no longer concerned that the existence of a stream API is fundamentally a mistake? (I understand you still prefer the “pipe-like” API and think it’s a fatal flaw for a language not to support it in the standard library, but I don’t see a connection between this and wishing that streams didn’t exist.)
I’ve heard the argument that macros increase compile time, but I’m not sure if it’s supp…
As if everything you said wasn’t enough already, I think it’s worth saying that these three points are often just as true of standard libraries as they are of third-party libraries.
For 1 and 2, the people that control what goes into a standard library are usually also spending a lot of their time on the core language, while a 3rd party library maintainer is much more likely to be spending all their coding time maintaining just that library. Like how serde replaced rustc_serialize.
For 3, I’m…