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

Problems of C, and how Zig addresses them

avestura.dev

Post reply on HN
Print view View original

161–170 of 290 posts

Re: Problems of C, and how Zig addresses them

#161

Post by veber-alex »

Cyberdog wrote: post #121
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

Who uses bun in production?

Seems totally insane to me to use a pre-1.0 application written in a pre-1.0 language in production considering Node and Deno basically do the same thing.

Re: Problems of C, and how Zig addresses them

#162

Post by pixelpoet »

Gibbon1 wrote: post #136
flohofwoe wrote: post #86

Earlier quoted context omitted.

+1 (don't want general operator overloading, but a more powerful @Vector builtin type, basically Clang's ext_vector_type: https://clang.llvm.org/docs/LanguageExtensions.html#vectors-... ), plus maybe a similar @Matrix builtin up to 4x4.

Maybe I'm small brained but built in vector types align with heavily platform optimized libraries. Meaning you don't want this stuff implemented in the compilers front end. You want it handled in the compilers back end.

Performance is equivalent in both representations, but the important thing is being able to write

  vec4 c = a * 4 + b;
instead of

  vec4 c = vec4_add(vec4_mul(a, 4), b);
i.e. infix vs postfix order, with simple * and +/- operators etc. I would very much like to appeal to the Zig authors to see the beauty in the former expression compared to the latter, for a huge class of real-world mathematical applications.

Re: Problems of C, and how Zig addresses them

#163

Post by kristoff_it »

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.

> I really want to like Zig.

Don't try to like Zig and instead make sure your cup is empty before entering a new tea shop.

Re: Problems of C, and how Zig addresses them

#164

Post by dsego »

pixelpoet wrote: post #83

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…

Odin does this afaik.

Re: Problems of C, and how Zig addresses them

#165

Post by pixelpoet »

jacquesm wrote: post #147
pixelpoet wrote: post #83

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…

It would be nicer still if vectors and matrices were first class citizens. That way you can hide all of that stuff and it opens up across the board optimization routes that are otherwise much harder.

Agreed, that's basically what I'm asking/begging; don't need operator overloading, but please do give me vectors and matrices.

Edit: I asked in the Zig Discord and was told "it's been denied many times", oh well :/ Fair enough, it's their language to control.

Re: Problems of C, and how Zig addresses them

#166

Post by pixelpoet »

syntheweave wrote: post #141
pixelpoet wrote: post #83

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…

As a comptime macro, yes, you should be able to slot in a DSL for all your vector math and essentially "pass in a string, get the function calls back". It would not be that hard, if you're up on your parser-writing skills, and definitely much cleaner than any C-style equivalent.

Yep that seems comptime possible but a little heavy handed with string work, no? With everyone writing their own parsers and language tools...

In any case, if something practical is done here I'd be interested. Aesthetically I prefer the "vectors and matrices are first class types" (and maybe complex numbers could be too), but I guess Andrew isn't so sympathetic to these types being part of the standard language :/

Re: Problems of C, and how Zig addresses them

#167

Post by e4m2 »

menaerus wrote: post #157
matklad wrote: post #144

Earlier quoted context omitted.

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?

> Does it assume that the predefined capacity will not be reached?

Yes, the function name says exactly that as well, though admittedly what this actually means and what consequences it might have if the assumption is false are probably fairly opaque to a novice user.

> how does it handle the case where you don't have enough capacity to insert the new (k,v) pair?

Breaking the invariant results in safety-checked undefined behavior, that's what the "asserts" in the doc comment signifies[0]. Basically, if something goes awry at runtime you'll get a crash along with a nice error trace in Debug/ReleaseSafe mode or with the appropriate @setRuntimeSafety call.

If instead you'd like to have errors that you can handle, you could use your real allocator where you expect to actually use it and pass a failing allocator[1] everywhere else (but that's sort of abusing the API IMO, I don't know if I'd actually recommend you do this).

[0] https://ziglang.org/documentation/master/#Doc-Comment-Guidan...

[1] https://github.com/ziglang/zig/blob/0dffab7356685c7643aa6e3c...

Re: Problems of C, and how Zig addresses them

#168

Post by justinpombrio »

naasking wrote: post #148
flohofwoe wrote: post #86

Earlier quoted context omitted.

+1 (don't want general operator overloading, but a more powerful @Vector builtin type, basically Clang's ext_vector_type: https://clang.llvm.org/docs/LanguageExtensions.html#vectors-... ), plus maybe a similar @Matrix builtin up to 4x4.

I think operator overloading should be fine even for puritans, as long the language requires the type to be numerical in a strict sense, and so they have a well defined semantics. So integers, floating point, complex numbers, vectors, matrices, etc.

How would the language require it to be numerical? For example, if you're defining complex numbers in a library, what would the compiler be checking about your ComplexNumber type before allowing you to define `+` for it?

Re: Problems of C, and how Zig addresses them

#169

Post by bryancoxwell »

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?

Zig is kind of fun to write to be honest. I mean about as fun as a systems programming language can be.

Re: Problems of C, and how Zig addresses them

#170

Post by eichin »

kristoff_it wrote: post #131
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?

> As far as I know, no one is using it in production after 7 years of development. - Uber uses Zig to produce hermetic builds of their backends and was able to move their C/C++ codebases to arm64 thanks to Zig's C/C++ cross-compilation support. https://www.uber.com/en-US/blog/bootstrapping-ubers-infrastr... - Bun is written in Zig and its sudden success was big enough to cause Deno to have an identity crisis. - Tiger…

Was apple silicon the thing that brought "caring about cross compilation" back from the dead in general? small-scale embedded use never really went away, but it was always a distinct niche...
Post reply on HN