4 ms·

What do you by convenient? There is an extremely good response to how to design this in Rust on the SO post. This doesn't change the way that you should design

What do you by convenient? There is an extremely good response to how to design this in Rust on the SO post. This doesn't change the way that you should design the rest of the code. The convenience that Rust gives you in this context is strong ownership (i.e. can limit access to the Global except in very desirable patterns) and data-race free with compile time checks around mutability. The standard library has all of these options available, additionally there are a bunch of libraries from the ecosystem that make it even easier.

Const-me 6y ago
> can limit access to the Global except in very desirable patterns It’s desirable when you don’t do much I/O, only implementing some algorithms that compute something. It’s not desirable at all when the majority of your complexity is I/O. An extreme example is a videogame, these can update global mutable state (the VRAM, abstracted behind GL or D3D) with the bandwidth measured in gigabytes/second, often concurrently so from multiple threads. Update: and even for computations, when you want performance, rust’s ownership shenanigans often get in the way. See this C++ code for example: https://github.com/Const-me/SimdPrecisionTest/blob/master/rcppsErrorSummary.cpp https://github.com/Const-me/SimdPrecisionTest/blob/master/rc... You gonna have hard time porting that to Rust, because this vector https://github.com/Const-me/SimdPrecisionTest/blob/master/rcppsErrorSummary.cpp#L212 https://github.com/Const-me/SimdPrecisionTest/blob/master/rc... is updated concurrently by multiple threads of the pool, without any locks.
- bluejekyll 6y ago
  You're comparing an implicitly unsafe language implementation, C++, with a language that guarantees safety by default, Rust. There are many people working on non-blocking lock-free datastructures in Rust, but this often requires unsafe implementations. Essentially removing the safety restrictions to do things like what you're showing in the C++. Looking at the code you're showing, I might model this with deque from the Crossbeam project: https://docs.rs/crossbeam/0.7.3/crossbeam/deque/index.html https://docs.rs/crossbeam/0.7.3/crossbeam/deque/index.html I believe that's all lock-free, and offers a safe interface for working with it.
  - Const-me 6y ago
    I have no doubts it’s possible to replicate the functionality in Rust. Most languages are Turing-complete, after all. What I have doubts about is performance parts, i.e. replicating the functionality without moving data from a single std::vector into randomly-allocated heap objects, or using synchronization primitives. Another thing is usability, and especially readability. OpenMP C++ code is very readable, it’s just a for loop. The example on the page you have linked, on the other hand… And by the way, when I want memory safety, I don’t code C++, I use C# instead. Much easier to use than Rust, IDE and libraries are awesome, C interop is same as in Rust, and last but not least even very complex software compiles in a few seconds. Despite what most people think it’s very suitable for lower-level system software, including latency sensitive stuff working on slow ARM CPUs, see this for an example: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo https://github.com/Const-me/Vrmac/tree/master/VrmacVideo
    - bluejekyll 6y ago
      Readability is probably always going to be a very personal thing as it has a lot to do with familiarity. Having worked with all the languages you mention, I don't find Rust to be any less readable, and definitely enjoy reading it more than C or C++. I get how coming from C or C++, deciding that it's not worth turning to a new language in this space that meets the same requirements. I made that same choice years ago when I switched to Java primarily for memory safety. This is no longer a trade-off you need to make with Rust (i.e. turning to a garbage collector), and that's one of the reasons that I've enjoyed it so much. Obviously, YMMV.
      - Const-me 6y ago
        > This is no longer a trade-off you need to make with Rust I don’t need to make that trade-off either. In the software I’m working on, I often use C# for less performance-critical parts where I want memory safety, and calling C++ DLLs for code which needs to be unsafe for some good reasons. Apparently, Java had a design goal to force people to code their entire software in Java. C# didn’t, it was designed for native interop from the very beginning, hence value types, real stack, DllImport, unsafe, pointer arithmetic, delegates compatible with C function pointers, HRESULT status codes of exceptions, and so on. At some point I have even made COM interop for Linux: https://github.com/Const-me/ComLightInterop https://github.com/Const-me/ComLightInterop It’s a small project with less than 5k lines of code, because all the heavy lifting was already in the .NET runtime.

