[jacobr1]

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]

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]

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]

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]

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]

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]

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]

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.

[dathinab]

Sure,

But in the end most times people (outside of the rusty community) speak about rusts borrow checking it's about the combination of checking lifetime, "pointe" aliasing rules and the (not fully specified) memory model. I.e it's ownership model.

And while lifetimes get eliminated at some point in compilation this is after making sure they are correct, which enables rust to use a "pointer" aliasing model for it's references which is subtle different from C-pointers in ways which affects code generation.

I.e. they implicitly affect code generation in the way they affect what the rust language/compiler can do/can rely on (like relying on being often able to mark &Mut as noalias).

I.e. if you write unsafe code assuming lifetimes are just about making sure memory is freed correctly you will produce unsound code.