7 ms·

I agree. I feel far more productive in C and C++ than in Rust at that point. Rust feels like totally missing the sweet spot for me. It's way too pedantic about

I agree. I feel far more productive in C and C++ than in Rust at that point. Rust feels like totally missing the sweet spot for me. It's way too pedantic about low level stuff for writing higher level applications, but way too complicated for embedded or writing an OS. In the former case I would rather take a C++, Java, Haskell, OCaml or even Go, and maybe sprinkle some C, and in the latter case C in macroassembly mode is far more suitable. I still have a feeling that original vision of Graydon Hoare (i.e. OCaml/SML with linear types, GC, stack allocations, green threads and CPS) would be a much better language.

api 3y ago
The problem with C and to C++ is that it’s 2023 and the CVE list is still loaded with basic memory errors. These come from everywhere too: small companies and open source all the way up to Apple, Microsoft, and Google. We as a profession have proven that we can’t write unsafe code at scale and avoid these problems. You might be able to in hand whittled code you write but what happens when other people work on it, it gets refactored, someone pulls in a merge without looking too closely, etc., or even maybe you come back two years later to fix something and have forgotten the details. Having the compiler detect almost all memory errors is necessary. Either that or the language has to avoid this entirely. Rust is the former class unless you use unsafe, and the fact that it’s called “unsafe” makes it trivial to search for. You can automatically flag commits with unsafe in them for extra review or even prohibit it.
- flohofwoe 3y ago
  I think nobody is arguing the need for static memory safety, just that the poor Rust ergonomics aren't a good tradeoff, especially for scenarios where C is useful. We need many more Rust alternatives that explore into different directions, Rust is already too big and "established" for any radical changes in direction.
  - pjmlp 3y ago
    On that regard, by packaging Modula-2 into a C friendly syntax, I do agree Zig is relatively interesting option, however not having a story for binary library distribution is an hindrance in many C dominated industries.
  - ParetoOptimal 3y ago
    > I think nobody is arguing the need for static memory safety, just that the poor Rust ergonomics aren't a good tradeoff Unless the "poor ergonomics" and lack of shortcuts are explicitly what provides the static memory safety.
    - flohofwoe 3y ago
      IMHO Rust's ergonomics problems aren't caused by the borrow checker itself, but have the same cause as similar problems in C++ (mainly a "design by committee" approach to language design and implementing features that should be language syntax sugar in the stdlib instead, which then directly results in the stdlib being too entangled with the language and "too noisy" hard to read code). Apart from the static memory safety USP, Rust is repeating too many problems of C++ for my taste, and at a much faster pace.
      - perryizgr8 3y ago
        I agree with this. The borrow checker itself isn't the problem. That's necessary to make you write correct and safe code anyway. The problem is that there is too much syntax, too many symbols, and too many keywords. I just keep forgetting how to use impl and lifetimes and single quotes and whatnot. It makes it really tough to use as an occasional language. And if I can't do that, then how can I get confident enough to use it in my job?
        jug 3y ago
        Maybe Lobster could be an option. https://strlen.com/lobster/ https://strlen.com/lobster/ https://aardappel.github.io/lobster/memory_management.html https://aardappel.github.io/lobster/memory_management.html It uses compile-time reference counting / lifetime analysis / borrow checking. Which is mostly inlined to the point that there is none of the sort in the compiled output and objects can even live on the stack. It basically looks like Python but is nothing like it underneath, and of course with no GIL. You can run it on JIT or compile it to C++. There's also Koka with the Perceus algorithm on compile time and looks like a much cleaner language than Rust. It also tracks side effects of every function in a type where pure and effectful computations are distinguished. https://github.com/koka-lang/koka https://github.com/koka-lang/koka
  - hgs3 3y ago
    When the pendulum swings it often swings far before normalizing somewhere in the middle. I agree that Rust isn't the answer. FWIW there is interest in adding bounds checking to C [1]. That discussion includes feedback from at least one member of the C standards committee. [1] https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-c-fbounds-safety/70854 https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-...
