Live data from Hacker News

Problems of C, and how Zig addresses them

avestura.dev

151–160 of 290 posts

Re: Problems of C, and how Zig addresses them

#151

I really want to like Zig. Honest question: why is Zig so resistant to some kind of RAII? RAII is the biggest improvement that C++ brings over C. Leaving it out of a system programming language 50 years later is just strange? And no, manual defer is not the solution.

I felt that way at first too but I’m less concerned about it the more I use Zig. Defer and errdefer are already a huge improvement over C. I won’t deny there’s more risk of forgetting to clean up than in Rust or C++, but Zig’s approach forces me to think more clearly about what’s going on. For example, instead of doing a slow tree traversal to free little bits of memory all over the place (which RAII would do implicitly), in Zig I’d probably use an arena and free it all at once. A similar principle applies to other non-memory resources too (though maybe not mutexes for example). I also think it would be difficult to achieve the flexibility of Zig’s unmanaged containers (where deinit takes a parameter) in a RAII language.

Re: Problems of C, and how Zig addresses them

#152
post #97

One thing Zig is missing is Exception Handling. Now before you complain about exception handling grossly bloating the size of a program, know that there are ways to trigger exceptions that do not involve the "throw" keyword. You get processor exceptions when you access a bad pointer, divide by 0, etc. If you don't want the program to instantly terminate, you need to be able to handle those exceptions. So far, it seem…

I know basically nothing about Zig, but you don't need language-level exceptions to handle platform exceptions. You can write the handler code in C. Why can't you write it in Zig? The usual problem is that the language runtime gets in the way, but I thought Zig had a very minimal runtime like C.

__try and __except are win32-specific language extensions for C that do not exist in Zig. They become code which adds a linked-list item (exception handler entry) somewhere into the TEB. Win32 requires that you call all the Stack Unwind entries within your exception handler. When your exception handler is done, you longjmp out, or return to the offending code. Using the language extensions for exception handling is far more friendly than doing it manually with low-level code.

Re: Problems of C, and how Zig addresses them

#153

Earlier quoted context omitted.

It is a feature that sounds like it promises to make something compile time but it doesn't. At the same time it has a bunch of limitations, that in no way reflects what modern compilers can do. Plenty of times you can write an expression and if you say its a constexpr, the compiler is forced to tell you that its not a valid constexper, but if you just remove the constexper qualifier, the compiler the compiler can sol…

Gotcha. To be honest, this description sounds like what constexpr is in C++ as well, and various `const` things in Rust. I thought you were saying that the feature doesn't work, but it sounds more like you don't like how the feature was designed. Thank you for letting me know!

Well, its broken in the sense that one part of the standard describes some functionality, and then an other part of the standard, says "Oh you can ignore that."

Re: Problems of C, and how Zig addresses them

#154

I really want to like Zig. Honest question: why is Zig so resistant to some kind of RAII? RAII is the biggest improvement that C++ brings over C. Leaving it out of a system programming language 50 years later is just strange? And no, manual defer is not the solution.

The most frequently given reason is that a core principle for Zig is ‘No implicit control flow’ or just the more general ‘Explicit is always better’. RAII, both for constructors and destructors are inherently implicit control flow constructs, also they usually involve access to allocation primitives, which Zig also rejects when implicit. You can disagree with the language principles if that is one’s position. However…

I assume that zig requires the programmer to also manually allocate and free stack frames? And it eschews functions as they can hide allocations and control flows?

Re: Problems of C, and how Zig addresses them

#155

Earlier quoted context omitted.

Counterpoint: C itself invented lot of syntax compared to the contemporary ALGOLs and PL/I. Yet, it became immensely popular.

I would dare say, different combination of early adopters/pragmatists in your target audience. C/C++ these days is mostly legacy stuff, so if you want to cater to that audience, you deliver small incremental improvements. Many people that could be bothered to learn Zig syntax, jumped ship to Python/Java/whatever already.

