4 ms·

I should note that writing data structures in rust is also a fraught business! In practice, that’s just a property of languages that don’t have garbage collect

I should note that writing data structures in rust is also a fraught business! In practice, that’s just a property of languages that don’t have garbage collection. Exception safety is a serious complication in c++! Exceptions were a mistake in the language, particularly given the existence now of std::optional.

bodhiandphysics 5y ago
Finanally, c++ is the only language I would ever want to do linear algebra in, or for that matter, many graph algorithms. Rust is adding features to make it useful for linalg, but it’s not their yet. Linear algebra is important!
- chrisseaton 5y ago
  > Finanally, c++ is the only language I would ever want to do linear algebra in Isn't something like MATLAB better for linear algebra than C++?
  - Jtsummers 5y ago
    Or Fortran or Julia.
    - bodhiandphysics 5y ago
      I don’t want to use Fortran! Julia is lovely
  - bodhiandphysics 5y ago
    Low level linalg... implementing solvers using openmp and CUDA
    - deleted 5y ago
      [deleted]
  - deleted 5y ago
    [deleted]
- MetricExpansion 5y ago
  Perhaps syntactically C++‘s operator overloading can make it quite palatable, but C and C++’s unique aliasing rules would mean that a naive implementation could leave performance on the table. There’s a reason it’s almost always Fortran at the bottom of the stack in most LinAlg codes in most languages.
edflsafoiewq 5y ago
Rust has the same exception safety issues. Eg Vec::retain_mut: https://github.com/rust-lang/rust/blob/532d3cda90b8a729cd982548649d32803d265052/library/alloc/src/vec/mod.rs#L1478 https://github.com/rust-lang/rust/blob/532d3cda90b8a729cd982...
beached_whale 5y ago
that's just false. Exceptions were not a mistake and std::optional isn't even a good type to replace more than communicating that there is no value. It's as good as returning nullptr, in this case. And what strength of an exception guarantee does one really need? A basic guarantee is not that bad to give and most things do not need to worry if they don't use unmanaged resources without RAII types(e.g pointers). But the big thing is, a large amount of code does not have error states at all, they always work. Another chunk have preconditions, that are generally developer errors, that shouldn't be throwing either. That leaves the parts that interact externally. And here is where one learns, it's not a dichotomy of exceptions or error flags/results... it can be both. It's more to do with the shape of the code. One example is, one is passing a string buffer to a parser, an exception is probably fine as the error cannot be dealt with within the parser. It didn't create the malformed document and cannot fix it. To use error types will greatly complicate the inner workings of the library as it has to deal with errors at a majority of calls internally. This leads to more bugs(assuming more code == more bugs) and complexity/branches. One already paid for the branch to check for the error in the document too, now they have to pay for branching up the stack. Exceptions strong part is that they cannot be implicitly ignored. One can do that with error types that force a read prior to destruction too though. For short distance things, where one is handling the error state after the call, not throwing is fine.
- 3836293648 5y ago
  Exceptions as a concept weren't a mistake, but their specific details and implementation absolutely is.
  - beached_whale 5y ago
    I am curious, what would you change?

bodhiandphysics 5y ago

Finanally, c++ is the only language I would ever want to do linear algebra in, or for that matter, many graph algorithms. Rust is adding features to make it useful for linalg, but it’s not their yet. Linear algebra is important!

chrisseaton 5y ago
> Finanally, c++ is the only language I would ever want to do linear algebra in Isn't something like MATLAB better for linear algebra than C++?
- Jtsummers 5y ago
  Or Fortran or Julia.
  - bodhiandphysics 5y ago
    I don’t want to use Fortran! Julia is lovely
- bodhiandphysics 5y ago
  Low level linalg... implementing solvers using openmp and CUDA
  - deleted 5y ago
    [deleted]
- deleted 5y ago
  [deleted]
MetricExpansion 5y ago
Perhaps syntactically C++‘s operator overloading can make it quite palatable, but C and C++’s unique aliasing rules would mean that a naive implementation could leave performance on the table. There’s a reason it’s almost always Fortran at the bottom of the stack in most LinAlg codes in most languages.

edflsafoiewq 5y ago

Rust has the same exception safety issues. Eg Vec::retain_mut: https://github.com/rust-lang/rust/blob/532d3cda90b8a729cd982548649d32803d265052/library/alloc/src/vec/mod.rs#L1478 https://github.com/rust-lang/rust/blob/532d3cda90b8a729cd982...

beached_whale 5y ago

that's just false. Exceptions were not a mistake and std::optional isn't even a good type to replace more than communicating that there is no value. It's as good as returning nullptr, in this case. And what strength of an exception guarantee does one really need? A basic guarantee is not that bad to give and most things do not need to worry if they don't use unmanaged resources without RAII types(e.g pointers). But the big thing is, a large amount of code does not have error states at all, they always work. Another chunk have preconditions, that are generally developer errors, that shouldn't be throwing either. That leaves the parts that interact externally. And here is where one learns, it's not a dichotomy of exceptions or error flags/results... it can be both. It's more to do with the shape of the code. One example is, one is passing a string buffer to a parser, an exception is probably fine as the error cannot be dealt with within the parser. It didn't create the malformed document and cannot fix it. To use error types will greatly complicate the inner workings of the library as it has to deal with errors at a majority of calls internally. This leads to more bugs(assuming more code == more bugs) and complexity/branches. One already paid for the branch to check for the error in the document too, now they have to pay for branching up the stack. Exceptions strong part is that they cannot be implicitly ignored. One can do that with error types that force a read prior to destruction too though. For short distance things, where one is handling the error state after the call, not throwing is fine.

3836293648 5y ago
Exceptions as a concept weren't a mistake, but their specific details and implementation absolutely is.
- beached_whale 5y ago
  I am curious, what would you change?