5 ms·

There is nothing fundamental about ownership-based resource management, memory-safety can be achieved in other ways. Zig is C, it's not meant to abstract away m

There is nothing fundamental about ownership-based resource management, memory-safety can be achieved in other ways. Zig is C, it's not meant to abstract away memory management. You can do whatever in Zig, write a specialized allocator that's verified to be correct, even for a microcontroller with 2 KiB memory. Zig is a machine-oriented language, which means no hidden control flow, no hidden allocation. You can write a garbage collector or a compiler like Rust has too if that's what you need.

pjmlp 5y ago
Thing is, if Zig is C, why bother at all, we already have C for it.
- Comevius 5y ago
  Zig is warts-free C, but you can use them together. You can gradually refactor your C codebase, Zig can even transpile C. Zig is also a standalone C toolchain, compiling and cross-compiling C is a breeze with it, and it has it's own libc implementation.
  - pjmlp 5y ago
    It doesn't fix C flaws like use after free, hardly warts-free.
    - Comevius 5y ago
      That's not a C flaw, you can use an allocator that prevents use-after-free. https://github.com/bwickman97/ffmalloc https://github.com/bwickman97/ffmalloc The point of C and Zig is that they are low level and you can do whatever, like not use an allocator, or write an allocator.
      - pjmlp 5y ago
        Just like C memory debuggers for the last 30 years, so what is the benefit?
  - delphLonepaw 5y ago
    it does not have it's own implementation of libc, it just makes easier to work with implementations of libc and letting the cross compile, I think it was like that. However a libc is a thing that zig probably wants and something I am also thinking on doing if I have the time
- ayende 5y ago
  Defer, comptime, far better cross file model, yo name just a few things
  - pjmlp 5y ago
    For the price of an ecosystem with the same security flaws, hardly worth it. Much easier to just use C+.
jolux 5y ago
> memory-safety can be achieved in other ways I mean, as far as achieving it at compile time, I would say it remains to be seen whether Zig's approach is one of these ways. There are certainly other known approaches, like the way ATS models pointers as proof objects, but these are also fairly abstract. > Zig is C, it's not meant to abstract away memory management. This is just hiding the ball though. Why don't we want abstractions on memory management? There is no runtime cost to providing the abstraction that Rust does. As such, "machine-oriented" is an ambiguous description of the difference here. The whole lesson of Rust is that there's nothing fundamental about the abstractions the machine itself provides, and we can create better abstractions without losing our orientation to those concerns.
- anonymoushn 5y ago
  > There is no runtime cost to providing the abstraction that Rust does. This is technically true, but if I want to write a program that does not call malloc in its steady state, I can't use the stdlib or any library that uses the stdlib.
  - ryukoposting 5y ago
    Herein lies the second biggest barrier to Rust's viability in embedded systems. (The first being that no microcontroller OEM ships libraries for Rust)
    - jolux 5y ago
      But this is not a fundamental limitation, there's nothing about the language that requires you to use heap allocation. That it contains affordances for safe heap allocation is a good thing, but you're not required to use them. There's always no_std and unsafe.
- Comevius 5y ago
  Here is an example with a keyboard firmware why you might not always want all that complexity. https://kevinlynagh.com/rust-zig/ https://kevinlynagh.com/rust-zig/ https://zig.news/aransentin/analysis-of-the-overhead-of-a-minimal-zig-program-4lg0 https://zig.news/aransentin/analysis-of-the-overhead-of-a-mi... The point of languages like C and Zig is that they are only a bit higher level than assembly for portability, but otherwise they don't hinder you to do whatever. It's up to you to solve problems like memory safety. You might not even have a memory safety problem because you don't have memory in the first place, or your use case makes memory safety trivial.
octoberfranklin 5y ago
> nothing fundamental about ownership-based resource management, memory-safety can be achieved in other ways. Not other ways. One other way. Just one. Garbage collection.
- jibalt 5y ago
  You're mistaken. https://en.wikipedia.org/wiki/Memory_safety#Approaches https://en.wikipedia.org/wiki/Memory_safety#Approaches

pjmlp 5y ago

Thing is, if Zig is C, why bother at all, we already have C for it.

Comevius 5y ago
Zig is warts-free C, but you can use them together. You can gradually refactor your C codebase, Zig can even transpile C. Zig is also a standalone C toolchain, compiling and cross-compiling C is a breeze with it, and it has it's own libc implementation.
- pjmlp 5y ago
  It doesn't fix C flaws like use after free, hardly warts-free.
  - Comevius 5y ago
    That's not a C flaw, you can use an allocator that prevents use-after-free. https://github.com/bwickman97/ffmalloc https://github.com/bwickman97/ffmalloc The point of C and Zig is that they are low level and you can do whatever, like not use an allocator, or write an allocator.
    - pjmlp 5y ago
      Just like C memory debuggers for the last 30 years, so what is the benefit?
- delphLonepaw 5y ago
  it does not have it's own implementation of libc, it just makes easier to work with implementations of libc and letting the cross compile, I think it was like that. However a libc is a thing that zig probably wants and something I am also thinking on doing if I have the time
ayende 5y ago
Defer, comptime, far better cross file model, yo name just a few things
- pjmlp 5y ago
  For the price of an ecosystem with the same security flaws, hardly worth it. Much easier to just use C+.

jolux 5y ago

> memory-safety can be achieved in other ways I mean, as far as achieving it at compile time, I would say it remains to be seen whether Zig's approach is one of these ways. There are certainly other known approaches, like the way ATS models pointers as proof objects, but these are also fairly abstract. > Zig is C, it's not meant to abstract away memory management. This is just hiding the ball though. Why don't we want abstractions on memory management? There is no runtime cost to providing the abstraction that Rust does. As such, "machine-oriented" is an ambiguous description of the difference here. The whole lesson of Rust is that there's nothing fundamental about the abstractions the machine itself provides, and we can create better abstractions without losing our orientation to those concerns.

anonymoushn 5y ago
> There is no runtime cost to providing the abstraction that Rust does. This is technically true, but if I want to write a program that does not call malloc in its steady state, I can't use the stdlib or any library that uses the stdlib.
- ryukoposting 5y ago
  Herein lies the second biggest barrier to Rust's viability in embedded systems. (The first being that no microcontroller OEM ships libraries for Rust)
  - jolux 5y ago
    But this is not a fundamental limitation, there's nothing about the language that requires you to use heap allocation. That it contains affordances for safe heap allocation is a good thing, but you're not required to use them. There's always no_std and unsafe.
Comevius 5y ago
Here is an example with a keyboard firmware why you might not always want all that complexity. https://kevinlynagh.com/rust-zig/ https://kevinlynagh.com/rust-zig/ https://zig.news/aransentin/analysis-of-the-overhead-of-a-minimal-zig-program-4lg0 https://zig.news/aransentin/analysis-of-the-overhead-of-a-mi... The point of languages like C and Zig is that they are only a bit higher level than assembly for portability, but otherwise they don't hinder you to do whatever. It's up to you to solve problems like memory safety. You might not even have a memory safety problem because you don't have memory in the first place, or your use case makes memory safety trivial.

octoberfranklin 5y ago

> nothing fundamental about ownership-based resource management, memory-safety can be achieved in other ways. Not other ways. One other way. Just one. Garbage collection.

jibalt 5y ago
You're mistaken. https://en.wikipedia.org/wiki/Memory_safety#Approaches https://en.wikipedia.org/wiki/Memory_safety#Approaches