3 ms·

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 usef

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
    - kramerger 3y ago
      > 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. This is exactly how I feel about Rust. There are some good ideas in there, hiding behind a horrible language design. I am waiting for someone to provide a more developer friendly alternative with the simplicity of C or Go.
  - pjmlp 3y ago
    In that regard, strangely enough, I find with constexpr code, templates, and concepts, is easier to achieve most compile time code stuff, while staying in C++, than dealing with Rust macros.
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

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
  - kramerger 3y ago
    > 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. This is exactly how I feel about Rust. There are some good ideas in there, hiding behind a horrible language design. I am waiting for someone to provide a more developer friendly alternative with the simplicity of C or Go.
- pjmlp 3y ago
  In that regard, strangely enough, I find with constexpr code, templates, and concepts, is easier to achieve most compile time code stuff, while staying in C++, than dealing with Rust macros.

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-...