3 ms·

You can argue that (and I'd generally agree in most cases above a certain complexity size) about dynamic vs any static language though?

by berkut 5y ago

littlestymaar 5y ago
Yes, it's exactly the static vs dynamic trade off, but with one of the best static programming language design. C++ is probably at the other end of the spectrum since it's too easy to accidentally cause a memory error during refactoring. C# and Java are a bit in-between, the automatic memory management limits the footgun, but the type system is much less powerful than Rust's one so there still a lot of issues that can come during a refactoring. I have only very limited OCaml experience and no Haskell experience but I think you'd have most of Rust advantages with those, except the thread-safety part which is my favourite part of Rust but is also situational.
- colonwqbang 5y ago
  Haskell is quite thread safe, I suppose it is at least as good as Rust in this respect. Immutability by default and garbage collection really help to cut away the ceremony around threading.
  - tialaramex 5y ago
    > I suppose it is at least as good as Rust in this respect. (Safe) Rust has Data Race Freedom, which means you get Sequential Consistency. As I understand it, Haskell does not promise you data race freedom, so, if you mistakenly implemented a data race now you don't have Sequential Consistency and now you can't reason about non-trivial programs at all. I think Haskell, like Java, and unlike C or C++, promises you still get a meaningful program if you have a data race, but it may be tricky to debug the mess. Edited to expand: Suppose you're writing a program to process 16GB of data, the result will be a floating point value between 0 and 100.0 as a result of this processing. You realise it's embarrassingly parallel and so you spin up 16 threads to solve the problem in parallel on your CPU cores. Mistakenly instead of processing 1GB per thread, you process the same 1GB on all sixteen threads, the processing involves a lot of twiddling data, and so now it's full of data races. What is the result of your buggy program? In Rust, the program doesn't compile, or depending how you wrote it, exits immediately reporting that you can't go around processing the same data from different threads. In C or C++ maybe it deletes all your data, more likely it simply exits instantly with no result, spins forever, or outputs something completely spurious. In Java you might get an Exception reporting that you mustn't do this, but you might get a bogus but real looking answer like 46.2 now good luck figuring out why. I don't know for sure about Haskell, but I think you get a similar situation to Java minus the exception.
    - pjmlp 5y ago
      On the other hand, if one decides to use 16 processes to handle the data across a NUMA shared memory segment, to be able to easier scale it across the cluster, the Rust type system is of little help.
      - tialaramex 5y ago
        To make this work you're going to need an (unsafe) wrapper that lets all your processes get write access to the same 1GB of shared memory. If you write a wrapper that ensures safety, you'll get back to the same place where the faulty program reports that you can't all map the same 1GB of data and twiddle it, and if you don't it's on you for introducing unchecked unsafety.
        pjmlp 5y ago
        Assuming every single OS process that has access to the NUMA segment is written in Rust and originates from exactly the same build, which is impossible to represent on the type system.
    - zozbot234 5y ago
      > (Safe) Rust has Data Race Freedom, which means you get Sequential Consistency. I don't think this is correct. Safe Rust includes atomics that are data-race free but need not be sequentially consistent.
      - tialaramex 5y ago
        Unsurprisingly core::sync::atomic is not in fact implemented in Safe Rust. However you can indeed use it from Safe Rust, and you can choose Orderings which do not give you Sequential Consistency if you're comfortable with that, or more likely because you are implementing an algorithm whose authors assure you this is fine (I hope they're correct). I think that's a very modest caveat to the overall promise of Sequential Consistency, but sure, it is a caveat. If you write code that explicitly asks for Ordering::Relaxed and are astonished you don't get Ordering::SeqCst I guess I apologise for confusing you.

You can argue that (and I'd generally agree in most cases above a certain complexity size) about dynamic vs any static language though?

by berkut 5y ago

You can argue that (and I'd generally agree in most cases above a certain complexity size) about dynamic vs any static language though?

littlestymaar 5y ago

Yes, it's exactly the static vs dynamic trade off, but with one of the best static programming language design. C++ is probably at the other end of the spectrum since it's too easy to accidentally cause a memory error during refactoring. C# and Java are a bit in-between, the automatic memory management limits the footgun, but the type system is much less powerful than Rust's one so there still a lot of issues that can come during a refactoring. I have only very limited OCaml experience and no Haskell experience but I think you'd have most of Rust advantages with those, except the thread-safety part which is my favourite part of Rust but is also situational.

colonwqbang 5y ago
Haskell is quite thread safe, I suppose it is at least as good as Rust in this respect. Immutability by default and garbage collection really help to cut away the ceremony around threading.
- tialaramex 5y ago
  > I suppose it is at least as good as Rust in this respect. (Safe) Rust has Data Race Freedom, which means you get Sequential Consistency. As I understand it, Haskell does not promise you data race freedom, so, if you mistakenly implemented a data race now you don't have Sequential Consistency and now you can't reason about non-trivial programs at all. I think Haskell, like Java, and unlike C or C++, promises you still get a meaningful program if you have a data race, but it may be tricky to debug the mess. Edited to expand: Suppose you're writing a program to process 16GB of data, the result will be a floating point value between 0 and 100.0 as a result of this processing. You realise it's embarrassingly parallel and so you spin up 16 threads to solve the problem in parallel on your CPU cores. Mistakenly instead of processing 1GB per thread, you process the same 1GB on all sixteen threads, the processing involves a lot of twiddling data, and so now it's full of data races. What is the result of your buggy program? In Rust, the program doesn't compile, or depending how you wrote it, exits immediately reporting that you can't go around processing the same data from different threads. In C or C++ maybe it deletes all your data, more likely it simply exits instantly with no result, spins forever, or outputs something completely spurious. In Java you might get an Exception reporting that you mustn't do this, but you might get a bogus but real looking answer like 46.2 now good luck figuring out why. I don't know for sure about Haskell, but I think you get a similar situation to Java minus the exception.
  - pjmlp 5y ago
    On the other hand, if one decides to use 16 processes to handle the data across a NUMA shared memory segment, to be able to easier scale it across the cluster, the Rust type system is of little help.
    - tialaramex 5y ago
      To make this work you're going to need an (unsafe) wrapper that lets all your processes get write access to the same 1GB of shared memory. If you write a wrapper that ensures safety, you'll get back to the same place where the faulty program reports that you can't all map the same 1GB of data and twiddle it, and if you don't it's on you for introducing unchecked unsafety.
      - pjmlp 5y ago
        Assuming every single OS process that has access to the NUMA segment is written in Rust and originates from exactly the same build, which is impossible to represent on the type system.
  - zozbot234 5y ago
    > (Safe) Rust has Data Race Freedom, which means you get Sequential Consistency. I don't think this is correct. Safe Rust includes atomics that are data-race free but need not be sequentially consistent.
    - tialaramex 5y ago
      Unsurprisingly core::sync::atomic is not in fact implemented in Safe Rust. However you can indeed use it from Safe Rust, and you can choose Orderings which do not give you Sequential Consistency if you're comfortable with that, or more likely because you are implementing an algorithm whose authors assure you this is fine (I hope they're correct). I think that's a very modest caveat to the overall promise of Sequential Consistency, but sure, it is a caveat. If you write code that explicitly asks for Ordering::Relaxed and are astonished you don't get Ordering::SeqCst I guess I apologise for confusing you.