3 ms·

I kind of wanted to downvote you for being non-constructive, but instead, I'll ask you a question to try to make this a concrete discussion. Can you give a conc

by geofft 7y ago

I kind of wanted to downvote you for being non-constructive, but instead, I'll ask you a question to try to make this a concrete discussion. Can you give a concrete example of "no language can even come close to doing what C can"? (Not a statement about how C is flexible or powerful or portable or anything, a specific actual thing in C code.)

ignaloidas 7y ago
A valid point could be compiler availability. Almost every platform imaginable has a C compiler. Not a language feature though, just a sign of popularity.
- geofft 7y ago
  Right, that's not an instance of "... language can even come close to doing what C can," absent an argument about how architectures that LLVM doesn't support are easy to write custom C compilers for but not LLVM backends. LLVM just happens not to support that many architectures today. Also there have been a few attempts at a C backend for LLVM, and code in Rust that is compiled through C will generally retain its safety and speed properties.
ff317 7y ago
I'm a fan of Rust (although I haven't waded into it much yet), and a heavy user of C, and the one particular thing I find missing so far is a properly Rust-ified abstraction of QSBR-style RCU, with the full power and flexibility that can be achieved with liburcu-qsbr in C. For C it's just some header files and a library and you get some amazing performance magic out of it. It's the key missing feature that makes me leery of going down the road of converting some existing C daemon code over to Rust. It's hard to do low-level QSBR as a primitive for scalable threading in languages other than C/C++ unless you bake the abstraction in pretty deeply. I think it's probably possibly to bring it to Rust in a meaningful way, but probably non-trivial to integrate with all the other cool things going on in the language for concurrency and the borrow-checker, etc.
- steveklabnik 7y ago
  I’m not super familiar, but from a cursory google, it looks like crossbeam is the rust equivalent?
- tene 7y ago
  I'm not familiar with the implementation details of QSBR, and I've never used liburcu-qsbr, but what I've read about it tonight sounds a lot like the im[0] crate in terms of behaviour. The behaviour in im is a data structure where readers get a reference that pins data in memory, so they have a consistent snapshot to read from. Any mutations made while there are outstanding read references will write to a new allocation for the part that changed, so the two references can share most of the data through structural sharing. When there are no outstanding read references, mutations happen in-place. Have I correctly understood QSBR if I think it's similar behaviour to this? How does the implementation differ? [0] https://docs.rs/im/13.0.0/im/ https://docs.rs/im/13.0.0/im/

by geofft 7y ago

ignaloidas 7y ago

A valid point could be compiler availability. Almost every platform imaginable has a C compiler. Not a language feature though, just a sign of popularity.

geofft 7y ago
Right, that's not an instance of "... language can even come close to doing what C can," absent an argument about how architectures that LLVM doesn't support are easy to write custom C compilers for but not LLVM backends. LLVM just happens not to support that many architectures today. Also there have been a few attempts at a C backend for LLVM, and code in Rust that is compiled through C will generally retain its safety and speed properties.

ff317 7y ago

I'm a fan of Rust (although I haven't waded into it much yet), and a heavy user of C, and the one particular thing I find missing so far is a properly Rust-ified abstraction of QSBR-style RCU, with the full power and flexibility that can be achieved with liburcu-qsbr in C. For C it's just some header files and a library and you get some amazing performance magic out of it. It's the key missing feature that makes me leery of going down the road of converting some existing C daemon code over to Rust. It's hard to do low-level QSBR as a primitive for scalable threading in languages other than C/C++ unless you bake the abstraction in pretty deeply. I think it's probably possibly to bring it to Rust in a meaningful way, but probably non-trivial to integrate with all the other cool things going on in the language for concurrency and the borrow-checker, etc.

steveklabnik 7y ago
I’m not super familiar, but from a cursory google, it looks like crossbeam is the rust equivalent?
tene 7y ago
I'm not familiar with the implementation details of QSBR, and I've never used liburcu-qsbr, but what I've read about it tonight sounds a lot like the im[0] crate in terms of behaviour. The behaviour in im is a data structure where readers get a reference that pins data in memory, so they have a consistent snapshot to read from. Any mutations made while there are outstanding read references will write to a new allocation for the part that changed, so the two references can share most of the data through structural sharing. When there are no outstanding read references, mutations happen in-place. Have I correctly understood QSBR if I think it's similar behaviour to this? How does the implementation differ? [0] https://docs.rs/im/13.0.0/im/ https://docs.rs/im/13.0.0/im/