Continuing the discussion from (spectacular) failure of abstraction, compile times, and toolboxes vs thin stdlib :
A quote from the second linked post:
expHP:
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 self-sustaining.
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 is still hope for having such a feature in the standard library. But in general?
I see people reimplementing identically named but incompatible traits as a failure: dual_num::Zero - Rust
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-encompassing implementations for things, b…
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 this blog .
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…
This discussion revolves around whether the Rust standard library should contain more features. Central arguments of @peter_bertok are:
I see people reimplementing identically named but incompatible traits as a failure: dual_num::Zero - Rust
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-encompassing implementations for things, but I do feel that it needs to authoritatively and centrally define core traits and a decent set of data types, not just thin wrappers around whatever is provided by LLVM.)
Please take a quick look at the Diesel crate’s cargo.toml dependencies.
This is a top-shelf library, but they were forced to depend on piddly little libraries for all sorts of basic stuff that absolutely does not belong outside of std. Numbers. Bit manipulation. GUIDs/UUIDs. Temp directory. Time. Urls.
Are you seriously saying that in 2018 it’s okay for a new programming language just barely out of 1.0 to not include a UUID type!?! Seriously? They’re everywhere: in file formats, protocols, APIs, and of course databases.
You have no idea how many “enterprise” databases I’ve seen with “nvarchar(36)” columns storing the text-representations of GUIDs for one reason, and one reason only: Java didn’t originally include this type in their core library. Oops. Now there’s thousands of databases out there with 74-byte primary keys because of that mistake.
My takeaway point is this: small mistakes or omissions in standard libraries and language design have an enormous multiplying factor in their cost to society. Thousands of developers write millions of applications with billions of users.
A small convenience for the language designer can cost literally billions of dollars down the road.
bgeron
July 18, 2018, 10:27am
3
Yes. UUIDs are not required for many useful Rust application. Ripgrep is one of them. We should celebrate that the language's designers have been modest and didn't err on the side of putting too much in the standard library.
1 Like