I did not mean to suggest that crates.io is "bad". It's obviously quite useful. It's just that I would like it better if there were some kind of systematic review of newly submitted packages by someone other than their authors, and I would like rust better if its standard library included a random number generator.

I would suggest that Debian is quite good, and is indeed something special, but that's another story.

Debian (and other "community" distros) is distributed collaboration, not an organization in the sense you're describing. You're trusting a scattered large number of individuals (some anonymous), infrastructure, and processes. The individuals themselves change all the time. The founder of the whole project is not even still with us for example.

Not only the processes did nothing to stop shipping the already mentioned xz backdoor (malicious upstream). But the well-known blasé attitude towards patching upstream code without good reason within some Debian developer circles actually directly caused Debian-only security holes in the past (If you're young, check this XKCD and the explanation below it). And it just happens that it's the same blasé attitude that ended up causing the xz backdoor to affect PID 1 (systemd) in the first place. While that particular malicious attack wasn't effective/applicable in distros that don't have such an attitude in their "culture" (e.g. Arch).

On the other hand, other Debian developer(s) were the first to put a lot of effort into making reproducible builds a thing. That was a good invaluable contribution.

So there is good, and there is very much some bad. But overall, Debian is nothing special in the world of "traditional" binary distros. But in any case, it's the stipulation "trusting an organization because it has a long track record of being trustworthy" in the context of Debian that would be weird.

(The "stable distro" model of shipping old patched upstreams itself is problematic, but this comment is too long already.)

crates.io is 10+ years old upstream-submitted repository of language-specific source packages. It's both not that comparable to a binary distro, and happens to come with no track record of own goals. It can't come with own goals like the "OpenSSL fiasco" in any case, because the source packages ARE the upstreams. It is also not operated by any anonymous people, which is the first practical requirement to have some logically-coherent trustworthiness into an individual or a group. Most community distros can't have this as a hard requirement by their own nature, although top developers and infrastructure people tend to be known. But it takes one (intentionally or accidentally) malicious binary packager...

You don't seem to have a coherent picture of a threat model, or actual specific factualities about Debian, or crates.io, or anything really, in mind. Just regurgitations about "crates.io BAD" that have been fed mostly by non-techies to non-techies.

Trusting an organization because it has a long track record of being trustworthy is "invalid"? You guys are pretty weird.

So, we established that "pulled in from the interwebs" is not a valid differentiator.

which has existed for much longer than has crates.io

True and irrelevant/invalid (see below). Among the arguments that could be made for <some_distro> packages vs. crates.io, age is not one of them. And that's before we get to the validity of such arguments.

In this case, it is also an apples-to-oranges comparison, since Debian is a binary distro, and crates.io is a source package repository. Which one is "better", if we were to consider this aspect alone, is left for you to ponder.

and has had fewer malicious packages get into it.

The xz backdoor was discovered on a Debian Sid system, my friend. Can you point to such "malicious packages" that actually had valid users/dependants on crates.io?

which has existed for much longer than has crates.io

The Rust compiler has not existed for as long as the debian package manager has. You're still trusting it and its standard library even if your reason for trusting it is that Debian's maintainers trust it. This is also true of any vetted dependencies you download. You're trusting others at the end of the day, whether they are the package developers or the auditors. Only by auditing your dependencies yourself can you avoid trusting anyone else.

With that being said, you are also able to contribute here. Someone has to do the auditing. Go audit some packages!

I got the compiler and whatever comes with it from the debian package manager, which has existed for much longer than has crates.io and has had fewer malicious packages get into it.

How long did it take you to audit the source code for your OS?

Why do you keep making these "no context" posts?

They read like random gibberish.

fastrand has zero dependencies.

And all external dependencies are "pulled from the interwebs" nowadays (in source and/or binary form), irrespective of language. This includes core, alloc, and std, which are crates that came with your compiler, which you pulled from the interwebs.

They may not have been formally vetted, but they are in the sense that the majority of those 200 crates are used widely in everyone else's projects.

But yeah, this is definitely a blind spot, not just for rust, but all modern build systems that accept code from various sources. At least cargo vet is a step in the right direction.

What a nifty idea! Nice job <3

As usual, everything on US infrastructure. Only Github is supported, no other avenues for funding. @rust@social.rust-lang.org how about liberapay or other alternatives?

Expand.

The never type comes more from type theory and isn't common in other languages (though TS has never). Similar to 0 or the null set, it exists as a "base case" for types. For example, where you have unions of T1 | T2 | ..., the "empty union" is the never type. Similarly, for set theory, a union of no sets is the null set, and in algebra, the summation of no numbers is 0.

In practice, because it can't be constructed, it can be used in unique ways. These properties happen to be super useful in niche places.

I guess it makes sense. What I struggled with is, as the type is unusable basically and I didn't like the idea it being a type. But for documentation reasons, it makes sense. Otherwise, it has no practical meaning. Even a comment could have the same effect.

Because if it never returns, then it has no return value.

Then how would you annotate having no return value?

use core::convert::Infallible;
fn can_never_fail() -> Result<(), Infallible> {

Judging by recently discovered use of unwrap this might be a trap for some ;D

To me it makes no sense. Because if it never returns, then it has no return value. Therefore it makes no sense to have a type for something that does not exist.

I don't know where None comes from (what's the T in Option<T>?)

Assuming you meant (), that's a unit type with one valid value. It's a ZST, but can be created and returned.

! is a bottom type. It's uninhabited. Can't be created. Functions can never return it because they can never construct it. So why's this useful? It can be coerced to any type.

Because the set of valid values for ! is the null set, by contradiction, there do not exist any values valid for the type ! that are invalid for any other type T. Therefore, all valid values of ! are also valid values of any other type T, and you can always convert from it to any other type.

Notably, this is already possible, but language support for it isn't amazing:

enum A {}

fn bar(a: A) {
    let foo: Box<Arc<Rc<Mutex<String>>>> = match a {}
}

Heck you can even do this today:

// `loop {}` never returns, so its type is `!`:
let blah: String = loop {};

I think you're misunderstanding the never type. The never type is not a hack at all. It's a very natural part of the type system. Just as you have the unit type (), which is the canonical type with only 1 value, you also have the never type, the canonical type with 0 values.

This is extremely useful in generic code. See my other comment in this thread.

This is an unfortunate wart to appease a desire to those that want to be able to write code like they do in legacy languages

What do you mean with this? I can't really decipher it. What alternative to the never type would you want?

Right, so you can't "enforce" a return from the function.

If it never terminates, then it means it runs forever.

shouldn’t Rust enforce returning from function

This is impossible. How would you enforce that? What prevents a function from panicking, aborting the whole process or just going into an infinite loop? All these things correspond to the never type.

I think you're misunderstanding what the never type is. It's not equivalent to None at all. It's a type that doesn't have any values. This is useful in situations with generic code where for example an error type can be chosen as the never type. Then you could destructure or unwrap a Result without handling the error, cause the type system guarantees the error never occurs.

I think you should read up on the never type a bit more. It's a perfectly natural part of the type system. In fact you can make your own very easily: enum Never {}

shouldn’t Rust enforce returning from function

How do you enforce returning from exit or a function with a loop that never terminates?

It's because they wanted to hack control flow functionality into expressions. Returning None is actually returning something, but never is just a placeholder for any type when they want to do things that may exit the expression entirely. This is an example in the docs

let num: u32 = match get_a_number() {
    Some(num) => num,
    None => break,
};

Break exits the expression without ever producing a value.

This is an unfortunate wart to appease a desire to those that want to be able to write code like they do in legacy languages. There should have been better ways to do this without being a hack IMO