Fat Rand: How many lines do you need to generate a random number?
lucumr.pocoo.org
lucumr.pocoo.org
> Now this is a bit misleading, because like many times most of this is within windows-. But how much of windows- does getrandom need? A single function.
See also the Azure CLI. There's a github issue, still open, from 2018 complaining about their 350 MB monstrosity bloating up a docker container. By now the thing weighs more than 1.5 GB. Fucking MS.
Systems are like babies: once you get one, you have it.[a.] They don’t go away. On the contrary, they display the most remarkable persistence. They not only persist; they grow. And as they grow, they encroach. The growth potential of Systems was explored in a tentative, preliminary way by Parkinson, who concluded that Administrative Systems maintain an average rate of growth of five to six percent per annum (corrected for inflation) regardless of the work to be done.
- from Systematics by John Gall
0. https://en.wikipedia.org/wiki/Junk_DNA (Well aware of how “junk” DNA is linked to functions elsewhere, and that the subtleties involved represent an evolutionary aggregation equivalent to why acli is 1.5G.)
In theory that would not be necessary any more on more modern rustc versions, but if you want to target rustc < 1.70 you still need that.
(Disclaimer, I didn’t work anywhere near this, and am just making up a guess).
“Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.”https://www.reddit.com/r/ProgrammerHumor/comments/6jw33z/int...
EDIT: It's gotten even worse in the last 6 years!
I recently ripped out the rand crate and replaced it with some much simpler code ported from a C++ codebase. Still does what I need it to do but way fewer LOC and way less complexity. Is it as flexible as what rand and related crates offer? Maybe not, but that flexibility comes at a cost.
Windows-sys is necessary for w Windows OS kernel, libc is similar thing for *Nix, cfg-if is necessary for specializing targets per OS, arch, or SIMD capabilities.
Biggest offender is honestly zerocopy-derive. Which pulls in most dependencies.
On the article, two random thoughts:
- I like that the Rust standard lib is "tiny" and a lot of stuff is delegated to third-parties crates. I wish crates support namespaces (for instance std) so it's easier to see what dependencies are blesser. For the moment, you can obtain a good name, like http, and squat it forever (http being just an example, don't know if there is an actual crate)
- when you vendor a Rust project, does it vendor also the flag dependencies? For instance, Rand is dependent on Serde because of an optional flag for serializing a random generator. Serde loc should be ignored in that case if we count the code lines.
That being said, I simultaneously think the concerns are slightly overblown on the safety part. Having stable pillar crates that everyone builds around is a good thing not a bad thing. The build issues for things like that should be solved at the language/tooling level (e.g. pulling in a crate for 1 function should be trivially cheap) while relying on the network effects of auditing the components (i.e. it’s OK to rely on a crate with a stronger chain of trust than you have yourself).
* To be fair, they call out alternatives that you might find more appealing, but the type and module system being what it is (+ the name rand being so concise and appealing when you come at it with a first glance), it becomes the de facto standard.*
EDIT: it's a similar situation to general purpose allocators. If you know you can use a simple one, it's orders of magnitude less code and complexity than a general one.
You can use getrandom directly.
getrandom v0.3.1 ├── cfg-if v1.0.0 └── libc v0.2.169
Do you happen to also know if there is any ongoing work in rustc to make compilation faster for this situation?
I’m imagining that one could typecheck and then see if ASTs are used / unused and eliminate them before generating code. Maybe that would speed up compilation? Perhaps this is already being done.
There still is:
R. R. Coveyou, R. D. MacPherson,
"Fourier Analysis of Uniform Random
Number Generators", Journal of the
ACM, Volume 14, Issue 1, Jan. 1967,
Pages 100-119.
i -- a positive integer
ip1 -- a positive integer
Set i = 1
Do Forever
Set ip1 = i * 5^15 + 1 mod 2^47
Return(ip1)
Set i = ip1
End let invocations = 0;
export function rand3000() {
invocations += 1;
const timestamp = new Date().getTime() + invocations * 1000;
const masked = (timestamp ^ (timestamp >> 8)) & 0xFF;
const result = masked / 255;
return result;
}If this kind of insane dependencies for such a simple thing is common practice in the Rust ecosystem then the language is in a lot worse place than I imagined it to be.
Listen, I'd be as happy as anyone to have random numbers in the Rust standard library. Compared to the Rust developers, I'm a believer in stdlib maximalism, downsides be damned. But all this recent hand-wringing about dependencies is a tiresome moral panic.
If there weren't real costs to dependencies then I personally never would have published regex-lite.
The OP isn't addressing the real costs of dependencies, the moral panic in question is the automatic assertion that more dependencies is worse than fewer dependencies, which implies that e.g. all the work you have done to cleanly separate regex out into reusable regex-syntax and regex-automata crates has done a disservice to your users. There are real arguments to be made about wrangling one's trusted computing base, but this isn't making that argument, and by throwing the baby out with the bathwater it sets us back as a profession.
Sorry, what? The section on "Compilation Times" is absolutely a real cost!
> the moral panic in question is the automatic assertion that more dependencies is worse than fewer dependencies
I agree that is a moral panic, but I disagree that Armin is indulging in that assertion.
function rand() {
return 4;
} function rand() {
return ++4++;
}I'm not surprised. Reddit is a cesspool