Comment by throwawaaarrgh | Hacker News Reader

Comment by throwawaaarrgh | Hacker News Reader

"Rust screams at you all day, every day, often about things that you would have considered perfectly normal in another life."

A good C compiler does this when you turn on all the flags. I like languages/compilers that let you selectively disable the screaming and let you write bad code on purpose. Bad code that works but can be written fast is often better than perfect code that takes forever to write. Once you have a bad but working POC, you can make it less bad.

"It’s got no problem attracting new users, but it’s not resulting in dramatically improved libraries or tools. It’s resulting in one-off forks that handle specific use cases."

Age has nothing to do with that. Attracting core devs is hard, and putting lots of effort into making it attractive is necessary. On top of that, cultural conventions are set by the early adopters, and a lack of convention is often just as sinful as a bad existing convention.

Take Python for example. They took a lackadaisical approach to development and runtime environments, and as a result there's 50 competing ways to develop or run a Python program. Their most-used package repository, PyPI, has been a mess for years. Nobody builds on top of existing packages, names make as much sense as a random word generator, the ecosystem is rife with malware, you can't even search for a package on the command line, etc etc. None of that is the language's fault, it's the community and core team's fault for sitting on the sidelines rather than leading. Culture matters more than the tech it's centered around.

(I'm not trying to pick on them, I just know their problems better. C has been around for a half century and its community never really put together half the solutions more modern languages did)

> A good C compiler does this when you turn on all the flags. I like languages/compilers that let you selectively disable the screaming and let you write bad code on purpose. Bad code that works but can be written fast is often better than perfect code that takes forever to write. Once you have a bad but working POC, you can make it less bad.

Rust supports that. Just mark everything unsafe.

That doesn’t turn off the overwhelming majority of Rust’s soundness checks. `unsafe` isn’t a magic “let anything fly” switch.

That doesn't really work. All unsafe lets you do is dereference pointers or call unsafe functions. That's not gonna speed your development up during prototyping.

You can instead wrap everything in Arc<Mutex<T>> and .clone() liberally, though.

Always find it funny that people think unsafe {} means that rust ignores everything in the block, it just enables 4-5 additional abilities that are well documented, it's still doing most of its safety checks.

It will work if you only use raw pointers everywhere, like it's C. Don't use slices or strings; just pass a pointer to the first element of an array, and either pass its length separately or provide a sentinel value (like C's null terminated strings). Navigate balanced search trees using aliasing, raw, mutable pointers. Etc. This person compares the translation of C to Rust, literally versus idiomatically: https://cliffle.com/p/dangerust/

There will probably be weird behavior, though, because Rust optimizes based on assumptions about boxes and references. For example, if you have 3 raw pointers to some object live at once, and you give some library function a mutable reference made from one of those pointers, the compiler will optimize assuming it has exclusive access to that object, and it may make incorrect assumptions.

> All unsafe lets you do is dereference pointers or call unsafe functions.

And all those let you do is drop lifetimes and wave goodbye to the borrow checker. You just have to be explicit about it.

(What I mean is, the borrow checker checks borrows, it checks references. In unsafe you can make a reference forget what it's referring to. Just change &'a T to &'static T, and then the borrow checker is doing nothing.)

"Just mark everything unsafe" seems to be the motto of many (most?) crate developers. There's so much "unsafe" in dependencies used by so many Rust programs. It's a timebomb waiting to go off.

80% of crates have no unsafe code in them.

So only 1/5 of Rust code is unsafe? Isn't safety, like, the point of the language?

No, 1/5 of Rust code contains unsafe directly. Also, "the" point (in the area of safe/unsafe) is to manage unsafety and provide safe abstractions from unsafe foundations. If you go deep enough there's always something which will be unsafe (the type system would have to able to proof the whole universe otherwise), but most programmers will not have to write such code themselves (no, most of use do not write double-linked lists each day) - they can just use it (e.g. by using the standard library). And if they have to write unsafe code the unsafe parts are restricted to certain areas of their code. Areas they can then invest extra time and care to make certain their assumptions hold true.

It could also be stated as "1/5 of crates interface with the OS, FFI, or hardware or use pointers for fancy data-structures".

I'm interested in what went into this number.

I checked the six most recently published crates on crates.io (blablabla, nutp, tord, g2d, testpublishtesttest, hellochi, at the time of writing). Three of those (blablabla, testpublishtesttest, and hellochi) did some variation on printing `hello world`. g2d seems like an interesting graphics library. tord provides a data structure for transitive relations, which is also neat. No crate contained over 250 lines of code. Unsurprisingly, none of them contained unsafe code.

Elsewhere in this thread, it's been pointed out that as a consequence of crates.io having a global namespace, plus lax enforcement of an anti-squatting policy, there are a lot of namesquatting packages. Those presumably contain no unsafe code.

tokio contains unsafe code. rand contains unsafe code. regex contains unsafe code. time contains unsafe code. (method: a smattering of packages chosen from blessed.rs; result: every one that I checked except serde containing unsafe code; epistemic status: eh -- I grepped the codebases, ignoring things that were pretty clearly tests, but might have accidentally included some example code or something that's not part of the core library? Please let me know if I've misattributed unsafe usage to one of these projects, or if I've managed to select a biased sample!)

I'd certainly believe a straightforward reading of the claim "80% of crates have no unsafe code"...but that seems almost meaningless, given that a not-insignificant portion of crates contain basically no code at all? I'd be much more interested in a weighted percentage by downloads: I'd be wildly impressed if 80% of crate _downloads_ contained no unsafe code, and would be somewhat unsurprised if the number was well below 50% -- crates with more functionality would be more useful and therefore more download, but also more likely to use unsafe code, I'd imagine.

Edit: I just noticed crates.io has a most-downloaded list[0] -- I might end up running some numbers on top packages there tomorrow morning, for some more solid data.

[0]: https://crates.io/crates?sort=downloads

What is the fact that many foundational ecosystem crate contain unsafe code supposed to prove? That's the entire point of the language. That someone writes a really good regex crate once and then the rest of us don't have to write unsafe to use it. It seems like you have a fundamental misunderstanding about the goals and purpose of rust.

Don't forget to include transitive dependencies as well.

Libraries safely wrapping unsafe code in safe interfaces, and everyone reusing those safe interfaces is like, the whole point of…reusable libraries???

Also, you’re replying to someone who I’m fairly sure is on one of the core Rust teams, if not closely involved, I’m somewhat more inclined to trust _them_ when they say 80% of libs don’t contain unsafe (given that it cleanly meshes with my own experience of Rust libraries).

Instead of looking at the crates themselves, you might want to check your (or others') Rust application with https://github.com/rust-secure-code/cargo-geiger to get a sense of effective prevalence. I also dispute that the presence of unsafe somewhere in the dependency tree is an issue in itself, but that's a different discussion that many more had in other sub-threads.

I wonder what the ratio of utilization of that 80% is compared to the 20% that do have `unsafe` all over the place.

Note that a crate having any unsafe and having unsafe all over the place are two different things.

Ya i'm sure "no improved libraries" is why linux and even windows have started porting components over to rust.

At the risk of getting downvoted into oblivion, that sounds a lot like TypeScript (compiler yelling at you to fix things but you just want to try an idea without perfecting it).

Reply on news.ycombinator.com