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

251–260 of 290 posts

Re: Problems of C, and how Zig addresses them

#251

Post by Klonoar »

vanderZwan wrote: post #244
Klonoar wrote: post #235

Earlier quoted context omitted.

One thing nobody has pointed out yet - and this is not a knock on any language whatsoever but moreso a commentary on HN itself , so take it with a grain of salt, but: if you've followed this site since the beginning, programming languages cycle through here with a hype phase every few years like clockwork. The one most people jump to from the past few years is Rust and/or Go, but we've experienced this with other lan…

Go was mostly hated on when it came out iirc.

You may be right - I paid less attention to that era of HN.

Re: Problems of C, and how Zig addresses them

#252

Post by kristoff_it »

saagarjha wrote: post #204
kristoff_it wrote: post #131

Earlier quoted context omitted.

> 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…

Apple shipped a LLVM cross-compiler for Apple silicon on day one? Not entirely sure what you mean here.

Apple shipped a compiler with the M1 Mac, yes, but if you wanted to compile for Apple Silicon from say a Linux x86_64 machine, there was no toolchain that was able to do it other than Zig.

Re: Problems of C, and how Zig addresses them

#253

Post by camel-cdr »

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.

Most of the time you want to use something like size_t anyways.

Re: Problems of C, and how Zig addresses them

#254

Post by WalterBright »

brabel wrote: post #234
WalterBright wrote: post #103

Earlier quoted context omitted.

D uses byte, short, int, long for i8, i16, i32, i64, and ubyte, ushort, uint, and ulong for the unsigned versions. After 5 minutes with the language there is no longer any point to emphasizing the number of bits. Besides, they're just easier to touch type.

But Zig lets you use arbritary number of bits... you can write `i4` for example, or `u120` or whatever, which is a pretty great advantage.

True, but can you create a pointer to a 4 bit type? I tried to make that work in D at one point, and wound up abandoning it.

D allows 4 bit types using conventional bit fields (but you can't take a pointer to them).

Re: Problems of C, and how Zig addresses them

#255

Post by stefncb »

ben20440 wrote: post #137

Problems of C: - memory safety - concurrency How Zig addresses them: - it doesn't.

Zig has async and await and is safe from buffer overflows and related memory issues. What it indeed doesn't solve is memory safety with time (so use after free and leaks), though this is somewhat ameliorated by the encouraged programming style.

Re: Problems of C, and how Zig addresses them

#256

Post by psychoslave »

dagmx wrote: post #146
gorjusborg wrote: post #15

Earlier quoted context omitted.

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

Isn’t that a pretty clear, if terse, description of the problem? Use-after-free is a well known problem in the memory managed programming space and one that Zig infamously does not tackle. For those who aren’t familiar, it’s the use of a resource (a pointer) after it is no longer available for use (or has been freed). Which can in turn result in accidentally accessing unexpected data or crashing.

I never tried Zig, but can’t you, instead defer the actual resource release, replace it with one which crash at compile time? This is a naive suggestion based on lousy inferences of features that seems highlighted in Zig, comptime and deffer.

Re: Problems of C, and how Zig addresses them

#257

Post by menaerus »

e4m2 wrote: post #167
menaerus wrote: post #157

Earlier quoted context omitted.

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 undefi…

Right, that's what I thought is happening under the hood. Thanks for confirming.

This also means that there is nothing novel about this approach that cannot be achieved in other programming languages as one of the parent comments claimed.

This is simply a hashmap with pre-allocated pool of memory.

Re: Problems of C, and how Zig addresses them

#258

Post by kristoff_it »

avgcorrection wrote: post #217
kristoff_it wrote: post #131

Earlier quoted context omitted.

> 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…

> Bun is written in Zig and its sudden success was big enough to cause Deno to have an identity crisis. VP of Community strikes again.

You feel it's an unfair statement?

Re: Problems of C, and how Zig addresses them

#259

Post by jacquesm »

pixelpoet wrote: post #165
jacquesm wrote: post #147

Earlier quoted context omitted.

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.

That's a weird answer. If something is denied many times that shouldn't count as a reason to deny it again but to question whether that denial is appropriate.

Re: Problems of C, and how Zig addresses them

#260

Post by pjmlp »

saagarjha wrote: post #248
pjmlp wrote: post #240

Earlier quoted context omitted.

Somehow no one managed to make cross-compilers work, even though it is the standard way of working in embedded and game consoles for decades.

Yeah idk. I don’t want to be snarky but “we had a cross compiler for ARM with a few tweaks” that had already had hardware shipping for half a decade doesn’t sound all that impressive.

Indeed.
Post reply on HN