Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig and Rust

matklad.github.io

Post reply on HN
Print view View original

111–120 of 247 posts

Re: Zig and Rust

#111

Post by titzer »

crop_rotation wrote: post #19

I tried zig after reading so many HN articles and I am not impressed. You have to remember to free after each allocation. The language is supposed to be simple, yet there exist try, catch, defer, errdefer. Rust enums make defining errors so simple with arbitrary payload. Using data structures in rust is much nicer. I think unless you have some precise needs about memory allocation, and want to control exactly where w…

I think you might actually like Virgil more. It's actually memory safe and has nice enums. It has no way near the adoption of Zig, nor the standard library or batteries included. But it is my fullest expression of what I think a systems programming language should be.

Re: Zig and Rust

#112

Post by steveklabnik »

lr1970 wrote: post #109

From the linked article > When we call malloc, we just hope that we have enough stack space for it, we almost never check. malloc allocates on heap, not stack.

This comment from the author elaborates on what he meant here: https://old.reddit.com/r/Zig/comments/123jpia/blog_post_zig_...

Re: Zig and Rust

#113

Post by connicpu »

haberman wrote: post #96
connicpu wrote: post #72

Earlier quoted context omitted.

There's the third option, which is what Rust and C++ do by default, where types have destructors that are run when the value goes out of scope, but also have mechanisms to be activated manually at a precise moment if you know what you're doing and have specific needs.

RAII is not a silver bullet. RAII wants to have neat recursive ownership and cleanup of everything, which is undoubtedly a nice model, but sometimes in low-level code you have to choose between nice recursive ownership and performance. For example, Protocol Buffers are trees of objects. Originally they were simple and had recursively-owned, heap-allocated nodes. But it turns out that traversing and deleting a big gra…

Which is why low level languages like C++ and Rust make RAII the default in their standard library (easy, simple), but it's still completely possible to manage the memory on your own if that's necessary for the task at hand. Having easy defaults with the capacity to do everything by hand if you need to is the most flexible system.

Re: Zig and Rust

#114

Post by Animats »

crop_rotation wrote: post #19

I tried zig after reading so many HN articles and I am not impressed. You have to remember to free after each allocation. The language is supposed to be simple, yet there exist try, catch, defer, errdefer. Rust enums make defining errors so simple with arbitrary payload. Using data structures in rust is much nicer. I think unless you have some precise needs about memory allocation, and want to control exactly where w…

"(Zig's) collections are not parametrized by an allocator, like in C++ or (future) Rust. Rather, an allocator is passed in explicitly to every method which actually needs to allocate. This is Call Site Dependency Injection, and it is more flexible.'

I'd once considered the idea of having "space" as a type. Space is an array of bytes, and it cannot be read or written. Constructors take in "space" and turn it into an object. Constructors have the privilege of casting "space" to something else. Destructors take an object and turn it back into "space". Destructors can cast their object to "space", and this destroys the data. This separates construction, which is a typed thing, from allocation. It can be used with malloc/free type allocation, garbage collection, or fixed allocation. You'd probably encapsulate this with a generic depending on what type of allocation you are using.

C++ probably would have been cleaner if it took that route, but C++ added both generics and allocators as afterthoughts.

Re: Zig and Rust

#115

Post by netbioserror »

ibiza wrote: post #99
netbioserror wrote: post #20

Still not convinced that memory semantics are critical in the vast majority of domains. Incredibly fast speeds can be achieved with simple GC and RC for short-running programs, and programs with sustained runtimes can rely on generational GC. These methods have the advantage of nearly eliminating the need for memory semantics, leaving only business logic behind. The best example might be Nim, which drastically reduce…

That's a a compelling argument: GC/RC w/ stack allocation where possible. I associate GC w/ pointer chasing and the unavoidable L1, L2, L3 cache trashing that goes w/ it. To what extent is this possible? Does Nim have LTOs that rewrite memory handling across compilation units? I'm guessing no, and instead it's local & one-off, rather than something one can bank on.

https://zevv.nl/nim-memory/

  Local variables (also called automatic variables) are the default method by which Nim stores your variables and data.

  Nim will reserve space for your variable on the stack, and it will stay there as long as it is in scope. In practice, this means that the variable will exist as long as the function in which it is declared does not return. As soon as the function returns the stack unwinds and the variables are gone.

  In Nim, all your data is stored on the stack, unless you explicitly request it to go on the heap.
Strings and seqs are allocated on the heap and accessed via a stack pointer, but the stack pointer controls their lifetimes, and semantically behaves like any other local variable.

