5 ms·

"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

"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)

Someone1234 3y ago
> 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.
- stouset 3y ago
  That doesn’t turn off the overwhelming majority of Rust’s soundness checks. `unsafe` isn’t a magic “let anything fly” switch.
- estebank 3y ago
  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.
  - cchance 3y ago
    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.
  - trealira 3y ago
    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/ 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.
  - Buttons840 3y ago
    > 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.)
- sidlls 3y ago
  "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.
  - estebank 3y ago
    80% of crates have no unsafe code in them.
    - throwawaaarrgh 3y ago
      So only 1/5 of Rust code is unsafe? Isn't safety, like, the point of the language?
      - sgift 3y ago
        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.
        estebank 3y ago
        It could also be stated as "1/5 of crates interface with the OS, FFI, or hardware or use pointers for fancy data-structures".
    - chandlerswift 3y ago
      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 https://crates.io/crates?sort=downloads
ajhurliman 3y ago
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).
cchance 3y ago
Ya i'm sure "no improved libraries" is why linux and even windows have started porting components over to rust.

Someone1234 3y ago

> 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.

stouset 3y ago
That doesn’t turn off the overwhelming majority of Rust’s soundness checks. `unsafe` isn’t a magic “let anything fly” switch.
estebank 3y ago
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.
- cchance 3y ago
  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.
- trealira 3y ago
  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/ 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.
- Buttons840 3y ago
  > 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.)
sidlls 3y ago
"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.
- estebank 3y ago
  80% of crates have no unsafe code in them.
  - throwawaaarrgh 3y ago
    So only 1/5 of Rust code is unsafe? Isn't safety, like, the point of the language?
    - sgift 3y ago
      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.
      - estebank 3y ago
        It could also be stated as "1/5 of crates interface with the OS, FFI, or hardware or use pointers for fancy data-structures".
  - chandlerswift 3y ago
    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 https://crates.io/crates?sort=downloads

ajhurliman 3y ago

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).

cchance 3y ago

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