Legacy stuff like the compiler and runtime used by the new hip languages or the webserver, browser, database, libraries needed to run those programs, or the OS, hypervisor, device drivers needed by the machine those programming run on.

Re: Problems of C, and how Zig addresses them

#156

Earlier quoted context omitted.

Having spent a lot of time porting 32bit system code to 64bit, I developed a dislike for these explicit types. It's a slippery slope to hard code your bitness with people making assumptions where size_t or pointers fit. Now maybe if you're already 64bit that's fine (it's unlikely that we'll ever need 128bit, and code is unlikely to grow down), but for anything starting smaller it's a pain.

Just because your code compiles on a new platform doesn't mean the prior assumptions of the prior behavior of the types remains valid.

But it should, and that's what stricter typing can help with.

Re: Problems of C, and how Zig addresses them

#157

Earlier quoted context omitted.

I don't quite understand how do you change the size of a zig hashmap in runtime by, for example, inserting 1M items at some point but at the same time being able to enforce in compile-time that such operation will not result with dynamic allocation?

Compare these two methods: https://github.com/ziglang/zig/blob/0dffab7356685c7643aa6e3c... https://github.com/ziglang/zig/blob/0dffab7356685c7643aa6e3c... One of them requires passing an allocator (and can allocate), the other doesn’t have an allocator argument (and thus can’t allocate). If you only pass allocator to `init` method of your application, and don’t store it anywhere, only init will be able to call alloca…

If the second one can't allocate then how does it handle the case where you don't have enough capacity to insert the new (k,v) pair?

I can see that the difference between the two is in self.growIfNeeded() call, https://github.com/ziglang/zig/blob/0dffab7356685c7643aa6e3c..., which the one that doesn't allocate really doesn't have. Does it assume that the predefined capacity will not be reached?

Re: Problems of C, and how Zig addresses them

#158

Tangentially... I'm grateful that these new batches of systems languages have chosen to use the u8, i32, etc, style integer types. Rather than the uint8_t and int32_t style. First thing I do in any of my low level embedded C projects is put in the various uNN/iNN types.

Having spent a lot of time porting 32bit system code to 64bit, I developed a dislike for these explicit types. It's a slippery slope to hard code your bitness with people making assumptions where size_t or pointers fit. Now maybe if you're already 64bit that's fine (it's unlikely that we'll ever need 128bit, and code is unlikely to grow down), but for anything starting smaller it's a pain.

People are already working on a 128bit Linux kernel.

Re: Problems of C, and how Zig addresses them

#159

I'm super sold on Zig except that it doesn't make graphics/vector coding with operator overloading possible :( I've heard what Andrew Kelley has to say about it ("that ONE little feature from C++...") but it's just a very sad situation for what otherwise looks like a lovely basis for graphics coding. Actually, I don't even want operator overloading in general (leading to stuff like the C++ stream API), it's JUST for…

Last year I dabbled in making a DSL like solution for operator overloading: https://github.com/Laremere/alg

It ends up slightly more verbose in usage, but the statements themselves remain concise. Unfortunately I got a real job that isn't using Zig, so I've stopped working on this. Others can feel free to take up the torch, though.

Re: Problems of C, and how Zig addresses them

#160

I remain confused about how Zig makes it to the front page of Hacker News so often. As far as I know, no one is using it in production after 7 years of development. Are people just really excited about this project? Are the people behind it just really good at marketing? Honest question: why do we all keep talking about Zig?

Andrew Kelley's intro[0] is probably the best talk I've ever seen, and his continuing leadership seems really great to me and worth supporting. Besides my reservations for its use in graphics programming (see my other comment) it looks very attractive in many practical ways (build system!! fuck CMake!) I could go from how I currently write my hobby code, sometimes a prototype for future commercial code. [0] https://w…

This is easily one of the best programming talks I have ever seen, I loved the "no compiler magic" compile-time-known string formatting, and generics literally becoming a thing without magic either.
Post reply on HN