Re: Zig and Rust

#116

Post by kaba0 »

flohofwoe wrote: post #62
crop_rotation wrote: post #19

I tried zig after reading so many HN articles and I am not impressed. You have to remember to free after each allocation. The language is supposed to be simple, yet there exist try, catch, defer, errdefer. Rust enums make defining errors so simple with arbitrary payload. Using data structures in rust is much nicer. I think unless you have some precise needs about memory allocation, and want to control exactly where w…

> ...and want to control exactly where when and how memory is allocated... Isn't this the whole point and the reason why manual memory management is still a thing - and actually getting more important with the ever widening CPU/memory latency gap? There simply is no silver bullet for memory management, you can either have high performance or automatic memory management, but not both. (vastly simplified of course - bu…

> There simply is no silver bullet for memory management, you can either have high performance or automatic memory management

That’s only true for workloads where you can optimize the memory layout/allocations. This may not be true in general, where you will end up implementing a shitty GC that will definitely perform worse than a properly written one.

Also, the cost of a proper GC is heavily overblown in my opinion. Especially when value types are available.

Re: Zig and Rust

#117

Post by kaba0 »

connicpu wrote: post #72
flohofwoe wrote: post #62

Earlier quoted context omitted.

> ...and want to control exactly where when and how memory is allocated... Isn't this the whole point and the reason why manual memory management is still a thing - and actually getting more important with the ever widening CPU/memory latency gap? There simply is no silver bullet for memory management, you can either have high performance or automatic memory management, but not both. (vastly simplified of course - bu…

There's the third option, which is what Rust and C++ do by default, where types have destructors that are run when the value goes out of scope, but also have mechanisms to be activated manually at a precise moment if you know what you're doing and have specific needs.

This is by definition manual memory management.

Re: Zig and Rust

#118

Post by flohofwoe »

bitwize wrote: post #91
flohofwoe wrote: post #62

Earlier quoted context omitted.

> ...and want to control exactly where when and how memory is allocated... Isn't this the whole point and the reason why manual memory management is still a thing - and actually getting more important with the ever widening CPU/memory latency gap? There simply is no silver bullet for memory management, you can either have high performance or automatic memory management, but not both. (vastly simplified of course - bu…

> There simply is no silver bullet for memory management, you can either have high performance or automatic memory management, but not both. RAII is the way.

RAII for memory management implies that destructors free owned memory, which can quickly cascade out of control for complex objects (e.g. you still need to think very carefully about memory management).

Re: Zig and Rust

#119

Post by kaba0 »

hhhhmycmd22 wrote: post #97
crop_rotation wrote: post #19

I tried zig after reading so many HN articles and I am not impressed. You have to remember to free after each allocation. The language is supposed to be simple, yet there exist try, catch, defer, errdefer. Rust enums make defining errors so simple with arbitrary payload. Using data structures in rust is much nicer. I think unless you have some precise needs about memory allocation, and want to control exactly where w…

That's my complaint about Zig as well coming from C. I feel that there are too many reserved words in Zig, and some of them are too long (comptime for instance). Maybe that's just me being too picky about surface level concerns, but that kind of stuff really bothers me for some reason. Other than that, I do like some parts of Zig. The way templates are designed seems superior to C macros and C++ templates, having you…

> The way templates are designed seems superior to C macros

Everything is superior to C macros, that’s like the worst thing ever created. Honestly, C is not a good language but if it would have had at least a proper macro system it could at least be remotely usable, e.g. having proper generic data structures.

Re: Zig and Rust

#120

Post by kaba0 »

snek_case wrote: post #66
MrBuddyCasino wrote: post #29

Earlier quoted context omitted.

> I think unless you have some precise needs about memory allocation, and want to control exactly where when and how memory is allocated, it is hard to argue in favour of Zig. I do have a hard time to think of use cases other than embedded microcontroller work where that matters nowadays. That said, I suspect that while they could have written TigerBeetle in Rust (no_std does not assume the existence of an allocator)…

JIT compilers, games, database server. Anything where you need high performance and do a lot of allocations.

JIT compilers don’t actually need that low-level programming, and compilers in general use memory in a very haphazard way so they are likely better off with a GC.

In fact, you probably loose way more by not being able to write as many/great optimizations in a low-level language than what you lose on a slight overhead — e.g. Java’s Graal JIT compiler is nowadays performing better (written in Java itself) than the “original” C2 compiler which is written in C++. But this is mostly a maintainability question.

Post reply on HN