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

61–70 of 247 posts

Re: Zig and Rust

#61

Post by throwawaymaths »

steveklabnik wrote: post #58
throwawaymaths wrote: post #53

Earlier quoted context omitted.

what if you want there to be individual allocators (of the same type) that you want to point differently based on . For example in a M:N greenthreaded system perhaps you want each greenthread to have its own arena allocator. But you can't use something like threadlocal, because at any time a greenthread might move to any given OS thread? Is that possible in rust?

1. You can do anything you want in Rust, you can make your own collections do whatever you want at any time. 2. These changes are about two things, 2a. the first of which is a trait that represents the concept of an allocator, in case users' code would like to be generic over ones that exist in the ecosystem. You can of course still paper over this yourself but the whole point of a vocabulary trait is so that you don…

sorry, I should have been clear: I meant with a standard lib provided data structure.

Thanks!

Re: Zig and Rust

#62

Post by flohofwoe »

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 - but in languages with automatic memory management - no matter if garbage collection or refcounting - you need to spend so much effort to reduce memory management overhead that it is usually less work to do it all manually in the first place)

Re: Zig and Rust

#63

Post by mustache_kimono »

haberman wrote: post #44

> First, I think Zig’s strength lies strictly in the realm of writing “perfect” systems software. It is a relatively thin slice of the market, but it is important. This resonates with me. This is exactly why I use C today, and why Zig appeals to me.

This definition of "perfect" might be counterintuitive for those that haven't read the piece.

The idea is there might some ideal memory allocation scenario that Rust doesn't do "perfectly" that you can theoretically do better in Zig, which I buy. Most particularly, my experience with arenas and defer drop is -- they aren't always perfectly easy in Rust. But this definition of perfection tends to ignore all the manual, boilerplate memory management you have to do in the interim, that you may still mess up in some subtle way.

Re: Zig and Rust

#64

Post by [deleted] »

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…

[deleted]

Re: Zig and Rust

#65

Post by [deleted] »

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…

[deleted]

Re: Zig and Rust

#66

Post by snek_case »

MrBuddyCasino wrote: post #29
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 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.

Re: Zig and Rust

#67

Post by childintime »

Zig appeals to the “lone genius hackers”. I'd read this as the folks that like to know all the code in their code base, as is typical for embedded or moderate size projects. Folks that do not need (and resent) the abstractions made for every use case under the sun, which to them only ends up making the code harder to read and to comprehend.

Though Rust does an admirable job, and things are much better than for OOP languages, it's still a behemoth. Take a (any) small project, and the amount of dependencies upon dependencies explodes. A project easily takes up 1GB on disk, and it is impossible to know exactly what has been pulled in, or why. How much of this code actually ends up in the binary? It feels like a small fraction, like 5% (or even 1%), but that 95% is there and causes breakage. Now you have to debug something that's literally out of your world. It's not Rust, its the build. No matter how small the actual issue is, you are not qualified to find it.

Note that Zig's build system provides the exact opposite experience. Errors are always relevant, and can (therefore) always be solved.

In summary Rust takes away the helicopter view. Yes, in return it provides an unparalleled level of assurances, it really is magic. But I find myself returning to the roots, and Zig feels tasty. I bet Chatgpt will then handily convert the project, when done, to Rust, faster than I ever could.

Re: Zig and Rust

#68

Post by nindalf »

childintime wrote: post #67

Zig appeals to the “lone genius hackers”. I'd read this as the folks that like to know all the code in their code base, as is typical for embedded or moderate size projects. Folks that do not need (and resent) the abstractions made for every use case under the sun, which to them only ends up making the code harder to read and to comprehend. Though Rust does an admirable job, and things are much better than for OOP la…

You don’t need to pull in dependencies if you don’t want to.

But if you do, the contracts on ownership enforced by the compiler allows the software to compose better.

Re: Zig and Rust

#69

Post by klyrs »

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…

> Still not convinced that memory semantics are critical in the vast majority of domains.

This is okay. Zig is not targeting the vast majority of domains. It targets the low-level, performance-critical domain that C occupies. It would be a great language to write a compiler/interpreter for a higher-level language that has the bells and whistles that you want.

Re: Zig and Rust

#70

Post by monocasa »

messe wrote: post #11
olodus wrote: post #2

Probably just a small miss, but in the first section the author refers to stack space limitations possibly hit when calling malloc. That should probably refer to heap space. Or if it is stack space they meant then maybe not malloc but rather stack allocations / function calls.

I think they’re actually referring the stack usage from the function call itself (the creation of a new stack frame). I believe the point the author is making is that while it’s common to check the return value of malloc to see if heap allocation was successful, it’s comparatively rare to do any analysis of stack usage to verify that none of your function calls are going to cause a stack overflow.

Rust at least will stack probe to trigger any guard pages upon allocation.
Post reply on HN