291–300 of 546 posts
Earlier quoted context omitted.
I think you mean that Arc is an atomic reference counter (it uses atomic cpu instructions to prevent race conditions when incrementing and decrementing the ref count)
Ah yes, sorry. I remember it in my head with "async", but you're right. :)
Earlier quoted context omitted.
> The evangelism is exhausting. My best guess is that people who are "stuck" working in C or C++ wish they could use Rust at their Jobs. Or that others would make the leap and get over the learning curve.
Not until it reaches the same level as Visual Studio, Android Studio, QtCreator, XCode, CUDA and SYSCL tooling for graphical applications and GPGPU. For anything else managed languages are a much more productive option, other than writing kernel and drivers.
There are also a lot of people who do not use C or C++, but use a bit of rust because it's so much easier to write fast little tools with it. I'm in this category. I even use threads sometimes, and it's reasonably easy. A crop of new unixy tools in rust seems to indicate other people also think alike.
"Rust enforces thread-safety of all code and data, even in 3rd party libraries, even if authors of that code didn't pay attention to thread safety. Everything either upholds specific thread-safety guarantees, or won't be allowed to be used across threads."
> C libraries typically return opaque pointers to their data structures, to hide implementation details and ensure there's only one copy of each instance of the struct. This costs heap allocations and pointer indirections. Rust's built-in privacy, unique ownership rules, and coding conventions let libraries expose their objects by value The primary reason c libraries do this is not for safety, but to maintain ABI com…
The reason Common Lisp uses pointers is because it is dynamically typed. It’s not some principled position about ABI compatibility. If I define an RGB struct for colours, it isn’t going to change but it would still need to be passed by reference because the language can’t enforce that the variable which holds the RGBs will only ever hold 3 word values. Similarly, the reason floats are often passed by reference isn’t…
I prefer to have great ideas in rust ported over to C instead of rewriting everything with Rust. this approach will benefit all the existing softwares written in C which I think is much larger than Rust in terms of both impact and code size. am I a minority having this opinion?
To make static analysis robust in C you need to start reliably tracking ownership and forbid type-erasing constructs. This typically means adding smart pointers, some kind of borrow checking or garbage collection, generics to replace void*, maybe tagged unions, and a new standard library that embraces these features.
It's going to bring most of Rust's complexity and require major code changes anyway, but you won't even get benefits of a newer language.
The article talks way too high level and is written like a marketing people even the title sounds technical, for example: "Rust enforces thread-safety of all code and data, even in 3rd party libraries, even if authors of that code didn't pay attention to thread safety. Everything either upholds specific thread-safety guarantees, or won't be allowed to be used across threads."
It's not marketing speak.
We've implemented network drivers in C and Rust and did a performance comparison. Interestingly, the C-to-Rust-transpiled code ended up being faster than the original C implementation: https://github.com/ixy-languages/ixy-languages/blob/master/R...
https://github.com/emmericp/ixy/blob/0e00605be4153b06df06184... Looks like you're compiling C code with -O2. Does Rust build set -O3 on clang? Did you try -O3 with C? I know it's not guaranteed to be faster, just curious.
https://doc.rust-lang.org/cargo/reference/profiles.html#rele...
The article talks way too high level and is written like a marketing people even the title sounds technical, for example: "Rust enforces thread-safety of all code and data, even in 3rd party libraries, even if authors of that code didn't pay attention to thread safety. Everything either upholds specific thread-safety guarantees, or won't be allowed to be used across threads."
That doesn't sound too high level to me. Maybe a small quibble is the definition of "thread safety," but a reasonable one would be, "no undefined behavior in the presence of simultaneous access." In other words, no data races. And that's absolutely true and consistent with Rust's definition of safety. Another small quibble might be that, "even if the authors of that code didn't pay attention to thread safety and didn…
This is as same as some one tell you that you will never loose any money by investing a certain asset.
Earlier quoted context omitted.
But that may be of little solace. If you snapshot your entire heap into an mmapped file for fast I/O, then basically the entire advantage of Rust is gone.
> If you snapshot your entire heap into an mmapped file for fast I/O, I've never heard of this trick. And my first reaction is "That would be a nightmare of memory unsafety if I did it in C++" What's it used for? IPC?
I know some very skilled C++ and Rust developers who can pull it off. If you're at that skill level, Rust is not going to get in your way because you're just going to use unsafe and throw some sanitizers and fuzzers at it. I wouldn't trust myself to implement it.