4 ms·

Zig is great for low-level use cases like embedded, especially where performance is a high priority and memory safety doesn't offer as much benefit as in other

Zig is great for low-level use cases like embedded, especially where performance is a high priority and memory safety doesn't offer as much benefit as in other domains [0]. Nim's also geared towards systems programming, though it does so with an RC foundation. It's features are well-designed and complement that pretty well. Vale's more geared towards the higher-level cases (games, apps, servers) where memory safety, performance, and developer productivity are all priorities. It's meant to be more of a "software engineering" language, focusing on keeping things loose and decoupled in the large, while offering tools like regions [1] (not done yet) to eliminate overhead everywhere it can. [0] https://verdagon.dev/blog/when-to-use-memory-safe-part-1 https://verdagon.dev/blog/when-to-use-memory-safe-part-1 [1] https://verdagon.dev/blog/zero-cost-memory-safety-regions-overview https://verdagon.dev/blog/zero-cost-memory-safety-regions-ov...

zozbot234 4y ago
Rust will probably encompass most of these use cases eventually. Features like e.g. RC with efficient cycle collection as found in Nim, or generational regions as found in Vale, will simply be implemented as add-on crates in Rust, complementing the existing borrow checker.
- verdagon 4y ago
  There are some design decisions mean Rust can't work with generational references and regions, unfortunately. They're incompatible with their form of borrow checking. In Vale, each struct has a generation in theory, but they are often merged with their parent struct. It requires some pretty interesting logic which can't be implemented in Rust. Regions require truly immutable references, which Rust doesn't have. Their shared references are unfortunately foiled by the RefCell escape hatch. Additionally, the rest of Vale's future design prioritizes developer productivity more than Rust has, in my opinion: - A coroutine-like mechanism instead of Rust's async/await function coloring, and structured concurrency which doesn't involve the Sync/Send "data coloring" problem. - Vale's borrowing is done on the region level and on an opt-in basis, so users can decide to only use borrow checking where it makes sense. - Linear typing ("Higher RAII") which allows for different static checks which aren't quite as infectious as aliasability-xor-mutability. I love Rust, but it has some quirks that make it much more suited to low-level development than these higher user cases. I don't see how Rust can fix them, but there are some smart people working on it and I hope they figure out a way, because the world needs a fast and safe language that's easy to learn and focuses on productivity, even if it's not Vale ;)
  - zozbot234 4y ago
    I don't disagree that Rust's developer productivity story is still far from mature, especially wrt. async and its ecosystem (and the Rust design team agrees that this is a concern) but if you're going to argue for Vala as a "future design", we should similarly assess Rust's long-term potential. The language is improving quite fast and adding major new features (consider GAT and improvements in const evaluation) despite being quite stable and reliable in other respects. Very different from most "corporate"-focused languages. (Don't get me wrong, I'm quite fine with also focusing on hobbyist, proof-of-concept languages for potential improvements to developer productivity. But then I'll probably want a Pony.)
    - verdagon 4y ago
      That's a fair perspective. I don't have the same faith in Rust's dominance for high-level use as these problems seem inherent to their kind of borrow checking, but its possible they can compensate for it with improvements like the ones you mentioned.
- elcritch 4y ago
  I'm not sure that'll be likely. If anything Rust gets more complicated with GADT's and such. While GADT's makes sense, Rust's fundamental philosophy lends toward verbosity and low level semantics in my opinion. Don't get me wrong, it encourages very memory efficient code but its also tedious to write. Take RC for example, but you can already do efficient RC in Rust. It's just not as pleasant or easy as in Nim. Rust Rc's still require a fair bit of details about using and borrowing the memory, passing references to non-rc functions, etc. Also Nim could just compile to Rust as a backend. ;)

zozbot234 4y ago

Rust will probably encompass most of these use cases eventually. Features like e.g. RC with efficient cycle collection as found in Nim, or generational regions as found in Vale, will simply be implemented as add-on crates in Rust, complementing the existing borrow checker.

verdagon 4y ago
There are some design decisions mean Rust can't work with generational references and regions, unfortunately. They're incompatible with their form of borrow checking. In Vale, each struct has a generation in theory, but they are often merged with their parent struct. It requires some pretty interesting logic which can't be implemented in Rust. Regions require truly immutable references, which Rust doesn't have. Their shared references are unfortunately foiled by the RefCell escape hatch. Additionally, the rest of Vale's future design prioritizes developer productivity more than Rust has, in my opinion: - A coroutine-like mechanism instead of Rust's async/await function coloring, and structured concurrency which doesn't involve the Sync/Send "data coloring" problem. - Vale's borrowing is done on the region level and on an opt-in basis, so users can decide to only use borrow checking where it makes sense. - Linear typing ("Higher RAII") which allows for different static checks which aren't quite as infectious as aliasability-xor-mutability. I love Rust, but it has some quirks that make it much more suited to low-level development than these higher user cases. I don't see how Rust can fix them, but there are some smart people working on it and I hope they figure out a way, because the world needs a fast and safe language that's easy to learn and focuses on productivity, even if it's not Vale ;)
- zozbot234 4y ago
  I don't disagree that Rust's developer productivity story is still far from mature, especially wrt. async and its ecosystem (and the Rust design team agrees that this is a concern) but if you're going to argue for Vala as a "future design", we should similarly assess Rust's long-term potential. The language is improving quite fast and adding major new features (consider GAT and improvements in const evaluation) despite being quite stable and reliable in other respects. Very different from most "corporate"-focused languages. (Don't get me wrong, I'm quite fine with also focusing on hobbyist, proof-of-concept languages for potential improvements to developer productivity. But then I'll probably want a Pony.)
  - verdagon 4y ago
    That's a fair perspective. I don't have the same faith in Rust's dominance for high-level use as these problems seem inherent to their kind of borrow checking, but its possible they can compensate for it with improvements like the ones you mentioned.
elcritch 4y ago
I'm not sure that'll be likely. If anything Rust gets more complicated with GADT's and such. While GADT's makes sense, Rust's fundamental philosophy lends toward verbosity and low level semantics in my opinion. Don't get me wrong, it encourages very memory efficient code but its also tedious to write. Take RC for example, but you can already do efficient RC in Rust. It's just not as pleasant or easy as in Nim. Rust Rc's still require a fair bit of details about using and borrowing the memory, passing references to non-rc functions, etc. Also Nim could just compile to Rust as a backend. ;)