3 ms·
Zig has so many compelling features, and I'd even be willing to give up Rust's near-perfect memory safety in some cases. But the one thing that really put me of
by IshKebab 5mo ago
Zig has so many compelling features, and I'd even be willing to give up Rust's near-perfect memory safety in some cases. But the one thing that really put me off is string handling. It's just so super tedious. I like being able to finely manage individual string memory allocations, but I really don't want to have to do it all the time. RAII is great; I wish they'd use some light (optional) RAII for strings and containers etc.
- metaltyphoon 5mo agoFor me it’s string handling, no private, unused variable is compilation error, and having to implement interfaces myself.
- nusaru 5mo agoWhy not use an arena allocator?
- IshKebab 5mo agoTbh I don't know enough Zig to answer that. Can you give an example? E.g. some non-performance-sensitive function that returns a string? In Rust and C++ you can treat the string exactly the same as you would an integer and it's super easy. In C you have pain. Does the caller allocate a buffer? How does it know how big to make it? Do you have to have separate calls to calculate the required length? Etc. Can Zig work like Rust/C++ and not like C? My impression is that it can't.
- justinhj 5mo agoAn arena allocator lets you treat a series of allocations as a single block. In cases where you find yourself needing to micromanage a bunch of small memory allocations you can simply ignore freeing them individually and free the whole arena when you are done.
- IshKebab 5mo agoYeah sorry I know what an arena allocator is. I meant how can you write code that deals with strings (joining, formatting, passing around etc.) but isn't sensitive to performance (so `std::string`-like performance is fine) in Zig without having to deal with tedious low level allocator details. If I have to pass an allocator around everywhere that's a pain in the bum. Apparently Zig doesn't have a global allocator so it seems like you can't. (And it seems like the allocation details aren't encoded in the type anyway so it will be a disaster if you start mixing up global and non-global allocator types anyway.)
- justinhj 5mo agoPassing an allocator around is a design choice of Zig, so yeah, it is not supposed to be avoided
- onlyrealcuzzo 5mo ago> RAII is great; I wish they'd use some light (optional) RAII for strings and containers etc. Is it not possible to build a wrapper that does this? It seems like it should be.
- Arch485 5mo agoIt is. I definitely agree that strings in Zig can be tedious, but the upside is that if you need it, you can build a string library that does everything you want it to do, in the way you want. For comparison, while Rust offers a very rich string library, it's also very strict about what you can/cannot do with strings, so if your use case falls outside of that you're out of luck. With Zig, you can pretty easily roll your own and make it do what you want. (and when Zig is post 1.0, I imagine there will be some very nice pre-made string libraries by the community etc.)
- steveklabnik 5mo agoYou can also roll your own strings in Rust just fine. Take the bstr crate, for example.
- ngrilly 5mo agoBut I don't think you can implement RAII in Zig?
- lenkite 5mo agoLibrary interoperability becomes a PITA when everyone builds their own string library. Then you need conversion libraries.