Why no gcd in standard lib?

gcd is so ubiquitous, and frequently used, and part of every
other language I have regularly used

I've never needed it.

Or to be a little less glib about it, your experience of programming is not the entirety of programming, and in many domains, gcd is either not relevant at all, or only relevant in certain subdomains that are already wrapped away in more directly relevant libraries. I've never needed gcd, but I hardly ever start a project that doesn't need to parse JWTs.

You also make a direct correlation between "developer happiness" and "available out of the box." As a long time python developer, I'm rarely less happy than when I'm trying to connect to a web server using the "available out of the box" urllib. Requests is better, easier to use, readily available, and known to basically everyone in the community who deals with HTTP services. The python standard library is full of cruft that nobody uses or wants to use anymore.

Why is Option in std, and not gcd? Option is part of the public interface of most rust projects. If there were multiple implementations of Option, you'd need converter functions to get from type to type when dealing with multiple crates. If you have six dependencies that each use a different implementation of GCD, you won't notice or care, as long as they're all correct.

You found a community of people who help with rust problems. All you had to do was say "hey fam, is there an easy way to do a gcd?" Then you know about the crate, and your developer happiness continues.

Don't get me wrong. I hear you. You like batteries-included standard libraries. Rust doesn't have one, and it's not going to have one. Not because of ideological purity, but because we've seen the problems they cause, and don't want our language to go down that road. If that's a dealbreaker for you, that's okay. There are other languages out there. But maybe give rust a little more of a shot. I think you'll find that the community is very thoughtful, and the bulk of the design decisions the community has made have made for a very positive developer experience.


Is GCD worthy to include in std? Definitely yes, for it is well defined, frequently used and fundamental.
Is GCD including into std the matter of absolute necessity? Definitely no, for a custom (basic) implementation is pretty stright forward and takes as long as 3-4 stings of code.
The situiation reminds me debates about including sqr function into standart library....
I really missed both of them (GCD and sqr) in C, and i wrote them up countless times.
Does it (missing) breack my back? - Of course - NOT.. but I am still missing them...
Should somebody to take in account opinion of person so humble as me? May be NOT...
But wise men should remember that the solution of Niklaus Wirth to keep Oberon's std library so primitive and simple as possible (only for purity and size reasons) put his language popularity to the grieve end...


This is the kind of reply that earns the Rust community its reputation. :heart:

.. and this is the kind of helpful comment that would have skipped a whole lot of emotional debate and frustration if it had been among the first three. :heart:

I see a whole lot of well-meaning technical background explanation, that is only serving to frustrate @jzakiya because we are effectively implying "what you want is wrong", which isn't the inclusive, positive atmosphere we want to encourage.
It's also frustrating the kind rustaceans trying to explain, because the point isn't coming across. :frowning_face:

@jzakiya , this is where rust (partially) disagrees.
We believe that programmer happiness comes from an empowered community, where every person is free to choose the very best implementation for their tradeoffs, now and forever.
We believe that forcing this decision now, once, in the form of a top-down "this goes into std and stays there forever"-decision, results in more long-term frustration and accumulated dead code.

We understand this loses some convenience, because we now must think about dependencies, instead of picking whatever is in std.
In true Rust "have our cake and eat it too"-style, we try to make this thinking-about-dependencies into something positive, by having the best dependency system anywhere: crates.io and cargo.

For most common functionality, you only need to type a keyword into crates.io, and the Rust-world's best implementation is at your fingertips.

If you replace "standard build (by ruby team)" with "pick what you want/need (from crates.io)", you have the Rust Idea :smile:


To build on implied points here:

You're most likely going to need an external crate for whatever you're doing anyway, so having to get an external crate for gcd isn't going to be a huge inconvenience. You probably need external crates, and so it's no problem to grab one for gcd. The chances of only wanting gcd and no other crates seems incredibly small to me.


exactly so! But it (such package(es)) must be encluded into shiping bundle and governed by rust team (not community members!)

Rust is an open source project; most contributors, including to the Language and Compiler and Infrastructure teams, are unpaid. Why do you feel it's necessary for a "Rust team" to be burdened with maintaining other crates? If so, which team should carry that load?

It's not a language issue, so the Language team seems inappropriate. It's not a compiler issue, so the Compiler team seems inappropriate. It's not infrastructure tooling, though crates.io is part of the larger non-tools infrastructure, so it seems somewhat inappropriate to burden the people responsible for Cargo, Clippy, Rustfmt, Rustfix, and the other tooling ancillary to rustc.

In practice with Rust, it is the responsibility of those people who have signed up as Contributors to a crate to maintain that crate. That approach distributes the maintenance load across the ecosystem, rather than heaping it all on a few already-overburdened people, most of whom are volunteers.


I mean "high quality dedicated long time support guarantee"+ it must be included in main documentation bundle.

You'll have to contact the authors, then. I doubt anyone will give you a guarantee without getting paid. Correct me if I'm wrong, but not even Rust offers you any guarantees (in a legal sense), neither about the language nor about the core and standard library, AFAIK.


Moderation node: The back-and-forth bickering isn't terribly constructive. I think the OP's initial question has been thoroughly answered. So I'm going to close this.