3 ms·

> The problem is simple: if you can have mutable aliasing today in Zig, which you can, then the ecosystem has surely come to depend on it. ... The borrow checke

> The problem is simple: if you can have mutable aliasing today in Zig, which you can, then the ecosystem has surely come to depend on it. ... The borrow checker is not some magic dust that you sprinkle on a language to make it memory safe; the entire language must be designed around it. That's a good description of the issue. It's a bit frustrating to see this notion that Zig is "safe" or comparable to Rust in regards to memory safety at all. I don't prefer to use Rust as it's verbose, but at least I realize that if you don't do the lifetime analysis dance in the language you essentially need a GC to manage memory.

pcwalton 5y ago
> I don't prefer to use Rust as it's verbose, but at least I realize that if you don't do the lifetime analysis dance in the language you essentially need a GC to manage memory. Yep. And that's totally valid! I like using GC'd languages; garbage collectors are some of the most successful systems ever developed in computer science.
- elcritch 5y ago
  It's true, GC's can often even outperform manual memory management or Rust's lifetime analysis. Having a GC doesn't necessarily prevent a language from being a good system language either. I'm using Nim with its ARC garbage collector on embedded devices and it's been fantastic.
  - rocqua 5y ago
    ARC garbage collectors can suffer from reference cycles right? Is that something this Nim configuration suffers from? If so, is it something you noticed in practice?
    - elcritch 5y ago
      Yes, it can. In practice most data seems non-cyclic, and Nim has an 'acyclic' annotation to support it. However as Rust has shown, creating non-cyclic async is really hard, and Nim isn't an exception. That means async requires you run ARC with a cycle collector (ORC), and it works on embedded with tweaks. Overall the non-locking ARC + move semantics runs really fast even on MCUs so it's worth avoiding cyclic strctures.

pcwalton 5y ago

> I don't prefer to use Rust as it's verbose, but at least I realize that if you don't do the lifetime analysis dance in the language you essentially need a GC to manage memory. Yep. And that's totally valid! I like using GC'd languages; garbage collectors are some of the most successful systems ever developed in computer science.

elcritch 5y ago
It's true, GC's can often even outperform manual memory management or Rust's lifetime analysis. Having a GC doesn't necessarily prevent a language from being a good system language either. I'm using Nim with its ARC garbage collector on embedded devices and it's been fantastic.
- rocqua 5y ago
  ARC garbage collectors can suffer from reference cycles right? Is that something this Nim configuration suffers from? If so, is it something you noticed in practice?
  - elcritch 5y ago
    Yes, it can. In practice most data seems non-cyclic, and Nim has an 'acyclic' annotation to support it. However as Rust has shown, creating non-cyclic async is really hard, and Nim isn't an exception. That means async requires you run ARC with a cycle collector (ORC), and it works on embedded with tweaks. Overall the non-locking ARC + move semantics runs really fast even on MCUs so it's worth avoiding cyclic strctures.