Const-me 6y ago

> can limit access to the Global except in very desirable patterns It’s desirable when you don’t do much I/O, only implementing some algorithms that compute something. It’s not desirable at all when the majority of your complexity is I/O. An extreme example is a videogame, these can update global mutable state (the VRAM, abstracted behind GL or D3D) with the bandwidth measured in gigabytes/second, often concurrently so from multiple threads. Update: and even for computations, when you want performance, rust’s ownership shenanigans often get in the way. See this C++ code for example: https://github.com/Const-me/SimdPrecisionTest/blob/master/rcppsErrorSummary.cpp https://github.com/Const-me/SimdPrecisionTest/blob/master/rc... You gonna have hard time porting that to Rust, because this vector https://github.com/Const-me/SimdPrecisionTest/blob/master/rcppsErrorSummary.cpp#L212 https://github.com/Const-me/SimdPrecisionTest/blob/master/rc... is updated concurrently by multiple threads of the pool, without any locks.

bluejekyll 6y ago
You're comparing an implicitly unsafe language implementation, C++, with a language that guarantees safety by default, Rust. There are many people working on non-blocking lock-free datastructures in Rust, but this often requires unsafe implementations. Essentially removing the safety restrictions to do things like what you're showing in the C++. Looking at the code you're showing, I might model this with deque from the Crossbeam project: https://docs.rs/crossbeam/0.7.3/crossbeam/deque/index.html https://docs.rs/crossbeam/0.7.3/crossbeam/deque/index.html I believe that's all lock-free, and offers a safe interface for working with it.
- Const-me 6y ago
  I have no doubts it’s possible to replicate the functionality in Rust. Most languages are Turing-complete, after all. What I have doubts about is performance parts, i.e. replicating the functionality without moving data from a single std::vector into randomly-allocated heap objects, or using synchronization primitives. Another thing is usability, and especially readability. OpenMP C++ code is very readable, it’s just a for loop. The example on the page you have linked, on the other hand… And by the way, when I want memory safety, I don’t code C++, I use C# instead. Much easier to use than Rust, IDE and libraries are awesome, C interop is same as in Rust, and last but not least even very complex software compiles in a few seconds. Despite what most people think it’s very suitable for lower-level system software, including latency sensitive stuff working on slow ARM CPUs, see this for an example: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo https://github.com/Const-me/Vrmac/tree/master/VrmacVideo
  - bluejekyll 6y ago
    Readability is probably always going to be a very personal thing as it has a lot to do with familiarity. Having worked with all the languages you mention, I don't find Rust to be any less readable, and definitely enjoy reading it more than C or C++. I get how coming from C or C++, deciding that it's not worth turning to a new language in this space that meets the same requirements. I made that same choice years ago when I switched to Java primarily for memory safety. This is no longer a trade-off you need to make with Rust (i.e. turning to a garbage collector), and that's one of the reasons that I've enjoyed it so much. Obviously, YMMV.
    - Const-me 6y ago
      > This is no longer a trade-off you need to make with Rust I don’t need to make that trade-off either. In the software I’m working on, I often use C# for less performance-critical parts where I want memory safety, and calling C++ DLLs for code which needs to be unsafe for some good reasons. Apparently, Java had a design goal to force people to code their entire software in Java. C# didn’t, it was designed for native interop from the very beginning, hence value types, real stack, DllImport, unsafe, pointer arithmetic, delegates compatible with C function pointers, HRESULT status codes of exceptions, and so on. At some point I have even made COM interop for Linux: https://github.com/Const-me/ComLightInterop https://github.com/Const-me/ComLightInterop It’s a small project with less than 5k lines of code, because all the heavy lifting was already in the .NET runtime.