- pjmlp 3y ago
  It is, however those same companies aren't dialing full safe ahead knob either, hence why Microsoft just recently published a set of secure coding guidelines for C and C++. https://devblogs.microsoft.com/cppblog/build-reliable-and-secure-cpp-programs-microsoft-learn/ https://devblogs.microsoft.com/cppblog/build-reliable-and-se...
  - Buttons840 3y ago
    Does it have tooling to enforce those guidelines? If not, how is it better than someone saying "write correct code" and calling it a guideline?
    - pjmlp 3y ago
      Partially, in Visual Studio and GitHub.
    - GoblinSlayer 3y ago
      Following a guideline that checks correctness for you is easier than following "write correct code".
  - dayjaby 3y ago
    Quite annoying to read in my native language, German. Do they use automatic translations? It's full of grammar errors and mistranslations.
    - deleted 3y ago
      [deleted]
- ernst_klim 3y ago
  These are two issues, which a theoretically orthogonal but in practice not so much. These are known as soundness and completeness. A good talk on topic [1] Rust will reject a lot of sound programs, and that's a huge performance hit. You are hitting the incompleteness wall with multiple mutable borrowing, closures in structures are a huge source of pain as well. And usually the answer from the community is "use handlers instead of pointers", but this gives you, surprise surprise, manual resource management alike that in C, and the compiler won't help much. Of course this is all subjective but for me the ergonomics of Rust is far too bad. It's a good step in right direction along with ATS, but I really hope we could do better than this. [1] https://www.youtube.com/watch?v=iSmkqocn0oQ https://www.youtube.com/watch?v=iSmkqocn0oQ
  - oneshtein 3y ago
    Can you give us examples, please? I use Rust since version 1.0, and I like it a lot.
    - hgs3 3y ago
      Cyclic data structures are impossible to represent in safe Rust because there is no clear "owner" in a cyclic data structure.
      - oneshtein 3y ago
        Cyclic structures can be flattened into a vector or an arena, or unsafe Rust can be used.
  - tene 3y ago
    What are some examples of sound programs you want to write in Rust but are unable to write?
- deterministic 3y ago
  I maintain very large C and C++ application and very rarely have any memory issues. Tools like Valgrind and Helgrind are excellent for finding and fixing problems. So switching to Rust is a very bad ROI.
khaledh 3y ago
I gave Rust a few chances, and always came out hating its complexity. I needed a systems programming language to develop a hobby OS[1], and Nim hit the sweet spot of being very ergonomic, optional GC, and great interop with C. I can drop down to assembly any time I want, or write a piece of C code to do something exotic, but the rest of the system is pure Nim. It's also quite fast. [1] https://github.com/khaledh/axiom https://github.com/khaledh/axiom

api 3y ago

The problem with C and to C++ is that it’s 2023 and the CVE list is still loaded with basic memory errors. These come from everywhere too: small companies and open source all the way up to Apple, Microsoft, and Google. We as a profession have proven that we can’t write unsafe code at scale and avoid these problems. You might be able to in hand whittled code you write but what happens when other people work on it, it gets refactored, someone pulls in a merge without looking too closely, etc., or even maybe you come back two years later to fix something and have forgotten the details. Having the compiler detect almost all memory errors is necessary. Either that or the language has to avoid this entirely. Rust is the former class unless you use unsafe, and the fact that it’s called “unsafe” makes it trivial to search for. You can automatically flag commits with unsafe in them for extra review or even prohibit it.

flohofwoe 3y ago
I think nobody is arguing the need for static memory safety, just that the poor Rust ergonomics aren't a good tradeoff, especially for scenarios where C is useful. We need many more Rust alternatives that explore into different directions, Rust is already too big and "established" for any radical changes in direction.
- pjmlp 3y ago
  On that regard, by packaging Modula-2 into a C friendly syntax, I do agree Zig is relatively interesting option, however not having a story for binary library distribution is an hindrance in many C dominated industries.
