Problems of C, and how Zig addresses them • Hacker News Board

Re: Problems of C, and how Zig addresses them

#121

Post by Cyberdog » Mon, Jul 03, 2023, 7:33 PM UTC

andrewedstrom wrote: post #112

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?

I can't answer you why Zig keeps showing up on HN (except for the surface-level answer that people keep submitting and upvoting it) but in terms of not being used in production, the Bun project, a Node/Deno alternative, is seeing a good deal of momentum by the people who like JavaScript a bit too much. It's probably the most widely used Zig project so far, including in production.

https://bun.sh

Re: Problems of C, and how Zig addresses them

#122

Post by steveklabnik » Mon, Jul 03, 2023, 7:37 PM UTC

quelsolaar wrote: post #120

steveklabnik wrote: post #91

Earlier quoted context omitted.

In what way? I haven't had the opportunity to try it out myself yet.

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!

Re: Problems of C, and how Zig addresses them

#123

Post by tialaramex » Mon, Jul 03, 2023, 7:40 PM UTC

flohofwoe wrote: post #74

square_usual wrote: post #27

You can repeat "C is a minimal abstraction over assembly" as many times as you want, it doesn't make it true.

Technically that's true because of the "C virtual machine", but pragmatically, C is still the "lowest-level high-level programming language" at least among the popular programming languages (arguably only Forth is lower level, but Forth isn't exactly mainstream). (and I'd argue that C is closer to assembly than assembly is to what's actually happening inside the CPU, e.g. assembly itself is a high-level abstraction l…

You're thinking of the C abstract machine, not a virtual machine. Abstract art is when this is a painted blue circle but it's about the feeling of sadness when losing somebody close to you - virtual art is when somebody persuades you a crappy GIF of a monkey is worth a million dollars.

And no, it's just not usefully true to model things this way. The C abstract machine is pretty weird even compared to a PDP-11, and your modern computer is nothing like a PDP-11.

C was intended to be efficiently implementable, so that's nice, but it has numerous defects in practice in this regard, because it pre-dates a lot of discoveries about how to implement programming languages.

The machine doesn't have types. At all. They're just not a thing. C has types. They're not very good types, and they're poorly implemented, but they are definitely types. Several other languages from that era don't bother, C does because it's a "high level language" and you'll do better embracing that understanding than trying to pretend it's assembler.

Re: Problems of C, and how Zig addresses them

#124

Post by tayistay » Mon, Jul 03, 2023, 7:41 PM UTC

From the article:

  const result = comptime square("hello"); // compile time error: type mismatch

ok, cool. But if the error occurs deep in some hierarchy of comptime calls, do you get the same kind of long errors that you do with C++ templates? Does zig have a way of achieving better ergonomics? One nice thing about generics in Rust and Swift is they are constrained by traits/interfaces so you get a concise error at the call site.

Re: Problems of C, and how Zig addresses them

#125

Post by pavlov » Mon, Jul 03, 2023, 7:41 PM UTC

stephc_int13 wrote: post #90

sieabahlpark wrote: post #84

Earlier quoted context omitted.

It sounds like you got some refactoring to use since you didn't namespace your own core types?

I think that "namespacing" basic types such as u32 is completely unecessary. In what world would an u32_MYLIB would be different than an u32_SOMELIB? Basic types are common enough.

The preprocessor doesn’t know that u32 defined in foo.h is the same type as u32 defined in bar.h. So you’ll get an error when importing both.

Re: Problems of C, and how Zig addresses them

#126

Post by andikleen2 » Mon, Jul 03, 2023, 7:42 PM UTC

travisgriggs wrote: post #18

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.

Re: Problems of C, and how Zig addresses them

#127

Post by quic5 » Mon, Jul 03, 2023, 7:46 PM UTC

tayistay wrote: post #124

From the article: const result = comptime square("hello"); // compile time error: type mismatch ok, cool. But if the error occurs deep in some hierarchy of comptime calls, do you get the same kind of long errors that you do with C++ templates? Does zig have a way of achieving better ergonomics? One nice thing about generics in Rust and Swift is they are constrained by traits/interfaces so you get a concise error at t…

A good api (like std.debug.print for example) can implement nice compile errors that fail early with readable messages manually at comptime. Still not as convenient as traits though

Re: Problems of C, and how Zig addresses them

#128

Post by throwaway17_17 » Mon, Jul 03, 2023, 7:51 PM UTC

igor_akhmetov wrote: post #117

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, the ‘resistance’ to RAII is a clear effect of those principles.

Re: Problems of C, and how Zig addresses them

#129

Post by pjmlp » Mon, Jul 03, 2023, 7:53 PM UTC

gorjusborg wrote: post #15

pjmlp wrote: post #6

Naturally it doesn't show how it tackles use-after-free cases.

Rather than offer drive-by criticism, perhaps you could illustrate 'the problem' you are suggesting is being hidden?

The problem is that Zig is basically Modula-2 for C syntax lovers, plus metaprogramming.

It is hardly safer than Modula-2 already was over C already in 1978.

We are in 2023 now.

Re: Problems of C, and how Zig addresses them

#130

Post by masfuerte » Mon, Jul 03, 2023, 7:57 PM UTC

Dwedit wrote: 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.