Hacker News Reader

Comment by Comevius | Hacker News Reader

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.

View on HN

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

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

Herein lies the second biggest barrier to Rust's viability in embedded systems. (The first being that no microcontroller OEM ships libraries for Rust)

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.

Here is an example with a keyboard firmware why you might not always want all that complexity.

https://kevinlynagh.com/rust-zig/

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.

I read the thread about the keyboard at the time. The author literally said it was a hobby project and they weren't concerned about safety, which is why they weren't interested in all of the solutions people offered for their problems with Rust. Zig's fine if you don't care about safety. But that's not really how I've heard it advertised.

> but otherwise they don't hinder you to do whatever

Neither does Rust! You can choose to ignore what the compiler wants you to do and just program with unsafe everywhere. The difference is that you don't have the option of writing safe code in Zig and C.

> It's up to you to solve problems like memory safety.

And so far, memory safety is not actually a problem that programmers have been able to solve by sheer force of will without borrow checkers or garbage collection. For a subset of trivial programs, sure. But not at any reasonable scale.

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

You're mistaken.

https://en.wikipedia.org/wiki/Memory_safety#Approaches

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

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.

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

It doesn't fix C flaws like use after free, hardly warts-free.

That's not a C flaw, you can use an allocator that prevents use-after-free.

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.

Just like C memory debuggers for the last 30 years, so what is the benefit?

Defer, comptime, far better cross file model, yo name just a few things

For the price of an ecosystem with the same security flaws, hardly worth it.

Much easier to just use C+.

Reply on news.ycombinator.com