- ParetoOptimal 3y ago
  > I think nobody is arguing the need for static memory safety, just that the poor Rust ergonomics aren't a good tradeoff Unless the "poor ergonomics" and lack of shortcuts are explicitly what provides the static memory safety.
  - flohofwoe 3y ago
    IMHO Rust's ergonomics problems aren't caused by the borrow checker itself, but have the same cause as similar problems in C++ (mainly a "design by committee" approach to language design and implementing features that should be language syntax sugar in the stdlib instead, which then directly results in the stdlib being too entangled with the language and "too noisy" hard to read code). Apart from the static memory safety USP, Rust is repeating too many problems of C++ for my taste, and at a much faster pace.
    - perryizgr8 3y ago
      I agree with this. The borrow checker itself isn't the problem. That's necessary to make you write correct and safe code anyway. The problem is that there is too much syntax, too many symbols, and too many keywords. I just keep forgetting how to use impl and lifetimes and single quotes and whatnot. It makes it really tough to use as an occasional language. And if I can't do that, then how can I get confident enough to use it in my job?
      - jug 3y ago
        Maybe Lobster could be an option. https://strlen.com/lobster/ https://strlen.com/lobster/ https://aardappel.github.io/lobster/memory_management.html https://aardappel.github.io/lobster/memory_management.html It uses compile-time reference counting / lifetime analysis / borrow checking. Which is mostly inlined to the point that there is none of the sort in the compiled output and objects can even live on the stack. It basically looks like Python but is nothing like it underneath, and of course with no GIL. You can run it on JIT or compile it to C++. There's also Koka with the Perceus algorithm on compile time and looks like a much cleaner language than Rust. It also tracks side effects of every function in a type where pure and effectful computations are distinguished. https://github.com/koka-lang/koka https://github.com/koka-lang/koka
- hgs3 3y ago
  When the pendulum swings it often swings far before normalizing somewhere in the middle. I agree that Rust isn't the answer. FWIW there is interest in adding bounds checking to C [1]. That discussion includes feedback from at least one member of the C standards committee. [1] https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-c-fbounds-safety/70854 https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-...
pjmlp 3y ago
It is, however those same companies aren't dialing full safe ahead knob either, hence why Microsoft just recently published a set of secure coding guidelines for C and C++. https://devblogs.microsoft.com/cppblog/build-reliable-and-secure-cpp-programs-microsoft-learn/ https://devblogs.microsoft.com/cppblog/build-reliable-and-se...
- Buttons840 3y ago
  Does it have tooling to enforce those guidelines? If not, how is it better than someone saying "write correct code" and calling it a guideline?
  - pjmlp 3y ago
    Partially, in Visual Studio and GitHub.
  - GoblinSlayer 3y ago
    Following a guideline that checks correctness for you is easier than following "write correct code".
- dayjaby 3y ago
  Quite annoying to read in my native language, German. Do they use automatic translations? It's full of grammar errors and mistranslations.
  - deleted 3y ago
    [deleted]
ernst_klim 3y ago
These are two issues, which a theoretically orthogonal but in practice not so much. These are known as soundness and completeness. A good talk on topic [1] Rust will reject a lot of sound programs, and that's a huge performance hit. You are hitting the incompleteness wall with multiple mutable borrowing, closures in structures are a huge source of pain as well. And usually the answer from the community is "use handlers instead of pointers", but this gives you, surprise surprise, manual resource management alike that in C, and the compiler won't help much. Of course this is all subjective but for me the ergonomics of Rust is far too bad. It's a good step in right direction along with ATS, but I really hope we could do better than this. [1] https://www.youtube.com/watch?v=iSmkqocn0oQ https://www.youtube.com/watch?v=iSmkqocn0oQ
- oneshtein 3y ago
  Can you give us examples, please? I use Rust since version 1.0, and I like it a lot.
  - hgs3 3y ago
    Cyclic data structures are impossible to represent in safe Rust because there is no clear "owner" in a cyclic data structure.
    - oneshtein 3y ago
      Cyclic structures can be flattened into a vector or an arena, or unsafe Rust can be used.
- tene 3y ago
  What are some examples of sound programs you want to write in Rust but are unable to write?
deterministic 3y ago
I maintain very large C and C++ application and very rarely have any memory issues. Tools like Valgrind and Helgrind are excellent for finding and fixing problems. So switching to Rust is a very bad ROI.

khaledh 3y ago

I gave Rust a few chances, and always came out hating its complexity. I needed a systems programming language to develop a hobby OS[1], and Nim hit the sweet spot of being very ergonomic, optional GC, and great interop with C. I can drop down to assembly any time I want, or write a piece of C code to do something exotic, but the rest of the system is pure Nim. It's also quite fast. [1] https://github.com/khaledh/axiom https://github.com/khaledh/axiom