4 ms·

I like Rust, but I wouldn't categorize it as a "better-C". It is a whole different world, and some things work well in Rust but not in C, and vice versa. Many t

I like Rust, but I wouldn't categorize it as a "better-C". It is a whole different world, and some things work well in Rust but not in C, and vice versa. Many things are flat out uncomfortable to express in Rust, and the number of times you need to bail out and just Rc<RefCell<T>> or Arc<Mutex<T>> random things is a bit high. Interacting with anything but basic C is also horrible, requiring significant engineering efforts to hide the glue in a binding crate when possible, and sometimes it just doesn't work out. Many C libraries are heavy on linked lists of linked lists with their own lifetimes, and that's Rust's kryptonite. Zig is definitely a "better-C", but also young and not nearly as widely adopted.

steveklabnik 3y ago
(You’d never want the box in either of those situations, as the data is already boxed by the Arc or Rc)
- arghwhat 3y ago
  Yeah got a bit carried away, and was stuck in C-ffi land where things get weird - Box::leak, ManualDrop, PhantomPin wrappers, all that.
jcranmer 3y ago
> the number of times you need to bail out and just Rc<RefCell<Box<T>>> or Arc<Mutex<Box<T>>> random things is a bit high. People keep saying this, but in all the Rust I've written, I've never needed to reach for this. Indeed, from what I've seen in the community, this kind of nesting is often a code smell that maybe you should think about the architecture of your system a bit more. > Many C libraries are heavy on linked lists of linked lists with their own lifetimes, and that's Rust's kryptonite. One article that was on here earlier today discussed what's the usual Rust salve to this problem, handles: https://news.ycombinator.com/item?id=36419739 https://news.ycombinator.com/item?id=36419739. That is to say, instead of saying that everything is a pointer, instead make an arena (an array) of allocations and use indexes into that array instead. This is the solution in petgraph, for example.
- arghwhat 3y ago
  The issue is not just architecture, it is also what you need to interact with. In my experience, if you're making practical applications that interact with the outside world where this is not the case, it's because you're using libraries made of the broken dreams of it's authors, giving it's best to hide all the pain from you. I tend to end up writing that code for system integration, so I don't get to see a world of pure type system bliss. > That is to say, instead of saying that everything is a pointer, instead make an arena (an array) of allocations and use indexes into that array instead An index into an arena is the very definition of a pointer, but I get the idea. Unfortunately, you cannot redefine how to deal with types defined and allocated by C, nor how C should interpret and deference types allocated by Rust that must integrate into C-esque designs such as being a node in a C-defined linked list. Teaching existing C to be anything else is not an option, but Rust is not - and is not meant to be - good a acting like C. The glue is not pretty to neither C nor Rust devs. Zig is a middle ground that gives up some things from Rust in order to let C paradigms still work, while still having improvements.
JohnFen 3y ago
> I like Rust, but I wouldn't categorize it as a "better-C". 100% agree. C and Rust are very different languages.

steveklabnik 3y ago

(You’d never want the box in either of those situations, as the data is already boxed by the Arc or Rc)

arghwhat 3y ago
Yeah got a bit carried away, and was stuck in C-ffi land where things get weird - Box::leak, ManualDrop, PhantomPin wrappers, all that.

jcranmer 3y ago

> the number of times you need to bail out and just Rc<RefCell<Box<T>>> or Arc<Mutex<Box<T>>> random things is a bit high. People keep saying this, but in all the Rust I've written, I've never needed to reach for this. Indeed, from what I've seen in the community, this kind of nesting is often a code smell that maybe you should think about the architecture of your system a bit more. > Many C libraries are heavy on linked lists of linked lists with their own lifetimes, and that's Rust's kryptonite. One article that was on here earlier today discussed what's the usual Rust salve to this problem, handles: https://news.ycombinator.com/item?id=36419739 https://news.ycombinator.com/item?id=36419739. That is to say, instead of saying that everything is a pointer, instead make an arena (an array) of allocations and use indexes into that array instead. This is the solution in petgraph, for example.

arghwhat 3y ago
The issue is not just architecture, it is also what you need to interact with. In my experience, if you're making practical applications that interact with the outside world where this is not the case, it's because you're using libraries made of the broken dreams of it's authors, giving it's best to hide all the pain from you. I tend to end up writing that code for system integration, so I don't get to see a world of pure type system bliss. > That is to say, instead of saying that everything is a pointer, instead make an arena (an array) of allocations and use indexes into that array instead An index into an arena is the very definition of a pointer, but I get the idea. Unfortunately, you cannot redefine how to deal with types defined and allocated by C, nor how C should interpret and deference types allocated by Rust that must integrate into C-esque designs such as being a node in a C-defined linked list. Teaching existing C to be anything else is not an option, but Rust is not - and is not meant to be - good a acting like C. The glue is not pretty to neither C nor Rust devs. Zig is a middle ground that gives up some things from Rust in order to let C paradigms still work, while still having improvements.

JohnFen 3y ago

> I like Rust, but I wouldn't categorize it as a "better-C". 100% agree. C and Rust are very different languages.