32 ms·

Depends on the tradeoffs. Having different levels of abstraction within the same language can be really useful. But you don't want to overcomplicate the langu

Depends on the tradeoffs. Having different levels of abstraction within the same language can be really useful. But you don't want to overcomplicate the language to support that, especially if it makes operating at different levels more complicated. In this case, it seems like an odd tradeoff to make. The less sophisticated user is exactly the same kind of user that is more likely to foot-gun themselves with a memory or thread-safety issue. The "right" answer is probably a thread-safe garbage collector, but that has its owns set of usability and implementation tradeoffs.

civilized 5y ago
How does Bronze overcomplicate Rust as a language? It's an optional library, not a language extension. I think it's often pretty easy to not footgun yourself with thread or memory issues, because these issues simply don't exist in wide swaths of application.
- dathinab 5y ago
  It's locking you into single threaded usage, but you might very easy run into a library which requires Send bounds, as it uses e.g. rayon internally. And for the cases where having managed pointers are better, Rc/Arc are often (not always) good enough.
  - dathinab 5y ago
    Also it seems to be fundamentally unsound, the borrow checker isn't limited to making memory is freed correctly and safe multi-threading. But also affects assembly generation! (And is used to makes sure that all kinds of thinks work correctly, even without multi-threading). The library seem to allow creating multiple mutable refs, which is instant UB in rust. I.e. having two mutable refs is already UB even if you only use one at a time. While this is just a PoC it means you can't implement it as a library! Only as a compiler extension which furthermore means a lot of optimizations must behave different if the extension used.. which is quite painful to maintain and prone to introduce compiler bugs.
    - mattgreenrocks 5y ago
      Thank you for mentioning UB. I like Rust quite a bit, but once you trigger UB, things get nasty really, really fast. It feels like you’re using gcc at -O5 (not a real thing). It’s not like C/C++ in which you can sort of infer the consequences of UB on a single platform with enough experience. It is greatly helped by compiler warnings, but; still, UB in Rust can be downright brutal.
      - dathinab 5y ago
        It's kinda the same in C/C++ as far as I can tell. They use the same backend in LLVM/GCC and the code gen options aren't even that different mainly that rust uses the noalias attribute a lot. > C/C++ in which you can sort of infer the consequences of UB on a single platform with enough experience. UB in C/C++ allows the compiler to arbitrary rewrite your code, and it sometimes does so. All depending on compiler version, enabled compiler flags, optimization level and "seemingly arbitrary" factors (i.e. some optimization passes detect or fail to detect optimizations sometimes for quite surprised reasons). So I don't think you can "sort of infer the consequences" on a single platform in practice. (Maybe in with optimizations disabled, but even then it can be tricky.)
        steveklabnik 5y ago
        There are similarities but also significant differences. Safe Rust has no UB, and so this appears less often in general. There’s also just straight up different semantics; famously there was an i soundness bug in safe Rust because a loop with no side effects is defined behavior in Rust (you get an infinite loop) and UB in C++ (the compiler can elide it). LLVM added a new syntax to handle this specific case, eliminating the UB in other languages. But this kind of thing does happen.
    - afdbcreid 5y ago
      The borrow checker does not affect code generation. Lifetimes are completely elided when codegen'ing. What _does_ affect code generation is Rust's rules about borrowing and so. If borrowck was affecting codegen, stuff like `RefCell` wasn't possible.

civilized 5y ago

How does Bronze overcomplicate Rust as a language? It's an optional library, not a language extension. I think it's often pretty easy to not footgun yourself with thread or memory issues, because these issues simply don't exist in wide swaths of application.

dathinab 5y ago
It's locking you into single threaded usage, but you might very easy run into a library which requires Send bounds, as it uses e.g. rayon internally. And for the cases where having managed pointers are better, Rc/Arc are often (not always) good enough.
- dathinab 5y ago
  Also it seems to be fundamentally unsound, the borrow checker isn't limited to making memory is freed correctly and safe multi-threading. But also affects assembly generation! (And is used to makes sure that all kinds of thinks work correctly, even without multi-threading). The library seem to allow creating multiple mutable refs, which is instant UB in rust. I.e. having two mutable refs is already UB even if you only use one at a time. While this is just a PoC it means you can't implement it as a library! Only as a compiler extension which furthermore means a lot of optimizations must behave different if the extension used.. which is quite painful to maintain and prone to introduce compiler bugs.
  - mattgreenrocks 5y ago
    Thank you for mentioning UB. I like Rust quite a bit, but once you trigger UB, things get nasty really, really fast. It feels like you’re using gcc at -O5 (not a real thing). It’s not like C/C++ in which you can sort of infer the consequences of UB on a single platform with enough experience. It is greatly helped by compiler warnings, but; still, UB in Rust can be downright brutal.
    - dathinab 5y ago
      It's kinda the same in C/C++ as far as I can tell. They use the same backend in LLVM/GCC and the code gen options aren't even that different mainly that rust uses the noalias attribute a lot. > C/C++ in which you can sort of infer the consequences of UB on a single platform with enough experience. UB in C/C++ allows the compiler to arbitrary rewrite your code, and it sometimes does so. All depending on compiler version, enabled compiler flags, optimization level and "seemingly arbitrary" factors (i.e. some optimization passes detect or fail to detect optimizations sometimes for quite surprised reasons). So I don't think you can "sort of infer the consequences" on a single platform in practice. (Maybe in with optimizations disabled, but even then it can be tricky.)
      - steveklabnik 5y ago
        There are similarities but also significant differences. Safe Rust has no UB, and so this appears less often in general. There’s also just straight up different semantics; famously there was an i soundness bug in safe Rust because a loop with no side effects is defined behavior in Rust (you get an infinite loop) and UB in C++ (the compiler can elide it). LLVM added a new syntax to handle this specific case, eliminating the UB in other languages. But this kind of thing does happen.
  - afdbcreid 5y ago
    The borrow checker does not affect code generation. Lifetimes are completely elided when codegen'ing. What _does_ affect code generation is Rust's rules about borrowing and so. If borrowck was affecting codegen, stuff like `RefCell` wasn't possible.