4 ms·

Rust allows to provide more information about types (generic types, pointer usage) and checks it, while in C you have to rely on doc comments and checking the c

Rust allows to provide more information about types (generic types, pointer usage) and checks it, while in C you have to rely on doc comments and checking the code manually. Or am I wrong and C allows to specify pointer nullability, pointer ownership and array bounds?

ohgr 2y ago
None of those things feature in any problem I deal with on a daily basis, whatever language I use. So for example today I dealt with a synchronization issue. This turned out to not be a code bug but a human misunderstanding of a protocol specification saga, which was not possible to code into a type system of any sort. The day before was a constraint network specification error. In both cases the code was entirely irrelevant to the problem. Literally all I deal with are human problems. My point is Rust doesn't help with these at all, however clever you get. It is no different to C, but C will give you a superset of vulnerabilities on top of that. Fundamentally Rust solves no problems I have. Because the problems that matter are human ones. We are too obsessed with the microscopic problems of programming languages and type systems and not concentrating on making quality software which is far more than just "Rust makes all my problems go away" because it doesn't. It kills a small class of problems which aren't relevant to a lot of domains. (incidentally the problems above are implemented in a subset of c++)
- kelnos 2y ago
  > None of those things feature in any problem I deal with on a daily basis, whatever language I use.' I run into those things nearly daily, so... ok then.
  - worthless-trash 2y ago
    Do not feel bad friend, It's not you.. there is definitely inconsistencies here. Maybe they work on absolutely pristine perfect codebases.
- xmcqdpt2 2y ago
  > So for example today I dealt with a synchronization issue. This turned out to not be a code bug but a human misunderstanding of a protocol specification saga, which was not possible to code into a type system of any sort. Maybe not in a reasonable language no, but there are advances in type systems that are making ever larger classes of behaviours encodable into types. For example, algebraic effects (can this function throw, call a remote service etc) https://koka-lang.github.io/koka/doc/index.html https://koka-lang.github.io/koka/doc/index.html linear types (this method must be called only once etc) https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/linear_types.html https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/line... dependent typing (f(1) returning a different type from f(2), verifiable at compile time), https://fstar-lang.org/index.html https://fstar-lang.org/index.html Some of these features will eventually make it to “normal” PL. For example, Scala now has dependent types, https://dotty.epfl.ch/docs/reference/new-types/match-types.html https://dotty.epfl.ch/docs/reference/new-types/match-types.h... and Java can support linear type checking, https://checkerframework.org/manual/#must-call-checker https://checkerframework.org/manual/#must-call-checker

ohgr 2y ago

None of those things feature in any problem I deal with on a daily basis, whatever language I use. So for example today I dealt with a synchronization issue. This turned out to not be a code bug but a human misunderstanding of a protocol specification saga, which was not possible to code into a type system of any sort. The day before was a constraint network specification error. In both cases the code was entirely irrelevant to the problem. Literally all I deal with are human problems. My point is Rust doesn't help with these at all, however clever you get. It is no different to C, but C will give you a superset of vulnerabilities on top of that. Fundamentally Rust solves no problems I have. Because the problems that matter are human ones. We are too obsessed with the microscopic problems of programming languages and type systems and not concentrating on making quality software which is far more than just "Rust makes all my problems go away" because it doesn't. It kills a small class of problems which aren't relevant to a lot of domains. (incidentally the problems above are implemented in a subset of c++)

kelnos 2y ago
> None of those things feature in any problem I deal with on a daily basis, whatever language I use.' I run into those things nearly daily, so... ok then.
- worthless-trash 2y ago
  Do not feel bad friend, It's not you.. there is definitely inconsistencies here. Maybe they work on absolutely pristine perfect codebases.
xmcqdpt2 2y ago
> So for example today I dealt with a synchronization issue. This turned out to not be a code bug but a human misunderstanding of a protocol specification saga, which was not possible to code into a type system of any sort. Maybe not in a reasonable language no, but there are advances in type systems that are making ever larger classes of behaviours encodable into types. For example, algebraic effects (can this function throw, call a remote service etc) https://koka-lang.github.io/koka/doc/index.html https://koka-lang.github.io/koka/doc/index.html linear types (this method must be called only once etc) https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/linear_types.html https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/line... dependent typing (f(1) returning a different type from f(2), verifiable at compile time), https://fstar-lang.org/index.html https://fstar-lang.org/index.html Some of these features will eventually make it to “normal” PL. For example, Scala now has dependent types, https://dotty.epfl.ch/docs/reference/new-types/match-types.html https://dotty.epfl.ch/docs/reference/new-types/match-types.h... and Java can support linear type checking, https://checkerframework.org/manual/#must-call-checker https://checkerframework.org/manual/#must-call-checker